[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