[Talk-us] Name tag on unnamed, but numbered routes

[Paul Johnson]

On Fri, Nov 19, 2021 at 9:23 PM Zeke Farwell <ezekielf at gmail.com> wrote:

> On Fri, Nov 19, 2021 at 9:01 PM Paul Johnson <baloo at ursamundi.org> wrote:
>
>> 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 noname=yes, ref=NA
>> 36 solves for literally all of this, isn't ambiguous in any way and
>> avoids annoying and distracting duplication.
>>
>
> 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 name tag it constructs
> names from ref values as well.  From the ref 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 name tag with the value "Vermochussetts
> Highway 25" solves this problem for the map renderer.  Without name tags,
> the different terms each state uses for its highways aren't available.
>

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, ref:stylized=State Highway 51
.

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 *way* and the route number for the *state route*"
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).

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 official_name, not the main name tag.  It may
> be appropriate for an official_name 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:
>

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20211120/08ca5926/attachment.htm>