[OSM-talk] Boundary editing (was Zero tolerance on imports)

2011-03-06 Thread Toby Murray
I have been thinking about this lately as well. In particular city/county boundaries. I realize this is specific to the US but the way a lot of our boundaries were imported from TIGER data makes them very prone to well meaning but ultimately bad edits by mappers. Basically, there is ALWAYS a node

Re: [OSM-talk] Boundary editing (was Zero tolerance on imports)

2011-03-06 Thread Peter Wendorff
Hi Toby. Am 06.03.2011 20:19, schrieb Toby Murray: When I am doing normal editing I usually have a JOSM filter enabled to hide boundaries because I don't care/know/want to touch them. What about making such a filter default in the popular editors? If someone WANTS to edit a boundary, they can

Re: [OSM-talk] Boundary editing (was Zero tolerance on imports)

2011-03-06 Thread Toby Murray
On Sun, Mar 6, 2011 at 2:28 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: These filters would not solve the problem. If boundaries are filtered and not displayed, moving a way with a common node leads to the same error - but as the boundary is not displayed, it's even harder to recognize

Re: [OSM-talk] Boundary editing (was Zero tolerance on imports)

2011-03-06 Thread Ed Avis
Toby Murray toby.murray at gmail.com writes: Basically, there is ALWAYS a node whenever one TIGER feature crosses another, regardless of what kind of feature it is. This leads to duplicate nodes sitting on top of each other which the various validators complain about. So people tend to merge them

Re: [OSM-talk] Boundary editing (was Zero tolerance on imports)

2011-03-06 Thread Toby Murray
On Sun, Mar 6, 2011 at 3:09 PM, Ed Avis e...@waniasset.com wrote: Perhaps the answer is to remove some of the spurious nodes which were automatically added, when they are at the intersection of two straight lines (in other words, when removing the node would not change the path of any ways