[OSM-talk] Multiple Layers for OSM

Simon Poole simon at poole.ch
Tue Sep 25 11:38:20 BST 2012


This is nice, in my manifesto I even have an item on supporting research
in to some kind of layer functionality, and now the discussion has
started on its own :-).

My thoughts

- GIS-like layers are a no no, they increase dependencies in the data
and we want to achieve the opposite.

- any implementation will have to conserve the most scarce resource we
have: developer time. This applies equally to core infrastructure as to
the myriad of tools and editors.

- at least for any layers/databases operated by the OSMF we should not
depart from the any user can edit anything  principle.

- any implementation should a allow conflict free merging of data and
synchronizing of data from multiple sources

IMHO the easiest, but very hackish, way to achieve this would be to
split the (64bit) object ID space up  in to sub-spaces (a la CIDR).

All tools will have to support 64bit IDs rsn and we are currently
throwing away half of the ID space for no real good reason except
convenience. The main concern is that 64bits may not be enough ID space
long term: for example 63 bits for OSM proper would allow ~18'000 nodes
per square meter of the earth's surface (~62'000 without oceans), which
may not be enough for detailed multi-storey indoor mapping :-).  Such a
scheme would not preclude switching to larger IDs down the road (the ID
size is essentially just a practical limitation of the databases and
tools we are currently using) the individual layers would simply get
non-continuous ID spaces allocated if necessary .

Simon

PS: all calculations errors etc are mine :-)




More information about the talk mailing list