Names are not refs. And Nominatim could easily search descriptions, just as easily as JOSM could show network and ref when there is no name.
1 Like
The correct values in this situation would be noname=yes, ref=I 35. Refs are not names.
Just to be clear, this “North” doesn’t mean “Northbound” like it sometimes does in other contexts. How would you retain the information that the roadway is located in the northern quadrant of the street grid, just like North Congress Avenue running parallel to it?
That information is only part of addresses, same as anywhere else this comes up on a nameless street with a highway on it.
I’ve linked to a Mapillary image of a street name sign that indicates the name of the cross street as “North Interstate Highway 35”. A driver would be forgiven for thinking it’s a street name rather than an address. I recognize that this practice is far from universal, but it does frequently come up elsewhere, especially with U.S. Routes.
1 Like
It’s true that ref and name are different keys with different meanings. However, this does not mean that roads identified by ref tags should never have name tags. In some cases this may be appropriate. In others it may not be.
I agree that it does, but it’s also contraindicated by common practice, contraindicated by data consumers (who will then say overly verbose and redundant things thanks to the unnecessary duplication of information), and in a really rare feat, also contraindicated by the wiki. Just fix it when you see it.
Definitely! But there’s a difference between something like the situation I was responding to, and say, name=Tualatin Valley Highway, ref=OR 8.
Yes that is an example where ref and name are both clearly applicable. But even in the case you were responding to there is not consensus that name should be ommitted in favor of noname=yes.
Yeah, no, I respectfully disagree there… The consensus is pretty clear, there’s a few folks, most of whom are relatively new coming from other maps, that do this but it’s definitely from a point of good faith ignorance.
And I respectfully disagree as well. Which is why I say there is not consensus. I recognize that your viewpoint is widely held, but it is not universal. In my area plenty of street blade signs and addresses use street names like “US Route 2” or “Vermont Route 15”. I and other local mappers have no problem understanding these as appropriate name values for these roads. In other areas, mapping practice is different and that’s just fine.
1 Like
You don’t see the annoyance and uselessness to users od hearing “Turn right into US Route 2, US 2” or “Continue on Vermont Route 25, VT 15”? It breaks nothing to do it the right way but does break most consumers by doing it the wrong way.
I generally fall in the “refs are not names” camp, but the specific example posed sounds more like “data consumer should do deduplication”
3 Likes
I acknowledge that this thread has now veered into the “how to tag road ways” controversy, which is totally separate from the initial topic and edit for road route relations.
But on this topic there seem to be two positions:
- Ref information should never be repeated in way names
- Ref can be repeated (e.g.
name=State Route 123) in situations where waves hands frantically the route name in that form is waves hands frantically used locally.
Examining position 2, what I would want to know is whether that name is computable using a consistent and well-determined method knowing only route and network information. In other words, would every way associated with a route get the same name format? Is that format used consistently or are there differences based on whims?
If the constructed is unique or special for a particular way, that gives a stronger argument for using name tag. If it’s purely algorithmic, that’s a strong argument for omitting it. If the construction differs in dfferent usages, that’s also a strong argument for omitting it - it lets the data consumer decide how to do the construction.
For example, if Vermont State Route 15 were called “Ye Olde Vermont Route 15” on a certain stretch in the historic part of town, I’d gladly accept the argument that we’re looking at a “real” name and not a constructed one.
I’m not convinced by postal addressing arguments, since there’s separate tagging for those.
1 Like
I am sympathetic to this annoyance, but voice guidance from a router is only one specific use case and OSM is used for many different things. If it is too difficult for routers to deduplicate, I’m sure we could come up with a tag that provides a hint that the the ref and name values are somewhat redundant. Something like ref_based_name=yes perhaps.
If you want to make a map displaying local street names, it is appropriate for certain sections of VT-15 (just one example) to be labeled “Vermont Route 15” as that is the actual street name designated by the town. Yes this is inherited from the state route, but they’ve chosen to use this as the name rather than a different unique name. This doesn’t mean the street is nameless. If you want to associate address points to their street, having a nearby street with a name tag that matches the addr:street tag on the address nodes is useful. If you want to conflate separately mapped sidewalks with their associated street, matching the street’s name tag to a name tag on nearby sidewalks [1] would be useful. Omitting the name tag when the name is too similar to the road’s ref breaks these use cases. Please note that we are talking about differences of opinion in mapping style here. There isn’t a right way and a wrong way.
In Vermont we’ve chosen to align our road names as closely as possible with the form that the state e911 address database uses: VT Route XX and US Route XX. We expanded these slightly to Vermont Route XX and U.S. Route XX and this is tagged fairly consistently across the state (mostly not by me).
Limiting the scope to only the state of Vermont, I’d say the answer is yes. A data consumer could predictably construct Vermont Route XX. But I consider this beside the point. If a road is truly nameless it should not have a name tag. These roads have names and therefore should have name tags. Why should a data consumer have to know that sometimes when a name tag is not present it means that the road doesn’t have a name, but other times it means the road does have a name but that name is similar to some other tags, so we omit and you should instead construct the name out of those other tags? The preferred format of these names also varies form state to state. In Vermont, “Vermont Route XX” is preferred, in other states “State Route XX” is preferred. A data consumer will need to take this into account as well. Seems simpler to me to just use the name tag.
Which name tag to use for the sidewalk (
name,street:name,is_sidepath:of:name, or something else) is a whole other discussion. ↩︎
Here in New Hampshire, we have non-overlapping state and US route numbers (except for US 4/NH 4, for some reason). Locals generally refer to all non-Interstate numbered highways as “Route 123”, whether it is a US or NH route. The words “State Route” are never used because we don’t have county roads, and I consider the TIGER names to be an error.
1 Like
I’m of the opinion that a street name can be utterly boring. It can contain a letter or a number. It can even be predictable, like “West 22nd Street” running between 21st and 23rd, or “Alley 8” two half-blocks away from Alleys 7 and 9. But neither 22nd nor 8 is a “ref”, that made-up word that mappers toss around as if it’s a noun. More precisely, neither 22nd nor 8 is a route number. A moniker like “State Route 123” can function as a name in some contexts, but in others, it’s just another representation of the route number, which is already adequately tagged on the route relation and redundantly on the way.
Unlike a lot of American GIS and addressing systems, we keep the whole street name together as one unstructured unit of information, even though breaking it up into “West”, “22nd”, and “Street” would facilitate more reliable abbreviations and such. But we do represent route numbers as structured data in network, ref, and direction. I guess we care more about being able to render 
than “West 22nd St.”.
Some use cases like navigation and geocoding really need to be able to come up with the spelled-out representation or an abbreviation, but it isn’t easy because every route network has different rules. Some route networks have a different rule depending on the jurisdiction. (Is it a “U.S. Route” or a “U.S. Highway”? Is it “CR”, “CH”, “CTH”, “Co.”, or “C”?) Compiling a comprehensive set of these rules is akin to the OSM Americana project’s effort to design a shield for each network. Many rules are already stored in Wikidata for data consumers to ingest automatically, without us needing to manually tag individual routes in various languages. But many local networks are still missing, so those who feel strongly about keeping systematic names off route relations might consider contributing to Wikidata’s coverage of those name formatters.
I appreciate @Baloo_Uriza’s position as a rule of thumb for most route systems in most of the country. OSM’s status quo is a lot cleaner than TIGER’s for this reason, even if it shatters Nominatim’s assumption that an addr:street=* must always match the name=* of a nearby street – or else the address doesn’t exist and all bets are off for routing. However, I don’t like to formulate it as a universal truth, because there’s nothing stopping a local authority from munching on some 
before foisting something more idiosyncratic upon the traveling public.
The U.S. Route 22 / State Route 3 concurrency in Warren County, Ohio, is officially “West United States 22 and 3” or “East United States 22 and 3” and appears that way in most GIS and addressing systems. On the ground, street signs posted by the county used to consistently give this idiosyncratic name, but more recently, townships and developers have posted signs that call it anything from “State Route 22/3” to “U.S. Rt. 22 & S.R. 3” (there was a surplus of periods one year) to “Montgomery Rd.” (the name of the road in a different county). I’ve mapped the signs and also tagged these idiosyncratic names in alt_name=*, because while I think this is interesting information, inconsistent software behavior may cause more confusion than it’s worth.
On the other hand, directionals are usually pretty important in the counties and cities that use them. Just as mail addressed to West 5th Street shouldn’t go to East 5th Street, there is a difference between northbound North Interstate Highway 35 and northbound South Interstate Highway 35 in navigation and geocoding. It may not be the determining factor in getting lost if you’re using turn-by-turn navigation, but that shouldn’t be a requirement for adding signposted detail to the map.
@NE2 already inflicted enough dataloss by removing quadrant directionals from street names in sweeping edits.[1] Hundreds of streets were affected in Ohio alone, maybe more if anyone has already started removing tiger:name_direction_suffix=* too. If another mass edit removing name=* from ways is under consideration, then I may need to trot out a longer parade of horribles.
Heh, this road becomes “East South Street” inside corporation limits. ↩︎
And I guess it is too late to revert this name edits? Though it sounds like tiger:name_direction_suffix=* can be used to reconstruct them?
tiger:name_direction_suffix=* is primarily useful for detecting where these road names became oversimplified. With a set of roads in hand, I could refer to the latest TIGER dataset or street-level imagery to come up with the same answer. But I don’t think a straight-up revert will do much good, because @NE2’s edits happened before we started mapping lane counts, turn lanes, and turn restrictions in great numbers; most of these ways have since been split many times.
By the way, it could be as many as (or more than) 735 roads if tiger:name_direction_prefix=* is included, and that doesn’t count counties in other states that have similar practices.
If tiger:name_direction_suffix=* remained then it would also survive splits.
And if NE2ified name was simply wrong (or at least worse than previous one) then recovering proper one on just some segments seems better then having consistently wrong one.
Note: I am not planning to make this edit, I lack understanding which version is better.
1 Like