I talked with Nate Smith (Humanitarian OpenStreetMap Team) at SOTMUS 2017 about how to build OAM uploading into WebODM. We thought it would make the most sense to do it there rather than in ODM core, as you can visualize the maps easily and connect user accounts.
Our goal: make a simple process for uploading your processed orthomosaic into OAM
Implementation concept:
- Ability to connect OAM API token to user account. see: https://github.com/hotosm/oam-catalog/issues/112
- Add a button to open a form for uploading a completed ortho
- I think the logical location would be in/around the map viewer
- Check whether the map has already been uploaded
- Also, if the process is rerun, ask before re-uploading
Upload form:
- Dataset Title
- Platform (Sat/Aircraft/UAV/Balloon/Kite)
- Sensor (eg. canon s100)
- Date Start
- Date End
Imagery Location (file loc)Tile Service url template (optional)- Provider (user)
- Tags (comma-separated)
Some of these can be auto-filled. We could keep track of which aerials are from WebODM by always adding a ‘OpenDroneMap’ tag.
Thoughts for the future:
- Adding the OAM map as a base map
- This is not implemented on OAM side yet, but should be soon
Let me know what y’all think about this, if you have specific ideas about how to implement, or other ways this could be done.
I have a few ideas; is this still relevant per the latest e-mail exchange with Matthew?
I think so. I don’t believe the serverless project has much to do with OAM integration, unless I’m mistaken. What are your ideas?
Architecture-wise, this “push” mechanism should be abstracted in order to allow multiple providers to receive data. We discussed that a little bit here https://github.com/OpenDroneMap/WebODM/issues/92. I think OAM would be a Plugin that offers “push” functionality (other functionalities could be added for other types of plugins). This architecture would allow us to create plugins for entwine/greyhound and others.
- Each plugin should be manageable, meaning an Administrator should be able to turn them on or off.
An Administrator should be able to install/remove a plugin without modifying the code. This could be a simple .zip archive and we could extend that to a “plugin registry” (QGIS style) in the future.
- Each plugin should not change the core WebODM tables (for example, to store token values). It should store values either on the FS or on separate tables.
- Each plugin should expose a public manifest, containing author name, description and functionalities, such as push, interface, hook, algorithm (think users being able to define their own postprocessing functions, like NDVI)
- Each plugin should expose functions for tearup (create db schemas, initialize fs, etc.), teardown (remove db schemas, cleanup).
- Each plugin that supports an “interface” functionality will have entries added in the side menu (a Django template?). This would allow users to set their configuration (in the case of OAM, the tokens).
- WebODM should have a system to manage the plugins (discovery, activation, deactivation, configuration)
We’ll need to define the exact structure of the plugin files/directories/manifest format. It might be interesting to look at how QGIS does it.
If this sounds like a lot of work, it is initially, but over the long run it will allow the platform to extend in a modular fashion. A monolithic solution is likely to become very inflexible to the changing needs of users.
I should probably ask, what is the timeline for OAM integration?
No timeline yet. While I had initially thought it best to keep the OAM addition light, your plugin idea is fantastic.
My tentative list of priorities for ODM/WebODM right now is as follows:
I’m thinking I could dedicate full attention to the plugin architecture sometimes starting in December.
1 Like
A quick update on OpenAerialMap, I’ve opened a question here https://github.com/hotosm/oam-uploader-api/issues/86 to ask information about the upload API, but no answers yet.