[Tagging] Route names that aren’t names

Kevin Kenny kevin.b.kenny at gmail.com
Sat Mar 28 22:45:19 UTC 2020


On Sat, Mar 28, 2020 at 5:57 PM Richard Fairhurst <richard at systemed.net> wrote:

> Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the
> "M4". That's fine - plenty of people refer to it that way. But OSM
> convention, dating back 15ish years, is that in situations like this, you
> put the number in the ref alone. The M4 just has ref=M4, not name=M4.

We Yanks follow that convention for route _relations_, where we can
identify the network. Otherwise, it really doesn't work for us,  It's
entirely possible to have intersections between two routes with the
same number that belong to different networks. (Yes, it's confusing,
but we are used to identifying routes as "Interstate 95", "US 9", "New
York 20", "County Road 84", .... even in speaking.)  For us to leave
that out would be like you saying the 4 or the 180 for the M4 or the
A180.

You convinced me that refs are not names, so I've been working in my
local area of killing off the use of the ref as the name, even in
cases where the road has no other name: 'ref="CR 104" noname=yes' in
preference to 'ref="CR 104" name="County Road 104"').  But as long as
we suffer with refs on ways, we need at least to make the refs useful.

(That gets tricky when one jurisdiction's road crosses over into
another jurisdiction.  About half of NY 120A
https://www.openstreetmap.org/relation/407958 is in Connecticut but
it's signed and maintained as a New York state highway.)

I fully understand the difficulty with rendering only from route
relations. I maintain a renderer that does it.  It still needs some
serious programming if it is to scale to handle minutely updates
against the planet.  The project has, to put it mildly, less than my
highest priority, since Paul and Sarah have quite sternly discouraged
me from pursuing the approach that I took to the problem. The issue is
that the rendering servers are already grievously overloaded, and any
new functionality such as this needs to come at essentially zero cost
at render time, and only negligible cost at the time of minutely
updates. I've not been clever enough to meet that challenge, and while
new ideas might come to me, I've so far come up empty.

-- 
73 de ke9tv/2, Kevin



More information about the Tagging mailing list