A Collaborative Web Mapping System for Urbit

Worker(s): Lumphead Reward: 4 Stars WIP

A Collaborative Web Mapping System for Urbit

Goal

Allow small scale spatial data to be stored and retrieved in Urbit, for use in landscape and external applications, and shared across ships.

Background/Motivation

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 GeoJSON1 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.

Overview

Stage 1 - A spatial store, spatial types, simple demo app

Spatial Document Store and Tools
Hook, View and Landscape App

Stage 2 - A Portal Store and Collaboration System

Store (Metadata, Portals)
Hook/View/App
Footnotes
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.

About Me

I am a beef farmer and software engineer (geospatial web applications). I work with tools/frameworks such as Openlayers, Leaflet, Geoserver, Postgresql/PostGIS etc. and I code predominantly in Java, Javascript, SQL, Clojure, and Python. I have completed the original Hoon 101 course, half the 201 course, and the recent hackathon. My hackathon entry was a very primitive geojson editor gall/landscape app (https://github.com/gusmacaulay/urlayers).

~lomped-firser

Milestones

Stage 1

2 stars A spatial store, spatial types, simple demo landscape app

Stage 2

2 stars A Portal Store and Collaboration System