Do you recall this 2013 post on GeoHipster?:
Later on, I confessed my secret to making accurate predictions:
In all this however, we are only touching the surface of what is possible. After all, while we have a solid start on a drone imagery processing toolchain, we still have gaps. For example, when you are done producing your imagery from ODM, how do you add it to OpenAerialMap? There’s no direct automatic work flow here; there isn’t even a guide yet.
And then once this is possible, is there a hosted instance of ODM to which I can just post my raw imagery, and the magical cloud takes care of the rest? Not yet. Not yet.
So, this is the dream. But the dream is bigger and deeper:
I remember first meeting Liz Barry of PublicLab at CrisisMappers in New York in 2014. She spoke about how targeted (artisanal?) PublicLab projects are. They aren’t trying to replace Google Maps one flight at a time, but focus on specific problems and documenting specific truths in order to empower community. She said it far more articulately and precisely, of course, with all sorts of sociological theory and terms woven into the narrative. I wish I had been recording.
Then, Liz contrasted PublicLab with OpenDroneMap. OpenDroneMap could map the world. OpenDroneMap could piece together from disparate parts all the pixels for the world:
- At a high resolution (spatial and temporal)
- For everywhere we can fly
- One drone, balloon, and kite flight at a time
- And all to be pushed into common and public dataset, built on open source software commonly shared and developed.
Yes. Yes it could, Liz. Exactly what I was thinking, but trying hard to focus on the very next steps.
This future ODM vision (the “How do we map the world with ODM) relies on a lot of different communities and technologies, from PublicLab’s MapKnitter, to Humanitarian OpenStreetMap Team’s (HOT’s) OpenAerialMap / OpenImageryNetwork, to KnightFoundation / Stamen’s OpenTerrain, ++ work by Howard Butler’s team on point clouds in the browser (Greyhound, PDAL, plas.io, etc.).
Over the next while, I am going to write more about this, and the specifics of where we are now in ODM, but I wanted to let you all know, that while we fight with better point clouds, and smoother orthoimagery, the longer vision is still there. Stay tuned.
Smathermather's Weblog 
As I see it, the biggest gap is not in smoother uploading or cloud processing in the cloud. The biggest gap is Ground Control Points. Until there’s a way to capture those accurately at a prosumer price point, we are doomed to a patchwork of images that don’t align, which is useless for most purposes, like overlaying other geodata.
I don’t see as patchwork and alignment as a major issue.
Ground control for relative correction is easy in my mind: either tie into a lower resolution image dataset (in an automated or semi-automated process), or allow for matching between your different datasets (or both!).
The latter of the two is used in Mapillary’s project, which meant they needed to solve the incremental matching problem, i.e. I have 1000 photos already tied together, and I want to add 50. I don’t want to reprocess the first 1000. The first problem is somewhat trivial by comparison.
Now, when we get to the point where we want absolute corrections, then it gets interesting (especially with respect to coordinate systems and datums). But, that will be a great problem to have… .
Oh, and I should say, it will get interesting once a few different pre-matched datasets start to tie together (1000 + 50 becomes 1000 + 50 + 1000). But if you can forestall reprocessing whole datasets as long as possible with the Mapillary approach, or if you are also tying the whole fabric to be consistent with a lower resolution dataset, than you should be OK in relative space, and in comparison with other geo datasets.