[OSM-dev] Multiple layers in the database

Robert (Jamie) Munro rjmunro at arjam.net
Sun Mar 16 12:05:42 GMT 2008

Hash: SHA1

Gervase Markham wrote:
| 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.

Why not just upload stuff with a osimport:highway=[whatever], then it
won't be rendered on any maps. JOSM could have tools separate it into
another layer if needed, and you could select and delete either the
original or the OS layer with JOSMs search features. A special layer
could be added to T at H (or mapnik when we get multiple layers going) to
show areas where the OS tagging hasn't been resolved, or to show only
the OS layer or whatever.

Robert (Jamie) Munro
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list