> On Nov 9, 2015, at 8:42 PM, Richard Welty <[email protected]> wrote:
> 
> maybe but i would do some more research before making an assumption.
> i'm aware of many postal city addresses that are in different counties
> than the
> "real" cities and i believe there are at least 4 cases where postal delivery
> crosses state lines.
> 

What is a “city” in US specific OSM terms?

I prefer a postal city definition as that is the most useful for routing 
purposes which I feel is the primary use of address data in OSM. Or are we 
dealing with some other concept of addr:city?

Using Pine Valley, California, as have been my examples for other posts in this 
thread, I see the administrative boundary for the city San Diego is probably 30 
miles away: The locations are neither within the boundary nor in the postal 
delivery area for the city of San Diego. To me that clearly indicates the 
addr:city=“San Diego" tags is wrong.

So what value to use for the addr:city tag values? There is an administrative 
boundary around the area that looks like it is from the original Tiger import 
with the name of “Pine Valley” as a “locality”. There is a post office there 
with a “Pine Valley” sign on the building. The ZIP codes that were imported on 
the change set for this area all are set to 91962. When I look up 91962 on the 
USPS official web site it returns “Pine Valley, CA” and only “Pine Valley, CA”. 
The USPS result page also says "Please use the default city whenever possible” 
which indicates they think everyone should use “Pine Valley”. There is no 
county, state or national border near by to confuse the issue.

Looking at adjacent “towns” (may only be census designated areas) I see the 
same thing. Just look at Guatay, CA a little west on the old main highway and 
you will see the same thing.

So what “more research before making an assumption” should be done in this 
area? I suspect a theoretical problem with a hypothetical general case is be 
being brought up when what I see in the data is a pretty straight forward issue 
of bad data that can be corrected.
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us

Reply via email to