I’d finally like to clean up the implementation around directional name prefixes and suffixes for US highways in Nominatim in order to improve searchability for addresses.
As far as I can tell, there are the following cases to consider:
directions (North/East/South/West) may be used as prefix or suffix
directions may also appear in the proper name of the street (North 300 East)
the directional prefix/suffix may or may not appear on the street sign
the directional prefix/suffix may or may not appear in the postal address
These variants can appear in combination, including the variant where the directional prefix/suffix is neither signposted nor in the address but still an official part of the street name
My suggestions for a generalised handling of directional information would be:
name of the highway contains whatever is signed on the street sign
addr:street on address objects contains whatever is the correct form in the postal address
name:prefix or name:suffix are added to the highway as appropriate to mark the presence of an optional directional prefix/suffix
if the prefix/suffix is mandatory, then name:prefix and name:suffix can be omitted
directional prefixes/suffixes must always be spelt out (no N/E/S/W)
This should be sufficient to resolve any discrepancies between different versions of the street names and cover all the variants mentioned above. Well, except for the variant where the direction can go in front or after the street name. Is that a thing? Are there areas in the US where prefix and suffix notation are used as the same time for the same street? Or would it be pointless to support that because it is always either prefix or suffix? If it’s a thing in a few exceptional cases then a tagging convention where both name:prefix and name:suffix are added would be preferable.
This handling would be compatible with the Utah naming conventions for their grid system, so no changes required there. It is one of the areas where search would finally just work in all cases.
Of course, this works out only if the US community would be committed in the long run to make more use of name:prefix/name:suffix, in particular for the cases, where the directional prefixes/suffixes don’t appear on the street sign and are therefore largely missing in OSM.
I’m not opposed to this in principle, though it would require everyone to get on board with a nationwide retagging campaign.
This is not a case I’m aware of. When present, the cardinal direction is always necessary address information.
If name and addr:street diverge, we would need to update editors like iD so that they could construct a proper addr:street value based on the name:prefix and/or name:suffix tags.
They’re not meant to be interchangeable - there should only be one correct form. But if you get it mixed up, your mail will still be delivered to the right place in most cases.
There are also areas where the street sign does not correspond to the name at all. For instance, the name of the street below looks like it’s North 54th Street, on the 1200 East block. Seems simple, right?
However, this is actually the intersection of 9th Avenue Southeast and South Maple, and I have express requests from the local authorities to put the address name on the map (it’s cheaper than fixing the signage).
I personally disagree with the Utah conventions, as I feel it is unnecessarily confusing. In South Dakota I’ve been adding the directionals everywhere they are needed to name and not using name:prefix /name:suffix.
It is not entirely clear to me what changes you’re proposing from current practice here? The US convention as far as I am aware is that name should match whatever is signed, with all abbreviations expanded, unless local knowledge is such that the names people use and/or are in addresses are different from the signs in some standard way. I had never heard of the name:prefix tag before, despite living all over the US. It appears to be mostly used in Utah and rarely elsewhere: name:prefix | Keys | OpenStreetMap Taginfo United States of America . name:suffix is even rarer, it only has 90 uses in the US. I defer to Utahns for how they tag their streets, which follow a fairly unusual convention anyway, but I don’t think this tagging is needed in much of the rest of the US, where the convention is to tag the full street name in name. But maybe you have an example not from Utah that trips up Nominatim?
Another minor piece to be aware of (you probably already are) is that ordinal directions (Northwest, Northeast, Southwest, Southeast) are also common prefixes and suffixes in many areas.
To be clear for those who don’t know, name:prefix=* (and name:suffix=* and name:full=*) was a proposal originally written by a Utahn to handle Utah addresses. Before I joined OSM, the proposal was never finished and marked abandoned, but entered use anyways.
The problem that name:prefix=* aims to solve is that the street name on the sign and in colloquial use does not match the street name used in addresses. At the cost of minor data duplication, name:full=* is also there as "$name:prefix" + " " + "$name", so that data consumers don’t have to perform that reconstruction if they don’t want to.
@SD_Mapman in your given examples where the divide is that the sign doesn’t match colloquial and address use, as opposed to the sign and colloquial use not matching address use, this scheme doesn’t work as well. If your current solution is to just set name=* to the colloquial and address use, that seems fine by me.
@willkmis since you say you are well traveled, are you able to share any specific examples that match the Utah case of street sign and colloquial name matching, but address use not matching?
I’ll also point out that several tools have already adopted support:
the Coloured Streets style for JOSM supports using name:prefix=* and name:suffix=* in its coloring, as a setting added in v3.0
the MapWithAi plugin for JOSM will match addr:street=* against name:full=* in addition to name=* when doing address validation (I can’t find the exact release this was added in, but I think it was ~6 months ago)
CoMaps added a temporary solution by using name:full=* instead of name=* when Utah Conventions are detected, in v2026.01.24-5
Personally, I don’t think we need to start broadly applying this across the whole country, since I have yet to find anywhere that uses directional prefixes the same way Utah does. The simple fix is that address usage prefers trying to match addr:street=* to name:full=* when present instead of name=*.
I’m also open to alternate ideas if anyone has ideas that still preserve this separation, because I do recognize the minor collision between name:prefix=*/name:suffix=*/name:full=* and name:<lang>=* (but name:right=*/name:left=* collide too, and I haven’t heard of people taking issue with those)
I’ve started to put the signed name in alt_name just so that information isn’t lost (which reminds me I need to do that in Sioux Falls) unless the signed name is just flat out wrong (because of a typo or the fact that SDDOT’s road name database is woefully inaccurate) then it goes into not_name.
So when I’m in Utah and I say something like “Oh we need to turn on South 300 East” how much does that mark me as an out-of-stater?
My experience editing in the US is that we have long passed the point of name being what is “on the sign” (even presuming all road signs agree). What we do have is a practice of editing by addition as we collate from different sources. For example:
A sign says Lk Samm Pkwy. By normal algorithmic expansion we have. We have name=Lake Samm Parkway
Some local notices that we haven’t expanded the “Samm” part because we don’t know the actual name from the sign. We have name=Lake Sammimish Parkway.
Someone finds address data that shows there’s a East/Westprefix directional split in the naming. We now get name=East Lake Sammimish Parkway and name=West Lake Sammimish Parkway.
etc
At no point did we ever have what what written on the sign. We added and collated data into the name so that OSM has the complete info there and consumers can decide how they want to display and work with the data.
In practice, this generally means that it tends to align with address data (but not always). And FWIW, my own editing experience is that, for example, the NAD address data is way less full of typos and misspellings than current OSM.
It would be an enormous shift, in the US, for the name tag to be “what is on the sign”.
Immediately, and without a doubt . If you ask a local and they’re like some people I know, they may even miss a beat while trying to decide if you really meant 300 East or 300 South.
That’s why I care so much about getting this right, and why the majority of my time editing the map has been splitting out or adding missing directional prefixes.
Most of Indiana’s county roads have a similar naming scheme to Utah’s, right down to the missing directional prefix on signs. And likewise, you know someone’s a Hoosier when they omit the prefix in speech.
But if we were to adopt Utah’s tagging scheme, we’d have to deal with several roadways that straddle county lines, and therefore have a name:left and name:right. How should prefixes for these roads be handled?
The option I chose on the spot when I ran into this was name:left:prefix=*, such as at the boundary between Woods Cross and North Salt Lake, 2600 South / 1100 North
name=2600 South / 1100 North
name:left=1100 North
name:left:full=West 1100 North
name:left:prefix=West
name:right=2600 South
name:right:full=West 2600 South
name:right:prefix=West
And when the plain name is the same, but has different directional prefixes, I omitted name:left=* and name:right=*, but added the other tags, to avoid the validator getting confused about name:left=* and name:right=* being the same. This is the boundary between Bountiful and North Salt Lake, Highway 89
Makes sense to me. Could add name:forward and name:backward variations as well, that would line up with my tagging in the northern plains. Also, I’ve been using a semicolon instead of a slash in the name field FYI. Given that, the full tag stack for the Woods Cross road would be
name=2600 South;1100 North
name:left=1100 North
name:left:full=West 1100 North
name:left:prefix=West
name:backward=1100 North
name:backward:full=West 1100 North
name:backward:prefix=West
name:right=2600 South
name:right:full=West 2600 South
name:right:prefix=West
name:forward=2600 South
name:forward:full=West 2600 South
name:forward:prefix=West
Yes, actually. In North Las Vegas, as Lake Mead Boulevard changes signage from “West” to “East,” it gains directional suffixes. I’ve confirmed that the suffixes are signed (via Google Maps Street View) and are officially part of the name (via its county’s GIS). Thus, we have “East Lake Mead Boulevard North” and “East Lake Mead Boulevard South.” They should be abbreviated as “E Lake Mead Blvd. N” and “E Lake Mead Blvd. S,” respectively.
Agreed. The text on the sign is an indication of what the name should be, but not the exact text. It is nearly always a shortened version of the full name with abbreviations, word omissions, and even word order differences. The sign is just one piece of evidence.
First the data consumers would have to be aware that these tags even exist before they could make that choice. I can’t help feeling that it would be better to put the full name in name, matching standard OSM expectations, and to put the shorter name used on signs and colloquially in a different tag. Instead it’s the other way around. I’ll trust Utah mappers to do what makes the most sense there though.
Definitely, if we want to have what’s on the sign then we can have signed:name like we do for other signed features. You also run into the issue where it’s very common to see different signed names as you drive along a road but that is left as an exercise for those more clever than me.
Oh dear. I wasn’t suggesting to change anything with respect to the usage of the street’s name. I was using “whatever is signed” as a short-hand to however this is interpreted in OSM. And that naturally includes extending abbreviations and ignoring obvious errrors on the sign, aka use common sense when filling the name tag.
Just to clearify a bit about the goal here: the US has a quite widespread problem that there is a discrepancy between the “common” name of the street (whatever you put into the street’s name tag) and the postal name of a street (whatever goes into the addr:street tag). Directional prefixes/suffixes are one of the reasons. They are the most common reason why addresses cannot be found in Nominatim. While it is in principle possible to skip over these prefixes in a query (let’s not discuss that, please), I’d like to see the base data on the directional prefixes/suffixes improved.
I wholeheartedly agree with that. It will be impossible to find a strict tagging rule for the US because the directional prefix/suffix is handled differently in different areas. That’s why my I was suggesting: keep using name and addr:street tag just as you have been doing. Just start consistently explicitly documenting the (optional) presence of a prefix/suffix with the name:prefix/name:suffix tag. That should be enough for data users to handle the situation. So: no retagging required, just additional information.
The alternative would be something like an name:full tag which documents the variants. But that seems to me to require more retagging.
May I suggest to rather use name:prefix:left and name:prefix:right? This would be more in line with the language-specific prefixes like name:prefix:ru that are already in quite widespread use.
I’ve answered that myself in the meantime and have indeed found areas where the street has name=North Foo Street and the address has addr:street=Foo Street North.
East and North are both directional prefixes/suffixes here? That would be a slightly different case and one I have to add to my list of oddities. ;)
Yes. The “West” and “East” prefixes are necessary for addresses. Its western terminus has an address number greater than or equal to 11350, while its eastern terminus is past 8000. So, 7000 West Lake Mead Boulevard is quite a different place from 7000 East Lake Mead Boulevard. The suffixes are there because Lake Mead Blvd’s two carriageways kinda form a one-way pair, so the distinction is necessary.
name=2600 South;1100 North
name:left=1100 North
name:left:full=West 1100 North
name:prefix:left=West
name:backward=1100 North
name:backward:full=West 1100 North
name:prefix:backward=West
name:right=2600 South
name:right:full=West 2600 South
name:prefix:right=West
name:forward=2600 South
name:forward:full=West 2600 South
name:prefix:forward=West
. If you ask a local and they’re like some people I know, they may even miss a beat while trying to decide if you really meant 300 East or 300 South.