[Talk-us] San Diego Address Import Update

Tod Fitch tod at fitchdesign.com
Tue Nov 10 05:48:59 UTC 2015


> On Nov 9, 2015, at 8:42 PM, Richard Welty <rwelty at averillpark.net> 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.


More information about the Talk-us mailing list