Postal vs 911 address city names

ezekielf · 2024-08-10T15:45:06.389Z

@Adam_Franco, that looks like a good technique for identifying general mismatch areas. Can’t identify every affected address due to non-resident owners as you mention. I think what I’m wondering, though, is whether this is worth worrying about in the first pass of adding addresses or not. It seems like the main use case for address date in OSM is for finding a location to navigate to and I tend to agree with @AntiCompositeNumber that the physical address is probably more useful for this. I guess ideally, a user should be able to find an address by entering either the physical city or postal city and I wonder if there should be two different tags for this. Dare I mention even more tags for alternately acceptable postal cities…

aighes · 2024-08-10T23:19:30.433Z

I think the definition in the wiki did not think about such cases but rather closed settlements and addr:city should refer to the “postal city” so it’s matching with the postal code and also make sure they all using the same “admin_level”. In rural areas like you pointed out, that might not make much sense. Though at least there should be a description or something to indicate the actual postal city. Especially for enterprises.

hoserab · 2024-08-11T01:39:56.561Z

We have the contact:street=*, contact:city=*, contact:house number=*, etc. tags where there is a mismatch between physical—what I think of as real—address, and an address at which someone may be “contacted” at.

Frankly I’ve always thought that the interpretation that addr:* tags were supposed to be “postal” addresses was nonsense in the context of Canada; it seems just as nonsensical in the US context. The only reason I can suss out that people ever “agreed” to this consensus was because in many countries—especially in Europe—mappers consider their national postal services more authoritative than any other political body for establishing addresses. It’s definitely not the case in North America. It’ll usually not deviate much between a “physical” and “postal” address, presuming a place even has a postal address. There are a great many buildings, domiciles, and points of interest that DON’T have postal addresses beyond a post office box or a rural route.

I wholeheartedly support a preference for so-called “9-1-1 addresses” rather than “postal addresses”. The former tells you where something is physically situated; the latter only tells you how to mail something to someone. Since OSM is after all a map we should give primacy to where stuff is.

ezekielf · 2024-08-11T22:33:36.953Z

hoserab:

I wholeheartedly support a preference for so-called “9-1-1 addresses” rather than “postal addresses”. The former tells you where something is physically situated; the latter only tells you how to mail something to someone.

This is generally how I started off thinking about this issue as well. However, after mulling it over I think it may not be quite so simple. Take for example, Harwood Union High School. The address listed on the school’s website and the address found in the VT E911 database match except for the city/town name.

Source	Address
Website	458 VT Route 100, Moretown, VT 05660
E911 Database	458 VT Route 100, Duxbury, VT 05660

As neither one is a post office box, these are both physical addresses. At first glance it would seem that the 911 address is more correct, since the school is located just inside the municipal boundary of Duxbury. However, it can also be argued that the website address is more correct since the school is much closer to the village of Moretown than the village of Duxbury. The USPS says it will also accept South Duxbury as a city name for addresses in the 05660 zip code.

It is reasonable to imagine that at least some people will use the Moretown form of the address to look up the location of this school since that is what is published on their website. Some may use the Duxbury form, and still others may use the South Duxbury form. Ideally a geocoder should be able to find the correct location with a search for any of these strings:

458 VT Route100, Moretown, VT 05660
458 VT Route100, Duxbury, VT 05660
458 VT Route100, South Duxbury, VT 05660
458 VT Route100, Moretown, VT
458 VT Route100, Duxbury, VT
458 VT Route100, South Duxbury, VT
458 VT Route100, 05660

For this to be possible it seems to me like tagging all commonly used cities names on an address node would be necessary. contact:city could be used in addition to addr:city but that only allows for two. Semi-colon separator? like so:

addr:city=Duxbury
addr:contact=Moretown;South Duxbury

addr:alt_city could be another option.

hoserab · 2024-08-12T01:59:37.349Z

I think what you’ve provided as an example here, with semi-colon-separated values in the alternate tag (whether you use addr:contact, contact:city or something else) is the most reasonable way of going about it. Doing my own sleuthing on the Duxbury and Moretown government websites, they both clearly show the boundary between them is where it’s shown on OSM, and the school in question is definitely within the bounds of Duxbury. As such, I think giving deference to addr:city=Duxbury is the more prudent approach, even if the school is closer to the “village centre” of Moretown.

