[Talk-us] Proposal: delete census-designated place polygons

Daniel Sabo danielsabo at gmail.com
Fri Nov 12 08:14:30 GMT 2010

>> 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?

More information about the Talk-us mailing list