Large Scale ODM Reconstruction
Effective disaster preparedness, monitoring, relief coordination, and damage assessments are predicated on reliable, up-to-date geographic information paired with on-the-ground knowledge. The detailed imagery available from unmanned aerial vehicles well fits this predicate due to high level of spatial detail, flexibility in requisition, and image quality. OpenDroneMap seeks to provide fast, accurate, easy-to-use, and scalable processing of aerial drone imagery that is necessary for the next generation of humanitarian response.
We’ve recently introduced a new workflow for OpenDroneMap (ODM) image processing, informally called Split-Merge. Initially conceived as a way to handle the increasing size of datasets being attempted by users and our team, we created a set of scripts that process subsets of the data that are geographically aligned and produce a single aerial map. The always excellent developers at Mapillary were indispensable in the development process, as their team provided the meat of the code that split the model into manageable chunks (called “submodels”) and made sure they remained aligned as each one processed.
The core problem we wanted to solve was the ability to handle large datasets without (1) taking an inordinate amount of time and (2) costing too many resources. Certain processes in the toolchain were struggling to handle large datasets. In some cases they were simply running out of memory, but other times there were issues writing such large outputs to disk. We identified other issues that popped up during development that were incidental to the split-merge pipeline. For example, when working with very large flat scenes, like in many areas of Unguja Island, Zanzibar, Tanzania, OpenSfM had trouble initializing the reconstruction. There were also improvements to be made with how the models are georeferenced, which would have to be addressed earlier in the toolchain in order to make sure each submodel stayed aligned with its neighbours.
The split-merge process takes advantage of OpenSfM, the set of algorithms responsible for generating the 3-dimensional point cloud, being the first major step in the ODM toolchain. In short, OpenSfM extracts unique features from each image as points, matches those features to neighboring images using GPS information provided, and then incrementally builds a point cloud of shared points using constraining parameters. In this new process, after the images are matched, we split the images into smaller, overlapping clusters called submodels. Then the incremental reconstruction is performed on each submodel. Because these clusters have overlapping geographic extents, their points are able to be aligned with each other before the rest of the ODM process continues. Each submodel, therefore, is run like a mini ODM project. Finally, the orthophoto maps created by each submodel are merged into a final map.
With this process in place, ODM is now capable of processing datasets of greater than one thousand images, although the upper limit is not yet known. Better still, these tasks can be completed on consumer-level high performance computers or standard cloud computing resources. It should be noted that the purpose of the split-merge addition was to scale ODM capabilities, and while many parts of the software were made more efficient in the process, these improvements do not necessarily mean that split-merge can be run on insufficient resources. As with any project, there are always plans for further improvement. Currently only the orthophoto output is merged into a final product, but the 3D outputs like the point cloud and textured mesh, as well as DTM/DTM outputs should also be made available. Ultimately, better integrating the split-merge feature into the standard toolchain would also be beneficial not only to use but also as a general improvement to the whole ODM ecosystem. As we grow our capabilities for drone mapping, we hope to bring better tools to our users and the communities they map.