I see now the problem with merging boundaries and waterways. In many places the boundaries are still close enough to the riverbeds and they are better than any other information we have. So I mistakenly assumed that today's meandering boundaries were identical (and shifting) with the actual riverbeds, and not with historical ones. My mistake, sorry, I started to unmerge the boundaries I merged last year.
On 03.08.2012 16:35, Simon Poole wrote:
The only merging I do and find acceptable is landuse to landuse. But please not to roads, buildings and similar.
On the other hand, I don't see a problem with merging shared ways of area multipolygons of an kind. Why not merge a lake with a meadow or a building with a pedestrian area in front of it?
When it comes to merging roads with areas, I still do like the idea of it, roads are often the "natural" limits of those areas. But I also see the difficulty and error potential that this creates for beginners.
Overlapping ways sharing the same nodes are often used as an alternative to merging, but you never see how many ways are in that "bundle". Well, in JOSM you can use the middle click to check what's all there, but for beginners that's not obvious either.
I've been toying with the idea of proposing a seperate (but still editable by normal OSM mebers) database for boundary data. Since we all will have to change to 64bit ID databases rsn, we would now have the opportunity of chopping of a couple of high bits as separate ID spaces which would make it trivial to use the same infrastructure and keep the data mergable without id conflicts. A bit hackish I admit but really easy to do.
Sounds good to me, but wouldn't that require a worldwide solution?
Thorsten (Shernott)