[OSM-dev] Multiple layers in the database

Gervase Markham gerv-gmane at gerv.net
Sun Mar 16 08:53:40 GMT 2008


Prompted by the recent release of the trading funds report 
(http://www.freeourdata.org.uk/blog/?p=180), I was dreaming about what 
might happen if the Ordnance Survey suddenly decided to make their data 
freely available. How would we integrate it with the main map?

We've had this problem on a smaller scale with TIGER/LINE. As I 
understand it, the data was simply uploaded into the main map, and then 
any areas where mapping had already been done were resolved and 
de-duplicated by hand. Is that correct?

It seems to me that it might be much better to start having the concept 
of multiple layers in the OSM DB. So one could upload a large 
contributed data set to a new layer, and then merge the two together 
slowly. But, and this is the key point, during the process things like 
the slippy map would just render the "main" layer - thus avoiding an 
extended period of time where the map was unusable due to lots of things 
being on there twice.

Clearly, this would require a tweak or two to the DB (a "layer" value 
for each object), the API (you'd need a way to request non-default 
layers for a particular bbox) and e.g. JOSM (although it already has the 
concept of different layers of OSM data). But I think it would help us a 
great deal.

As OSM gets better, it's much more likely that data donations will cover 
areas where work has already been done. Having a good way to merge the 
two while keeping the map usable during the process is, it seems to me, 
important.

What do people think?

Gerv





More information about the dev mailing list