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

Daniel Sabo danielsabo at gmail.com
Fri Nov 12 06:34:31 GMT 2010



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.

On Nov 11, 2010, at 9:21 PM, Nathan Edgars II wrote:

> On Thu, Nov 11, 2010 at 11:23 PM, Daniel Sabo <danielsabo at gmail.com> wrote:
>> I would oppose deleting them. They do have real world significance because they represent community boundaries in unincorporated areas,
> No they don't, except coincidentally. For example
> http://en.wikipedia.org/wiki/Lake_Butler,_Orange_County,_Florida is a
> name apparently made up by the Census Bureau. In many other cases the
> names are real but the boundaries are bogus, often expanded to fill
> the space between incorporated communities.
> 
>> and the name that you would use to search for an address these communities.
> Maybe, maybe not. Often the USPS uses a nearby incorporated place, and
> the CDP name would not be valid. Sometimes the actual incorporated
> community that has jurisdiction over a place is not accepted by the
> USPS.
> 
>> McKinleyville, CA (http://en.wikipedia.org/wiki/McKinleyville,_California) is as much a defined community as Arcata or Eureka to the south of it even if it only exists on the map as a CDP.
> It's definitely a defined community, but are the boundaries really
> well-defined? What makes the south side of Baird Road part of it but
> the north side not?
> 
Not a whole lot beyond the fact that TIGER loves to overuse roads for admin boundaries, 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".

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

Also, how are you going to verify something is "only used for census purposes"?


More information about the Talk-us mailing list