[Tagging] Route names that aren’t names

Paul Johnson baloo at ursamundi.org
Sat Mar 28 23:16:18 UTC 2020

On Sat, Mar 28, 2020 at 5:45 PM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

> 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.

Doesn't really work for most of Europe, either.  I get that European Truck
Simulator 2 and American Truck Simulator are highly stylized
representations of both regions, but in both cases, it's pretty obvious the
only places within the scope of those games that "*doesn't*" have this
problem is the UK and Arizona.  Except they still do, because bus, bicycle
and foot routes still run over the same ways as motorist routes...

> 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.

Most of Oklahoma and parts of Kansas also have the variation "E0104 Road"
which is really "CR E0104"...this one's going to be hard to crush since
there's slightly higher than one county road per mile on average on a state
that has extents of 478 miles east to west and 231 north to south, with
numbers *usually* but not always consistent across counties.  It goes
sideways in Osage County, the panhandle and the mountainous counties where
they get put in pretty much wherever terrain will allow, and there's 77
counties, so, probably somewhere between 25,000 and 50,000 county roads
that need to be updated.

> (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.)

Nice thing is relations don't care.  Which is handy because Oklahoma has a
couple routes that go into Texas, and both Oklahoma and Arkansas, and
Oregon and Washington have routes that go into each other (Oklahoma and
Arkansas having a road that's dual signed as an Oklahoma and Arkansas state
highway; largely as a result of the road roughly following the state line
but the line didn't care about terrain and roads obviously do).

> 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.
 Which Paul?  I'm on Team Relation here.  It's been 13 years, relations
really need to be treated like any other primative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200328/99f0051e/attachment.htm>

More information about the Tagging mailing list