OpenGeoLayers
Overview
OpenGeoLayers is a proposal to run a copy of the OpenStreetMap database and server for the purpose of storing any Geo data that is not a part of the world basemap OpenStreetMap.
The components required for the system are:
- Database
- Editing API
- Overpass API
- User management front end
Services that are not relevant are the following for OpenGeoLayers are:
- Tile rendering
On the main web page, ideally there would be an OSM slippy map where the user can select one or more map layers from a list and they would be displayed as overlays.
Uses
Some possible uses for the database are:
- Information related to mapping efforts in OpenStreetMap that are not part of the base map. One recent example is outlines of where Bing has high resolution imagery. See the discussion thread at http://gis.19327.n5.nabble.com/Imagery-Boundary-td5755334.html.
- Geodata related to academic and scientific studies, such as fauna and flora information. See the discussion thread at http://gis.19327.n5.nabble.com/Scientific-Species-Data-in-OSM-Database-Collaborators-td5732256.html
- Geographic operations data for projects such as the Humanitarian OpenStreetMap Team. http://hot.openstreetmap.org/
- Other arbitrary geographic data such as recorded GPS traces from running, biking, hiking or other recreational events. This is comparable to data help by public services such as Garmin Connect or Strava but the data is open. See the proposal OpenSportMap, http://wiki.openstreetmap.org/wiki/OpenSportMap
Map Layers
The name layer here refers to a grouped set of similar geographic data. The OpenGeoLayers database is intended to hold not a single specific layer of data but rather many different layers. Specific layers are identified with the tagging on the features. See the section on tagging.
The idea of adding map layers to OSM is not new. Below is a OSM-Talk related to map layers that includes a link to a more detailed discussion on the topic. The ensuing discussion on OSM-Talk is also of interest.
The implementation of map layers in this proposal is very simple. It contains no provision for linking data in this database to the OpenStreetMap database. This linking would be helpful in many cases, such as including routes in the layer database by linking to street segments in the OSM database. However linking the databases presents many challenges that are not addressed here. OpenGeoLayers serves the many cases where a link is not needed. This is a simple repository for geo data that is independent of the base map layer.
Using OpenGeoLayers
Tagging
The OpenGeoLayers database will consist of many different map layers, as defined above. Within a given layer, the tagging will be defined specific to that layer. For the database a single new tag "map_layer" is defined to identify the layer to which an object belongs.
- key - map_layer
- value - values to be defined
A layer will thus be composed of all the objects that have a given value for the map layer tag.
A proposal for a specific layer of data can be seen at http://wiki.openstreetmap.org/wiki/OpenSportMap. Entries in this layer are grouped by a relation of type "rec_event". If this layer is included in the OpenGeoLayers database, the top level relation would have an entry added with the key "map_layer" and the value something like "OpenSportMap" or "rec_event".
Editing
When editing data typically a user will only be interested in data from a single map layer, or possible a select number of map layers. This contrasts with the base map, where typically all data is desired for a specific area. Thus for OpenGeoLayers the Overpass API is appropriate API to use for retrieving data. The OpenStreetMap editing API only supports requests by bounding box and object ID. These requests are not practical in OpenGeoLayers.
The disadvantage of the Overpass API is that it is run off of a separate database from the map. It is synchronized with the map database on a one minute interval. This means there is a small delay between the when data is committed to the database and when it is available for download. For the time being this will be a limitation of the system.
To submit edits to the OpenLayer database, the standard Editing API is be used.
Displaying Data
Many clients can be made to retrieve data from OpenGeoLayers. The typical client would display one or more map layers on top of an OSM base map. The Overpass API would best be used to retrieve the data for the time being.
Main OpenGeoLayers Client
The main OpenGeoLayers client, which is displayed on the main web page, should allow a user to select one or more map layers and view them as overlays on an OSM client.
(Overpass Turbo, a web based graphical UI that retrieves data from the Overpass API and displays it as an overlay on a slippy map, can be a possible starting point for the client.)