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 :-) _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
