Architecture
From OpenAerialMap
The Architecture of OpenAerialMap is still up for discussion, but will also depend up on hardware Resources available
Diagram from discussions in Nov 2010: http://twitpic.com/35saf8
Contents |
Ideas for distributed tile architectures
Version 1
Simple portable AMI/VM with ingesting, processing and publishing capabilities.
This is a self contained instance (AMI, VM, Euca, installer) similar to tiledrawer that can be ported and fired up on a laptop, server, or AWS. It takes any
GeoTIFF (already georeferenced), creates an index, setup MapServer, creates the cache, and publish TMS, Google tiles, KML, WMS, etc. As easy as putting a bunch of geo-images in a directory then expecting to see http://127.0.0.1/oam/ running.
Version 2
Scalable instance for AWS hosting.
This would be the main OAM server. Take version 1 and put django (or any glue) on top. Imagery can now be updaloaded from anyone to the central repository,
either through simple Web form or FTP. Very similar to what cschmidt/telascience OAM was, but with much more power. Public access at http://openaerialmap.org/
Version 3
API support and pluggable distributed instances.
Take version 2 and replicate for cloudfronts or distributed storage space. Anyone setting up an OAM instance would be able to plug into the main federation through a common API and standards.
Version 4
Catalog, search, history, filtering.
Add OMAR catalog and provide access to single dataset or frame. Semantic tagging and medatata management. Realtime indexing of image peers. History of changes with public access. Filtering output based on data license, something like oam.org/cc or oam.org/pd, etc. OGC Catalog, CSW with support for standards (ISO, INSPIRE)..
