The OpenAerialMap Beta was just launched yesterday by DevelopmentSeed - a reboot of the old OAM from ~2008 (if I recall?). It's a global index of aerial imagery, depending on a simple standard for metadata which we now plan to support in Public Lab's MapKnitter:

https://github.com/publiclab/mapknitter/issues/178

Many of the maps in it have ~50cm/px resolution, whereas many MapKnitter maps (made from balloon, kite, and drone imagery) have 5-15cm/px resolution. And there are a lot of MapKnitter maps -- 1578 as of today.

Georectification metadata

I have another suggestion, though -- what if we modularized by providing georeferencing in aerial image metadata? (I know, isn't this what a GeoTiff is? :-P) There are a few reasons that'd be a good idea for individual images. First, MapKnitter approaches the problem from the other end of things when compared to auto-stitching. Instead of batch-processing huge numbers of images (which can take hours), Public Lab mappers fly balloons or kites much higher than drones typically can -- 1000-4000 feet, and capture fewer, large images. A good image from up high can cover a quarter mile! But in any case, many people just need a single good shot, like this one by Pablo Rey in Madrid:

This means that referencing is pretty easy to do by hand - just upload the image, scale and rotate it into place. Or if your camera/smartphone has a GPS, MapKnitter will auto-place the image for you, using GPS, GPS altitude, and compass heading.

Skipping re-rasterization

The other side of this is that due to our recently launched Leaflet plugin Leaflet.DistortableImage (read a great in-depth discussion in @justinmanley's The Magic Behind MapKnitter), MapKnitter 2.0 displays georectified images natively distorted with CSS3, in the browser. Go ahead -- right click the image above, and open it in a new tab. It's not a tile layer.

This means that unless you want to print a map out, there's no longer a reason to run GDAL (which powers MapKnitter's exporting function) at all -- hundreds of images are simply rotated, scaled, distorted, and displayed in real-time. For huge batches of images, we'd prefer to simply store each image once, which also means that you don't have to lose data where images overlap -- say, if one has better exposure, but the other has better sharpness. Most of all, it means MapKnitter's exporting engine doesn't need to be fired up as often -- saving CPU and memory on our servers. For big maps like this 48-image map by Chris Fastie, that makes a big difference:

These aren't everyone's priorities -- they're distinct to our use case -- but there is a common thread. We've kept an eye on auto-stitching approaches such as what OpenDroneMap is finally making easier. But it's not an either-or situation. We feel that the ease (especially for non-programmers, or non-GIS folks) of simply placing an image on a map makes a huge difference for many folks. But a rough placement can make interest point matching much more efficient, and some automation (such as via GPS) can make manual stitching much more efficient.

Convergence

Let's converge by standardizing on the interchange format of the rectification data itself, so that images from MapKnitter can be used as an incoming dataset for OpenDroneMap, and eventually, we could use interest point matching to assist manual stitching -- perhaps by providing visual indications of possible matches, like semi-transparent "spiderwebs" connecting two nearby images.

Just to throw out one more wild idea here -- I believe the matrix distortion calculations we do for Leaflet.DistortableImage could be re-used in WebGL to (someday?) generate exportable full-resolution versions of maps, in the browser. If possible, that would make this type of mapmaking hugely scalable!

Want to talk more? Come to the Public Lab Open Hour ("Behind the Code") this Monday the 1st at 1pm ET -- we're having an online software development meetup.