Postal vs 911 address city names

Communities United States
,
1

I’ve recently been adding addresses from the State of Vermont E911 Address dataset (VT-E911). This data also feeds into the US National Address Database (NAD) and both datasets are available to use via Rapid and the JOSM MapWithAI plugin. An issue I’ve run into is that since these are 911 addresses focused on physical location, the city name of a particular address node seems to always match the municipal boundary containing it. However, the wiki says that addr:city should match " the postal service city [which] is the name of the USPS post office that serves the address’ ZIP code".

This address was added from the NAD and is tagged addr:city=Westford, addr:postcode=05452. It is physically within Westford, but the preferred postal service city for 05452 is Essex Junction (Essex is also acceptable to the USPS).

Is this a problem or not really? If it is a problem, what should be done about it? I’m not really sure what a reasonable workflow would be for identifying areas where the physical/911 city and the postal city differ. The postal city is also not something that can generally be surveyed on the ground. If addr:city really does need to be the postal city, should there be an alternate tag for the physical/911 city in areas where they differ? Or should geocoders be pulling in name, official_name, etc from the containing administrative boundary?

1 Like
2

This really comes down to the postal addressing vs physical addressing question. Postal addresses contain a lot of idiosyncrasies in the US that most users do not know about, need to know about, or care about. I’ve mentioned before about a local trailer park where the Town and the USPS can’t agree how the lots should be numbered: the streets are named and the houses have numbers, but if you try to send mail to them it’ll be returned undeliverable. The USPS numbers and addr:place would be almost entirely useless to someone navigating in the neighborhood, so I don’t tag them.

As far as postal city goes, the USPS classifies place names into three different categories: the recommended city name, other recognized city names, and unacceptable names. My town has two towns next to it without their own post office or ZIP code, and they are both listed as other recognized city names. However, if I try to send mail to someone I know in an even smaller town in Vermont, I have to send it to the correct post office because they have three for some reason. The only way to get this correct is to use the proprietary USPS databases, which we can’t.

Another complication is that the E911 address data is likely more accurate than the TIGER boundaries currently in OSM, and I’ve found at least one instance where the boundaries are off by a significant amount compared to the address data in New Jersey.

Some mappers only map addr:housenumber and addr:street, expecting data consumers to infer the rest from the boundaries. I haven’t seen a data consumer actually do this.

I’d prefer to tag physical addresses most of the time, as it’s closer to what people would normally expect for navigation. I would not replace an “other acceptable” city name with the preferred USPS city name, as it’s more likely to be confusing than helpful, and would not prevent mail from being delivered. This is why ZIP codes were invented, and they should be used for that.

1 Like
3

This is the issue that tripped me up when trying do an import (still not performed) a few years ago. See Some addresses may have postal cities different from their municipality · Issue #15 · JaredOSM/vermont-address-import · GitHub for what I found.

Toward the end of the thread is a technique that might be helpful: I analysed the property data set to compare owners’ postal addresses to the property address and looked for cases where the Street portion of the property and postal addresses match, but the enclosing municipality doesn’t match the postal addresses’ “city”.

I didn’t take this further, but did identify over 21,000 addresses that would probably have this mismatch.

1 Like
4

@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…

5

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.

6

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.

2 Likes
7

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.

2 Likes
8

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.

9

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?

1 Like
10

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.

  1. 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. ↩︎

11

It certainly is a challenge that

  1. Which post office handles mail delivery to a location (that is, the last line of the mailing address)
  2. Which municipality (or other local governmental structure) has jurisdiction over that location
  3. 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.

And then there’s

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

1 Like
12

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”. :grimacing: 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

13

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

14

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.

15

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.

16

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

2 Likes
17

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.

1 Like
18

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

19

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.

20

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.

1 Like