[HOT] OpenAerialMap - Catalog Tech Challenge

Brad Hards bradh at frogmouth.net
Sun Feb 22 02:41:37 UTC 2015


On Thu, 19 Feb 2015 10:43:57 PM Blake Girardot wrote:
> Hi everyone!
> 
> As you may have heard (we hope you have) the Humanitarian OpenStreetMap
> Team is actively developing the relaunched OpenAerialMap project, an
> effort to make aerial imagery easier to organize, share and use.
> 
> https://github.com/hotosm/OpenAerialMap
> 
> Toward that goal, project leader Cristiano Giovando has published the
> first "Tech Challenge" to develop a core component of the system, the
> imagery catalog.
> 
> http://hot.openstreetmap.org/get_involved/openaerialmap_catalog_tech_challen
> ge
I'm not sure if this has been suggested before, but you might like to consider 
re-using software from another group who had some similar needs - the US DoD.

It turns out that internal to the DoD, there are a few groups who collect 
imagery (and other stuff). They don't want to hand over all the data to one 
"boss" group, so they keep there own data in their own repositories (e.g. 
Distributed Common Ground Station instances), and just federate queries into 
the distributed catalogs.  

The code that does the federated queries is open-source (LGPL), and is on 
github (https://github.com/codice has the various projects). Its modular, so 
you have to build multiple projects if you want all of the open-source bits. 
The upside is that you don't have to take anything you don't want. 

CSW, KML and WFS are supported out of the box. You can easily add to that if 
needed.

Its has documentation - https://tools.codice.org/wiki/display/DDF/DDF+Home on 
how to use it, and how to extend it.

The US government is paying for it to be developed and maintained, and while 
there are some parts that aren't open source (because they are adapters to 
allow link to legacy military systems), they also aren't important for 
OpenAerialMap.

>From a quick review of the requirements at 
http://hot.openstreetmap.org/get_involved/openaerialmap_catalog_tech_challenge

R1.    Maximum effort to reuse code and integrate with existing open source 
projects
 DDF: Re-uses existing apache projects (Karaf, Camel, Tika), builds on 
geotools. Uses Cesium globe. 

R2.   Lightweight with small footprint even if installed on portable hardware 
(e.g. i5/i7 laptop)
DDF: definitely runs on my laptop. If you want to keep data locally, then size 
might be an issue.

R3.    Limited and focused to handling raster imagery data, with an effort to 
reduce overhead from features of reused code that are not needed for OAM
DDF: Modular, and extensible metadata format.

R4.    Self-contained, portable, with simple installation steps (e.g. through 
deployment with software containers or by virtualization) for compatibility 
with multiple operating systems
DDF: Easy to install (unzip and run) on Linux, some developers use Mac and 
Windows.

R5.    Developed using interoperable and modern programming languages
DDF: Javascript and Java. 

R6.    Scalable, to support increased workload of peak request periods (e.g. 
during a disaster emergency) and able to quickly replicate across multiple 
instances.
DDF: I haven't done any scale-out work myself, but there is a front-end load 
balancer available (https://github.com/codice/loadbalancer). For most 
purposes, parallel installs is probably enough scalability.

It isn't likely to be a 100% solution, but it could be useful as a base (and a 
shared upstream, so OAM isn't carrying the catalog alone).

So it might not be the right answer for OAM, but its worth a look.

Brad



More information about the HOT mailing list