Allow small scale spatial data to be stored and retrieved in Urbit, for use in landscape and external applications, and shared across ships.
This proposal has grown out of a previous bounty which called for Open Street Map data to be ingested into Urbit. Through discussion it was decided that as OSM already provides a free, open and widely available base map and street network, a more useful system for Urbit would provide a method of storing spatial documents, which can overlay upon existing spatial data such as Open Street Map tiles, be collected together for use in landscape apps, and combined, shared and collaboratively edited with other ships as 'Portals'. A spatial document, for the purpose of this proposal, is a single valid GeoJSON[^1] document. A spatial document could contain a single geometry, a feature (geometry with associated properties), or a collection of features (a GeoJSON 'featurecollection'). A Portal is a collection of spatial documents, with associated metadata and can include spatial documents from multiple ships, whose owners can collaboratively edit or construct maps.
The proposed system will follow the Urbit store-hook-view pattern as described here https://docs.google.com/document/d/1hS_UuResG1S4j49_H-aSshoTOROKBnGoJAaRgOipf54/edit?ts=5d533e42
The system will be implemented in two stages. The first stage will implement simple spatial types and a spatial document store, demonstrate input and output of spatial data, and provide a minimal landscape app for creating and editing spatial documents, but limited to the local ship. The second stage will build on the first and provide Portals; collections of spatial documents and associated metadata, which can be shared across ships - similar to the 'canvas' landscape app (https://github.com/yosoyubik/canvas).
[^1]: The very readable spec for geojson can be found here http://geojson.org. An overview of GeoJSON summarizing it's advantages and limitations can be found here https://macwright.com/2015/03/23/geojson-second-bite.html
[^2]: A mature spatial store would include spatial indexes and provide spatial queries, however for the objectives of this proposal basic spatial spatial documents storage and retrieval can be achieved without spatial indexing. Each spatial document is treated as its own entity, and has limited querying beyond fetching and inspecting the data structure. However this is enough that it can easily be splatted on a map. Spatial indexing of geometries (or parent features/feature collections), is a sensible next step, which would allow many more use cases but is not in scope for this proposal.
[^3]: It may be possible to store styling info within the spatial documents, there are at least two GeoJSON style storage conventions, but nothing standardised (see discussion here https://gis.stackexchange.com/questions/22474/geojson-styling-information). Neither of these are part of the GeoJSON standard and appear to be not used much in the wild. There are formats such as KML and GeoPackage which have styling support, but these are also more complex formats.