I for one don’t always trust the contact info on the website of a POI to be “correct”. Local to me, the “house numbers” and postal codes often end up totally wrong on the contact details of businesses’ websites, e.g. listing the postal code for across the street or the next block down, or having the number of the adjacent building instead. I think a lot of these incorrect details simply come from extrapolations from Google Maps, and business owners not double-checking that they’re right.

Adam_Franco · 2024-08-12T13:59:44.839Z

I’m warming to the option of putting the enclosing municipality version addr:* tags and the “postal community” version in the contact:* tags.

This would lead to something like the following where the post office is named for the village of “Morrisville”, but the municipality is named “Morristown”:

addr:housenumber=18
addr:street=Lower Main Street
addr:city=Morristown
addr:postcode=05661

contact:housenumber=18
contact:street=Lower Main Street
contact:city=Morrisville
contact:postcode=05661

For locations where addresses are identical only the first addr:* version would be needed, but for locations where the postal city is different, then the contact:* version could be added. Given that “sending mail” is trying to contact someone, using contact:* makes more sense for the mailing address than the other way around. This also would make it abundantly clear what is being claimed by both sets of tags.

I don’t have any sense of support for the contact:* schema for addresses though. Do any support it at all? Would any geocoders support just the usage of contact:city and assume the rest of the details coming from addr:* or would the full contact:* version need to be filled out?

ezekielf · 2024-08-12T16:52:03.161Z

I’d hope we wouldn’t need to double tag all the address fields in the addr:* and contact:* scheme just because an address may use one of several city names. Ideally I’d want to tag something like:

addr:housenumber=18
addr:street=Lower Main Street
addr:city=Morristown
addr:alt_city=Morrisville
addr:postcode=05661

Similar to how alt_name and similar tags are used for variations of name.

What I’m realizing as I look at more and more examples is that there are many cases where there simply isn’t one “correct” city name, but instead there a few possibilities that are all in use. One may be more commonly used^[1], but that doesn’t mean the others are incorrect.

Adamant, VT is a hamlet within the municipality of Calais, VT that has it’s own zip code (05640). It also seems to have a strong local identity distinct from Calais despite being a part of it. I’ve looked up addresses for various points of interest in this area and so far they’ve all used Adamant, not Calais. Calais obviously wouldn’t be wrong to use (and the VT E911 database uses it), but Adamant is more specific.

That’s probably the one we’d want in the primary addr:city tag, but how commonly each city name is used by people is hard to determine. ↩︎

PeterCooperJr · 2024-08-12T17:07:56.485Z

It certainly is a challenge that

Which post office handles mail delivery to a location (that is, the last line of the mailing address)
Which municipality (or other local governmental structure) has jurisdiction over that location
What place someone says that location “belongs to” when speaking informally

can all be different things, and people don’t always realize which one they’re asking for or receiving.

hoserab:

I think a lot of these incorrect details simply come from extrapolations from Google Maps, and business owners not double-checking that they’re right.

And then there’s

where Google Maps says that it is,

which for some people really is what they’re trying to convey, since they’re trying to tell someone what to type into Google Maps to navigate to that location, regardless of whether that’s the “right” address in any other sense.

(Aside: I was somewhat-recently updating the Massachusetts Park and Ride locations on OSM, and the addresses on the state web site for them sometimes were clearly just “what the address looked like in Google Maps near there”, since they were sometimes the addresses for nearby buildings, or between buildings that there a little distance away, and/or were the wrong parity for the side of the road that the parking lot was on. The local government probably didn’t usually actually assign an address for a place that’s just a parking lot, but people want to figure out how to navigate to it just the same. And for better or worse, “type this into Google Maps to get there” is a good-enough solution for a lot of navigation problems for a lot of people.)

Adam_Franco · 2024-08-12T17:35:31.072Z

Doing some research on what data-consumers might be expecting…

Nominatim’s Proper support for postal towns in the US #1120 – From the discussion it sounds like Nominatim is actually doing area search for boundaries to find a matching “city”. Or maybe only if addr:city isn’t specified? I’m not sure.
OSMAnd doesn’t have an issue related to this exact problem, but US/Canada Addresses - not found #18924 and some testing seems to show that it does an “enclosed in” boundary search rather than looking at addr:city

Adam_Franco · 2024-08-12T17:37:50.835Z

According to TagInfo addr:alt_city is a pretty new tag that seems to have mostly been added in a single import: addr:alt_city | Keys | OpenStreetMap Taginfo

tekim · 2024-08-12T21:04:25.000Z

