[HOT] OpenAerialMap - Catalog Tech Challenge
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.
> Toward that goal, project leader Cristiano Giovando has published the
> first "Tech Challenge" to develop a core component of the system, the
> imagery catalog.
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
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
>From a quick review of the requirements at
R1. Maximum effort to reuse code and integrate with existing open source
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
R5. Developed using interoperable and modern programming languages
R6. Scalable, to support increased workload of peak request periods (e.g.
during a disaster emergency) and able to quickly replicate across multiple
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.
More information about the HOT