Talk:Utah/Naming Conventions

Comment from Sagei

See changeset https://www.openstreetmap.org/changeset/103551668

"Mostly added in the direction to the street name for areas where cities name the street differently to help prevent confusion. Where all e-commerce sites rely on the customer to add in the prefixes, and state and federal data is particular about prefixes, not having them attached in the name causes a lot of issues for folks (personal experience from customers chatting to me in newer developments). This is especially true in areas where you have the same house/building number on a road, but different prefixes (e.g., N, S, E, W). Even if you define the prefixes in the metadata, it doesn't always reflect on package or mail labels unless they're specifically inputted by the customer."

Adding cardinal names to streets has its uses, but other metadata inputs should be explained as well.

For some context, I've always approached road naming conventions with the full street name written out (e.g., West University Boulevard, North 300 West, East SR 89 Westbound). My rationale for it is pretty simple, though I'm aware that others might disagree:

1. Metadata that is added to a street does not always reflect on mapping services that import OSM data. The customer either has to input the prefixes themselves, or hope that their address is unique. Otherwise, there's an increased likelihood that their address will be mistaken for someone else's--and that's especially worrisome around the lower number addresses (generally in the 1-1000 range for any of the cardinal prefixes, as a lot of developers like to leave one side of the street as one cardinal direction and then assign a different on to a connecting street that's developed later on. Been seeing it in many cities throughout Utah County).

2. It makes inputting addresses for businesses or residences much simpler--as you don't have to remember to type the full prefix when inputting the street name. I've often put addresses on residences so that the house number displays in the apps delivery drivers use (when it wants to display), and it certainly helps to keep my "paste"-data free if I need it.

3. Adding the prefixes can help people be aware that they're traveling into a different city. Just having the numbers change doesn't do that often enough for people (take the jump seen between American Fork and Highland for instance, or certain parts between Spanish Fork and Salem, or even Salem and Woodland Hills), as many cities outside of Salt Lake County follow different designation rules that don't always smoothly convert into a consistent cardinal prefix direction.

Other than that, it would help to have some consensus on how roads should be labeled if they have different designations in different cities. Many parts of Utah County where you have the designation between two cities and the original county designation, after all (American Fork and its neighbors being one major use-case). Not certain how the "name_(n)" and "alt_name_(n)" differ in that regard, but that might help clean up some of these issues we're seeing from the old TIGER imports. Also, would be helpful to know if we plan on taking designations like "2100 South" and adding "St" to the "name_type" for the metadata--as no one really uses the "St" designation anywhere outside of plats submitted to county offices. Adding that "St" to non-named roads isn't really useful in navigation when the locals just refer to them by their number and cardinal direction suffix (excluding abbreviations. 112th South or 30th West should be written out, for example, as that's not its official designation).

My response to concerns above

I'd like to share my thoughts about the 3 points raised above.

1. I don't see this as a big concern since addresses will need to include the prefix in addr:street=*, and the address itself has coordinate information. I don't quite understand what you mean by developers assigning different cardinal directions to connecting streets? Isn't that how it's supposed to work? Say one street has a north direction; all of the connecting streets get an east direction (as an example). Of course, naming bodies are known for making weird decisions for streets that aren't straight north/south/east/west, but that's a different matter.

2. I agree that the editor problem is a big concern. iD only detects name=* tags on nearby streets, and most mappers do use the suggested name. I wonder if it'd be possible to have iD merge name=* and name:prefix=* in their suggestions?

3. I agree that it can be confusing when moving between cities. Though I think that that's just an inherent part of being in the counties that never unified their systems, and throwing extraneous directions on a map does not clarify things much.

For the streets of many names in Utah County, I did write a blurb about them on the main page. Typically there's only one name signed at a time, and that one will go in name=*, and any others would go as a semicolon separated list in alt_name=*. The signed name is usually set by the city the street belongs to. For cases where the street is a city boundary, and the two cities refer to the street differently, the name:left=* and name:right=* tags should be used, and the name=* tag should be empty or maybe have both names separated by semicolons. For my overall opinion on the matter, I would rather we follow the on-the-ground rule for street names in Utah, but I recognize that that is controversial since there's also the rule that addr:street=* should match the name=* of a nearby highway=*. What I want most of all is for the data to be consistent.

Aweech (talk) 21:08, 30 April 2021 (UTC)

Mention alt_names don't appear on the map

Problem:

• On the ground, signs say
  • 400 South, and in smaller letters:
  • University Blvd.
• On the map, we only see
  • 400 South

However in https://www.openstreetmap.org/way/829867667 the alt_name is indeed already there, but not rendered on the accompanying map. Jidanni (talk) 09:43, 9 March 2024 (UTC)