[Talk-us] Neighborhoods / Zillow

[stevea]

>On 2013-06-15 6:51 PM, Serge Wroclawski wrote:
>>On Sat, Jun 15, 2013 at 6:35 PM, stevea <steveaOSM at softworkers.com> wrote:
>>
>>>For the former, I don't need a painted line on the ground, just what the
>>>City GIS department publishes on the open Internet, after these
>>>lines/polygons/neighborhood boundaries were reached by public process.
>>
>>There is a growing number of OSM folks in the United States (myself
>>included) who believe that government provided boundry data should be
>>used for data products such as rendered maps and geocoders, but do not
>>belong in OSM's core dataset (which is built around the idea of
>>improvements based on local, verifiable observation).
>>
>>The result is that for data of the type you're talking about
>>(government provided polygons), I think they'd be best provided as a
>>third party service.
>>
>>And for the more subjective neighborhood boundaries, by its nature, it
>>doesn't belong in OSM either.

Minh Nguyen <mxn at 1ec5.org> writes:

>But there's a third kind of neighborhood data: objective data that 
>doesn't come from a government database.
(and continues):
>Different cities developed in different ways. OSM should encourage 
>neighborhood data curated by locals aware of the city's history. 
>Perhaps this kind of data is more suitable for display, while 
>algorithmic solutions may be better for geocoding.

In my opinion, Minh's thoughtful discussion here is an outstanding 
(short) treatise supporting reasonable wide definitions (nodes, 
polygons, government data, directly "on the ground" observable data: 
differing histories of city and neighborhood development needing a 
rich set of multiple syntax) for neighborhood data in OSM.

Again, this is not a "one solution fits all situations" problem, in 
this thread we have seen that over and over.  Let's continue to allow 
OSM to capture observable data (including aerial and satellite 
imagery) and local government-produced data alike, whether as nodes 
or polygons, as appropriate.  Many other features allow for both 
types of data structures, neighborhoods really are no different.

Algorithms which "simply" (wrongly, in many cases) extrapolate a 
neighborhood derived from a centroid deserve what they get:  often 
erroneous answers as to the question "is THIS in this neighborhood?" 
Let them tune their geocoding algorithms to be more clever instead, 
and answers will surely become more correct.

SteveA
California