On Sat, Jun 15, 2013 at 6:35 PM, stevea <stevea...@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 _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us