Hi Simon,
On 03.08.2012 11:30, Simon Poole wrote:
Please DON'T merge, in fact please do not merge ANYTHING with boundaries from the SwissTopo import.
Could we make an exception for boundary stones like this one
http://www.openstreetmap.org/browse/node/1373040900/history
or should I remove it and create a separate node for it?
- merging the data increases the probability of editing errors impacting the boundaries by a gigantic amount
The biggest source of boundary errors IMHO is their bad visibility in most editors. I don't know how often I find nodes of highways, landuse and other stuff stuck to boundaries. If you don't pay attention and detach these nodes before moving them, off goes your boundary. And there won't even be an visible error, except if you regularly run a bot that checks for shared nodes on boundary ways.
I'm wondering if this kind of DO NOT TOUCH information wouldn't be better kept in a different layer alltogether, at least as some kind of a backup that can be restored on a regular basis.
Thorsten
On 03/08/12 12:19, tnk@gmx.net wrote:
The biggest source of boundary errors IMHO is their bad visibility in most editors.
It has nothing to do with boundaries. Anything that is merged is difficult to see. That's why I think merging should usually be avoided.
datendelphin
The only merging I do and find acceptable is landuse to landuse. But please not to roads, buildings and similar.
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.
Simon
Am 03.08.2012 14:01, schrieb Datendelphin:
On 03/08/12 12:19, tnk@gmx.net wrote:
The biggest source of boundary errors IMHO is their bad visibility in most editors.
It has nothing to do with boundaries. Anything that is merged is difficult to see. That's why I think merging should usually be avoided.
datendelphin
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
Datendelphin -
Simon Poole -
tnk＠gmx.net