Thought 1:
Setting addr:city to the incorporated area in which the address is located is redundant - such information can be gained through a spatial query.

Thought 1B:
Boundaries for incorporated areas can change. Such a change would then make addr:city wrong if it was set based on the old boundary.

Thought 2:
What is addr:city set to for an address outside of any incorporated area? Is it to be omitted, or set to the “postal city”? If set to the postal city, then we are mixing two types of information in the same tag, and if the location is later incorporated into a city other than the postal city, it will be wrong.

Thought 3:
If you were to order something from an online retailer and have it sent to the address in question, what city would you enter as part of the address? Even though we are using the term “postal city”, it is my understanding that most online retailers and delivery companies (e.g. UPS, FedEx) use the same cities as part of their addressing.

AntiCompositeNumber · 2024-08-13T00:52:51.490Z

tekim:

Thought 3:
If you were to order something from an online retailer and have it sent to the address in question, what city would you enter as part of the address? Even though we are using the term “postal city”, it is my understanding that most online retailers and delivery companies (e.g. UPS, FedEx) use the same cities as part of their addressing.

It depends where they bought their address data from. UPS and FedEx have the advantage of being able to pre-validate addresses when the shipping label is created, instead of accepting handwritten address blocks. ups.com and fedex.com use Google Maps for geocoding and then appear to match against the USPS City-State and Five-Digit ZIP databases. It wants to correct North Faystown and South Duxbury to Moretown, VT but will accept Duxbury. Other software will use different geocoding but I’d expect it to perform the same validation.

For another point of comparison, every non-online GPS I’ve used has used the geographic city name rather than the three village names in Vermont I’ve previously mentioned. They will also distinguish addresses in Example, NJ from addresses in Example TWP, NJ and refuse to navigate if you pick the wrong one.

ezekielf · 2024-08-13T01:54:49.264Z

PeterCooperJr:

can all be different things, and people don’t always realize which one they’re asking for or receiving.

This is very well said. It seems to me that what we ideally want in addr:city is the city/town/community name that the residents of the address would tell you if you knocked on their door and asked. I’m going to make an educated guess that this would frequently be the most specific of the USPS recognized city names in cases where there’s isn’t just one option for a particular zip code.

willkmis · 2024-08-13T02:07:51.611Z

tekim:

Thought 1:
Setting addr:city to the incorporated area in which the address is located is redundant - such information can be gained through a spatial query.

I agree with this point, and that’s why I’m definitely in favor of the postal address for addr:city. I mostly feel this because it’s very necessary in my area: within the City of Los Angeles there are a variety of ‘postal cities’ that do not correspond to government boundaries, but which may repeat addresses between them. For instance, both Way: 427942818 | OpenStreetMap and Node: ‪Off the Wall Art Designs‬ (‪10863489700‬) | OpenStreetMap are within the city boundaries of Los Angeles and have the address 319 West 6th Street, but one has postal city ‘Los Angeles’ while the other has postal city ‘San Pedro’, as reflected in the current addr:city tags. Tagging the San Pedro address as addr:city=Los Angeles, or even really some alt tag, would be very confusing, and IMO strictly wrong. Both nodes’ location within Los Angeles city boundaries can be inferred from geometry, so I don’t see why a separate addr:city and contact:city tagging is necessary. Just for reference, a local in the latter location would say they were in San Pedro, but would probably know that they were also within the City of Los Angeles.

Perhaps this is a tangent though, since I have no idea what the ‘911 addresses’ of these places are.

Jarek · 2024-08-13T02:23:52.212Z

(Following this thread with interest. Up here in Ontario I’ve been struggling with cases where Canada Post and the local government disagree about spelling of some street names. I’m never sure which to use. And we also still have a few postal cities that have ceased to be municipalities 20 years ago, due to amalgamation.)

n76 · 2024-08-13T03:01:56.743Z

willkmis:

I agree with this point, and that’s why I’m definitely in favor of the postal address for addr:city. I mostly feel this because it’s very necessary in my area: within the City of Los Angeles there are a variety of ‘postal cities’ that do not correspond to government boundaries,

For quite a few years I lived near and worked in the San Fernando Valley area of Los Angeles. Probably 3/4 of the postal cities there are simply named areas within the City of Los Angeles. I think only San Fernando, Burbank, Calabasas and maybe Hidden Hills are separate cities. Glendale is a separate city but only really touches the SF Valley. All the others, places like Studio City, Van Nuys, Tarzana, Woodland Hills, Chatworth, Northridge, Granda Hills, etc. are all officially just parts of the large city of LA.

