[Talk-us] Neighborhoods / Zillow

[Serge Wroclawski]

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.

> For
> the latter, these are fluid enough that they can come and go, move and
> change name.

Did you watch the Flickr talk on their neighborhood data that they
presented at SoTM US 2012 (last year)? In that talk, they presented
their findings which show that people's idea of place is very fluid.
The key factor for me is that two parties with vastly different views
on a neighborhood are both right, and that makes agreement nearly
impossible. There is no ground observable data to use. OSM is
predicated on ground observable data. That's why we don't support
other subjective data like restaurant ratings.

If the argument was simply that a neighborhood exists, then maybe one
could come to some sort of a consensus, but the problem is that both
the models that have been talked about are flawed, and do cause
problems. The issue with polygons has been discussed at length, so let
me address the issue with nodes.

A node as an indicator of place can generally have two semantic
meanings in OSM. Either it can be in the geographic or cultural
center[1].

The problem is that in absence of more information about an area, the
tools which consume the OSM data take a node to mean an area, which
they must then calculate via an area around. The result is often quite
messy and problematic. For example, here in New York, I've had to
address some neighborhoods which were spilling into areas they didn't
belong. But I wouldn't blame the geocoder for not realizing that the
Upper West Side is more north to south than east to west[2].

In a more extreme example of why node areas are bad, a portion of
Washington, DC was claimed to be in Fairfax City, because Fairfax was
represented by a node.

Fixing these problems is a major undertaking, one I wouldn't subject a
friend to.

> Once again:  OSM accommodates by storing, displaying
> (uniquely!) and indexing both types of data.

This has not been born out over time, though. I'm just trying to avoid
a lot of work later.

> While this discussion is good, I don't think a "one polygon (or one node)
> fits all" solution will work across the very wide diversity of
> "neighborhoods" in the USA.  Accordingly, let us allow some minor small
> smears of syntax (multiple solutions) to capture multiple semantics.  It
> doesn't hurt anything, and nobody pretends there is a standard way to
> "properly map" every single thing in OSM we wish to map, just high-quality
> representations of things (which are all of captured in the database,
> rendered, and indexable).  Both polygons and nodes for neighborhoods do all
> three of those, and sometimes a polygon is better than a node (or vice
> versa), so I continue to believe using both is OK.

I am glad you're seeing that there's no single solution, but please
consider what I'm saying about the past and let it inform your
decision making.

- Serge