>> but the polygon is still a much better approximation that you would get with >> just a node. While a node be able to tell you "unincorporated the stuff >> north of Arcata is McKinleyville" it wouldn't convey that "west of 101 and >> south of the river is not McKinleyville". > Problem is if Arcata expends by annexing part of McKinleyville. The > CDP boundaries will then be changed to include only the unannexed > part, but the whole thing remains McKinleyville in common usage. Well then things get complicated :). There would still be meaningful polygons describing both, and depending on what the common usage ended up being I there could be a good argument for having the polygons overlap. But the fact that the CDP is suboptimal would be a bad reason to delete it without drawing a better boundary.
>> >>>> Place nodes are worse than useless >>> Perhaps you mean "useless for searching", since if something is worse >>> than useless it should be deleted. >> >> I do actually think most place nodes that have a corresponding polygon >> should be deleted, but I know that there's strong support for keeping them >> for rendering purposes. In theory tools should know that when there are both >> the polygon is more meaningful but most don't, and there are also cases >> where the tags are out of sync between point and polygon. > > How would you mark the cultural center of a place (downtown for most > incorporated and some incorporated communities) then? Fair point, but the "most incorporated" is still a rather vague thing to tag. I'm not going to go deleting them in the main database just because they aren't useful to me, but I do take them out of my local mapnik renderings. >>> >>>> as demonstrated by the associations Nominatim generates from them. (e.g. >>>> it thinks my home street is part of a trailer park several miles away). >>> That's partly Nominatim's fault and partly our fault (presumably the >>> trailer park is tagged with a misleading place=* value). A better >>> algorithm might be (if it's not inside a polygon) to give distances to >>> nearby place nodes, rather than choosing the closest. >>> >> The problem comes from the fact that the trailer park was a "hamlet" inside >> of a "city", but then there are legitimate cases for nesting like that, and >> there's no way for Nominatim to tell the difference if there are only nodes. > place=hamlet is misleading for a trailer park. If it's inside a city, > it's probably best to use place=neighborhood. If Nominatim didn't ignore neighborhood (which I hope gets fixed at some point) it would still generate the same problem on a node as hamlet. > >> >>>> If you think the boundaries are wrong move them (or even better ask people >>>> on the ground what the name of the place they live is, which is probably >>>> how the census ended up with them in the first place). >>> I have been replacing the CDP polygons in central Florida for a while >>> with better-defined neighborhood polygons roughly based on platted >>> subdivisions and zoning. The CDP boundaries were not useful for any of >>> these, even as starting points. >> Then you should delete those specific ones and replace them with a better >> boundary, just please not only a node. > > You're assuming the existence of a suitable non-fuzzy boundary. Just about any human drawn fuzzy boundary will be more informative than "an arbitrary distance from this dot". >> >> Also, how are you going to verify something is "only used for census >> purposes"? > If it's not in GNIS, for example, that means it's not on USGS or other > government maps, which narrows down the field considerably. Then I can > see if the name is used by the local newspaper, for instance. An > example is "Zephyrhills South" - it's just the census name for the > unincorporated area south of Zephyrhills. How would you denote the unincorporated region around Zephyrhills? _______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
