On 2013-06-15 6:51 PM, Serge Wroclawski wrote:
On Sat, Jun 15, 2013 at 6:35 PM, stevea <[email protected]> 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 <[email protected]> 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
_______________________________________________
Talk-us mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-us
