<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 19, 2021 at 9:23 PM Zeke Farwell <<a href="mailto:ezekielf@gmail.com">ezekielf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div dir="ltr">On Fri, Nov 19, 2021 at 9:01 PM Paul Johnson <<a href="mailto:baloo@ursamundi.org" target="_blank">baloo@ursamundi.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">You're on a trip heading towards 
Heresville, Nebrahoma.  You're coming up to a fork in the road, and your
 nav says "In 300 meters, stay left on Nebrahoma State Route 36 (NA 
36)."  That added no value to the situation, nor can the data consumer 
filter against that.  Especially since some segment of Nebrahoma 36 
might end up on 36th Street in Anyton.  Locales in the middle 
inconsistently put variations of Route 36, Highway 36, or whatever else 
on the finger signs instead of using the correct shield with double 
ended arrow sign instead in between, but it's immediately apparent 
that's not the name but the highway number.  Tagging it <font face="monospace">noname=yes</font>, <font face="monospace">ref=NA 36</font> solves for literally all of this, isn't ambiguous in any way and avoids annoying and distracting duplication.</div></blockquote><div><br></div><div>I agree that is not very helpful for a navigation system use case, but this doesn't seem like a major problem to me.  Navigation systems are also only one of many use cases for OSM data.  Let's think about a map renderer with this same fictional place.  This map renderer wants to display name labels on all roads but since some don't have a <span style="font-family:monospace">name </span>tag it constructs names from <span style="font-family:monospace">ref </span>values as well.  From the <span style="font-family:monospace">ref </span>value "NA 36" it expands NA into "Nebrahoma", and 36 into "State Route 36" for a full label of "Nebrahoma State Route 36".  So far so good.   In the nearby state of Vermochussetts, VO 25 is similarly expanded to 
"Vermochussetts State Route 25".  This is not so good.  In Vermochussetts this is the proper term is "Vermochussetts Highway 25" as that is how it is printed on signs and all state DOT publications.  A <span style="font-family:monospace">name </span>tag with the value 
"Vermochussetts Highway 25" solves this problem for the map renderer.  Without <span style="font-family:monospace">name </span>tags, the different terms each state uses for its highways aren't available. </div></div></div></blockquote><div><br></div><div>Expansions like this are usually handled in the description field of a road route relation.  Why not name?  Sometimes routes are named and/or numbered.  Creek Turnpike would be an example of a named route, it having OK 365 as a ref is a relatively recent update.  Or OK 51, the 42nd Rainbow Infantry Division Highway (or something like that).  It's also a named route.  But most route relations have descriptions that often match a reasonable expansion (though this can't be gauranteed, perhaps we need ref:stylized as a hint to consumers; example, <font face="monospace">ref:stylized=State Highway 51</font>.  </div><div><br></div><div>Edge concern being Oregon and Pennsylvania which has state highways (everything in the ODOT inventory is assigned a highway number) AND state routes (what appears on the route shields).  State beaches are Oregon highway 0 or 2 (I don't remember which) and starting with Pacific Highway 1, the rest are numbered in the order in which they were built (which is why some weirdly low numbers are like state park driveways and what not).  Pennsylvania suffers a similar "there's a real distinction between the highway number for the <i>way</i> and the route number for the <i>state route</i>" that OSM makes difficult with ref=* on the way implying a route right now (seriously this needs to just die already and state highway routes mapped as relations, a main reason relations were even introduced).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Vermont is not one of these states.  Grand Army of the Republic Highway is exactly this kind of honorific, secondary name signed only occasionally on very small signs (though they are green not brown).  This is why I'm so adamant that it belongs in <span style="font-family:monospace">official_name</span>, not the main <span style="font-family:monospace">name </span>tag.  It may be appropriate for an <span style="font-family:monospace">official_name </span>like this to exist on sections where the only other name is Vermont Route XX.  In these case the correct tagging is going to either be:</div></div></div></blockquote><div><br></div><div>That's fair, though if it really is a purely honorific name, someone might want to point out to VDOT that this belongs on a brown sign, not a green one, per the MUTCD...</div></div></div>