Why DroidMap

DroidMap started with a drone bought to answer a question.

One of us grew up on a fifth-generation farm at Cowra, in central New South Wales. The question was whether a set of changes to how the place was managed were actually working. Not in a general sense, but on this paddock, compared to last season. A drone seemed like the obvious way to find out. Fly it, look at the imagery, see what changed.

Flying it was the easy part.

Capture stopped being the hard problem

Aerial imagery used to be scarce and expensive. It isn't any more. The camera on a mid-range drone is good, the flight planning is a solved problem, and anyone who needs a survey of a few hundred hectares can have one by lunchtime.

What has not become easy is everything after the flight. You land with hundreds of overlapping frames, and none of them is an answer. Somewhere between those frames and a decision sits a stack of work that has very little to do with flying: stitching the imagery into something georeferenced you can measure against, building the terrain and structure out of it, and then working out what is different from last time, which is the part people actually care about.

That work is where most of the value is, and it is the part that is still hard.

Three things get in the way

The processing needs real compute. Turning overlapping frames into a georeferenced orthomosaic, a point cloud, and an elevation model is genuinely heavy work. It is also bursty: nothing for three weeks, then a lot at once. That is a bad shape to buy hardware for and an easy shape to rent, which is why we run it as cloud-native infrastructure that scales up for a job and back down afterwards. You should not have to own a workstation to answer a question about a paddock.

One flight is rarely the answer. A single map tells you what something looks like. Almost every question worth asking is comparative. Is this getting better or worse? Is the change we made working? Is this moving faster than it was? That means today's flight is only useful if it can be lined up against the ones before it, which means the earlier data has to still be there, still georeferenced, and still comparable. Imagery that lives on a laptop and a couple of external drives cannot do that. So storage is not a filing cabinet bolted to the side of the product; it is the thing that makes temporal analysis possible at all.

The tools do not talk to each other. The common setup is one tool to process, another to analyse, a third to share, and a folder structure holding it together. Every handoff is a chance to lose the georeferencing, the metadata, or the thread back to which flight this came from. We would rather ingest, process, analyse and share in one place, and expose the whole thing through an API so it can sit inside whatever you already use rather than replacing it.

And then the interesting part

Once imagery is processed, stored and comparable, you can start asking software to look at it for you. Detecting objects, classifying ground cover, flagging what changed between two dates: these are machine learning problems, and they only become tractable when the data underneath them is consistent. Getting the boring layer right is what makes the interesting layer possible.

Who this is for

The farm was our way in, and precision agriculture is still close to our hearts. But the shape of the problem is not specific to farming. Environmental monitoring, urban planning, mining, disaster response and infrastructure inspection all have the same structure: capture is cheap, comparison over time is where the value is, and the processing in between is the bottleneck.

If you are flying imagery and finding that the flight is the easy part, that is the gap we are building for.