But the USPS and locals, news media, etc. use those local names. LA is “over the hill” from “The Valley” and you’d never give directions, mail, or ship (USPS, FedEx, UPS, etc.) with LA as the city in the address field.

So I’d put the postal name in the addr:city field.

Corollary to that is the addr:city value should be one of the USPS recognized values for the ZIP code.

For what it is worth, our current house was once a duplex and when we moved in we received a lot of mail to “Unit A” and/or “Unit B”. And we had some mail order forms that insisted we give them a unit or apartment number.

I went to the post office to get our address information corrected. I was told they get their data from the county. And on further investigation, it turns out that for incorporated cities, the county gets address data from the city. This leads me to believe that, at least in Orange County in California, the 911 address likely matches the city, county, and for my area, USPS address.

Years later we still occasionally get mail to Unit A or Unit B but at least now we are not forced to add a fictitious unit number to an Internet purchase form. Amazing how long it takes for corrections to percolate through various databases.

hoserab · 2024-08-13T03:43:14.781Z

The only things Canada Post definitively, authoritatively knows are postal codes; any deviation in street name spelling is a typo on their part. Personally I would very, very strongly give precedence to local sources and summarily ignore Canada Post’s info.

hoserab · 2024-08-13T04:19:34.863Z

tekim:

Thought 1:
Setting addr:city to the incorporated area in which the address is located is redundant - such information can be gained through a spatial query.

Right; the premise of this conversation is the edge cases where this isn’t obvious. For the vast, vast majority of places this entire conversation is moot because the addr:city such as we know it in OSM isn’t in question, and can just be easily gained through a spatial query.

willkmis:

Just for reference, a local in the latter location would say they were in San Pedro, but would probably know that they were also within the City of Los Angeles.

Perhaps this is a tangent though, since I have no idea what the ‘911 addresses’ of these places are.

This isn’t a tangent, I think you’re driving at the very heart of the matter, and this is a great example of where you really do need to distinguish with that addr:city tag. Given there is a distinct numbered street grid in San Pedro, even though it doesn’t have its own municipal government, I would presume anybody in the LA area would distinguish San Pedro from the rest of LA because otherwise you wouldn’t necessarily know if you meant an address downtown instead.

All a “9-1-1 address” is is the address you would give a 9-1-1 operator in an emergency. I would presume if you called 9-1-1 for an ambulance and they asked where you were, if you’re in San Pedro you’re very pointedly going to say so, and they’re going to know precisely what you mean.

ezekielf · 2024-08-13T14:54:23.578Z

Certainly, if it were true that the city name used in an address was always the same as the containing municipality name (setting aside those in unincorporated areas) then an addr:city tag containing that name would be redundant. However, as this discussion shows, this is not the case. Populating addr:city in the many cases where the address city name differs from the municipality name is clearly beneficial, but even when they do happen to match I’d argue there is still a benefit.

The municipality of Fayston, VT is covered by two different zip codes - 05673, and 05660. For each of these zip codes, the USPS calls out Fayston and North Fayston as city names to avoid. For the 05673 area of Fayston, the city name Waitsfield is used instead and for the 05660 area, Moretown is used. A data consumer doing a spatial query for the containing municipality name here would end up with the non-preferred city name of Fayston. The 05673 zip code also fully covers the neighboring municipality of Waitsfield. There a spatial query would give the preferred address city name since it happens to match the municipality name. Querying for the containing municipality name is a good fallback when addr:city is not tagged, but in this case there is no way for a data consumer to know whether it is the preferred city name for addressing or not. Despite being redundant, if addr:city=Waitsfield is explicitly tagged within the municipality of Waitsfield this indicates that indeed the preferred city name for addressing matches the municipality name, unlike neighboring Fayston where it does not.

The reason I started this thread is that (in my state at least) the state E911 database and US National Address Database (NAD) do not contain the postal city name, only the containing municipality name. Addresses from these data sets are being added via MapWithAI/Rapid and are populating non-preferred city names in these edge case rural areas. While these city names clearly aren’t exactly “wrong”, they will likely not be what locals expect or search for when attempting to find an address.

hoserab · 2024-08-13T17:58:04.574Z

Are they not what locals expect or search for when attempting to find an address, though…?

When you write “non-preferred city names”, non-preferred by whom?