[Talk-us] Admin boundaries tied to roads

[Apollinaris Schoell]

On 23 Apr 2010, at 7:13 , Lord-Castillo, Brett wrote:

> On 19 Apr 2010, at 20:24, Apollinaris Schoell wrote:
>> On 19 Apr 2010, at 20:07 , Alan Mintz wrote:
>>> Not to mention that merging them will result in the inability to hide these 
>>> boundaries. When doing a bunch of editing on a road that follows one, in 
>>> the past, I've taken the time to verify that the boundary doesn't share any 
>>> nodes with anything and then remove it from my local OSM file manually so I 
>>> don't have to constantly deal with it. If it shares nodes with anything 
>>> else, this is no longer possible.
> 
>> fully agree, the good thing is these boundaries are tiger data and bad data anyway and should be replaced with better boundaries
> 
> While I understand the mantra of TIGER=Bad because of the state of the road data, this is not true for the boundary data. Most of the boundary data comes directly from recorded surveys (something not available for roads) and is not "bad data" for most of the United States. The rural areas would be the one exception (mostly because they did not have surveys converted to digital layers in 2000), but rural areas are also highly likely to have realigned boundary roads that no longer correspond to the original boundaries.
> 

I can tell for sure that they are completely wrong in California. They are not even close to USGS 24k, don't align with official county borders from official sources and don't align with natural features, fences which are sometimes visible on Yahoo. 


> --Brett
> Brett Lord-Castillo
> Information Systems Designer/GIS Programmer
> St. Louis County Police
> Office of Emergency Management
> 14847 Ladue Bluffs Crossing Drive
> Chesterfield, MO 63017
> Office: 314-628-5400
> Fax: 314-628-5508
> Direct: 314-628-5407
> 
> 
> 
> -----Original Message-----
> Date: Mon, 19 Apr 2010 20:24:47 -0700
> From: Apollinaris Schoell <aschoell at gmail.com>
> Subject: Re: [Talk-us] Admin boundaries tied to roads
> To: Alan Mintz <Alan_Mintz+OSM at Earthlink.Net>
> Cc: talk-us at openstreetmap.org
> Message-ID: <B356F39B-6758-4AB3-A05C-49828702DB8F at gmail.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On 19 Apr 2010, at 20:07 , Alan Mintz wrote:
> 
>> At 2010-04-19 10:45, Mike N. wrote:
>>> I see that the separate VS tangled argument has been settled in the US by
>>> the "Duplicate Node attack bots", who have blindly merged all duplicate
>>> nodes.
>>> 
>>> http://www.openstreetmap.org/browse/way/38855677
>> 
>> Is this really happening? Can someone describe exactly what criteria are 
>> being used, and just how it was decided that this was a good idea? Seems 
>> like the wrong thing to do - city and county boundaries are often defined 
>> in law, or by survey, and do not necessarily keep up with changes in road 
>> alignment. I have resisted editing most of these boundaries until/unless I 
>> take the time to research the true definition of the boundary.
>> 
>> Not to mention that merging them will result in the inability to hide these 
>> boundaries. When doing a bunch of editing on a road that follows one, in 
>> the past, I've taken the time to verify that the boundary doesn't share any 
>> nodes with anything and then remove it from my local OSM file manually so I 
>> don't have to constantly deal with it. If it shares nodes with anything 
>> else, this is no longer possible.
> 
> fully agree, the good thing is these boundaries are tiger data and bad data anyway and should be replaced with better boundaries
>> 
>> Sounds a lot like the IMO ill-considered road name expansion that was 
>> apparently agreed upon by a small group of people without input from the 
>> majority of active mappers whose work has been damaged.
> 
> agreed, no idea why this was done. it's a change without much benefit but lot's of damage. 
> 
>> 
>> --
>> Alan Mintz <Alan_Mintz+OSM at Earthlink.net>
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us