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 _______________________________________________ HOT mailing list [email protected] https://lists.openstreetmap.org/listinfo/hot
