OSM Americana originally took this stance, but ultimately was convinced that they weren’t necessary in the UK. Americana now renders shields based off of way refs in the UK.
I guess what I’m suggesting here is that we don’t need a tag for the fully qualified ref (I like that phrasing, though), when we can easily build to that from a lookup table, similar to what many countries do with speed zones… like maxspeed=DE:urban for the implied national urban speed limit in Germany (currently synonymous with maxspeed=50 but if it changed to, say, 30, then anyplace tagged maxspeed=DE:urban automatically becomes synonymous with maxspeed=30 with data consumers updating their lookup tables).
That seems like some fairly odd logic to use, given routes traverse a multitude of different named ways along the way, and the long standing guideline of “tag the object you’re describing”…the constituent ways aren’t the route.
My advice to consumers would be to render the ref on the way only if there is no relevant route relation in play, as a legacy fallback.
Stole that phrasing from @Minh_Nguyen 
. I certainly agree in principal. It would just be backwards compatibility for data consumers that don’t want to change. Same as the current situation with way refs.
1 Like
To which I say “It’s been 15 years since relations were introduced. Linux took less time between when ext1 was created and when it was removed from the kernel entirely”. But I’m not sure that including the fully qualified ref on the relation would actually be all that backwards compatible? Since the data consumer would already need to parse the relation, might as well go all the way.
We don’t have routes in the UK. We have roads with numbers.
I’m going to be honest… as someone who does pretty extensive parsing of US route refs, I’d suggest you should make your own map consistent before turning your attention elsewhere. In literally every other country where I need to do so for cycle.travel, I can match public traffic data to OSM data by doing a regex comparison on the ref value. I can’t do that in the US because the state of route relations, refs, names, or whatever, is so poor. Most rural areas are basically unchanged from the original TIGER attributes. So I have to spin up an entire new temporary instance of OSRM, at the cost of about 12 hours’ CPU on a beefy machine and a big load of bespoke multi-threaded C++, just to do map matching. By contrast, Europe takes me less than half an hour because I can just run some pretty simple Postgres matches on geometry and ref values.
When you have consistent route relations for every road in the US, like we have consistent refs in the UK or France or Germany or wherever, that’ll be great! But you are nowhere near that right now.
This is a difference that keeps catching people by surprise on either side of the pond. Some time ago, when OpenMapTiles implemented its own gymnastics to simulate “routes” based on UK road numbers and classifications, I attempted to explain this difference to an OSMUS Slack audience. Since not everyone here has joined Slack, here it is in an old-fashioned wiki slideshow.
1 Like
The state of US route information is excellent. It’s just massively complicated 
1 Like
This. You can take the entire European Union and you’ll have fewer highway networks than any 27 counties in Texas (as an extreme example; but this comparison could probably work for any 27 random counties in the US).
Yeah, it’s insanely complicated. But, to “fix the map”, it’s only going to get far more complicated, not less, simply because there’s probably still dozens of networks that nobody from OSM has effectively touched since the TIGER import.
The closest American analogue would be the concept of a “truck route”, or a “bike route” in cities that don’t name or number them.
These also get route relations, you know…
1 Like
That was a reference to 
and 
, not 
or .svg){kind=small}
. But watch the slideshow; you’ll see what I mean.
This is what I thought at first too, until I fully understood the mechanics of British and Irish road numbers. In fact, if you were to make route relations for the UK and Ireland, it’s not even clear how they should be assembled.
(for any Brits reading, I apologize in advance if I bungle this description)
The factors that make these roads so different from what we understand as routes are:
- Sign symbology is colored differently based on the road classification. So let’s say you have road numbered A123. That road might start on a
highway=trunkand then switch to ahighway=primary. But here’s the kicker, on thehighway=trunksection, it would get a green sign and on thehighway=primaryit would get a white sign. Here’s an example in the (developmental) Americana rendering of this below, where “A44” traverses from trunk to primary:
-
They are discontinuous when they should be concurrent. We’re used to route concurrencies in which two routes need to share a road. The routes would merge, and the road would carry both routes for a bit until splitting off later. In the UK, they still have this situation where two longer-distance numbered roads intersect in this way. Except in the UK, one of the two numbers simply goes away, and pops on back in on the other side. In other words, every road carries only one number, ever, period, full stop.
-
There are no exceptions to these rules, ever.
Here’s where that A44 road goes in Worcester, UK (screenshot from overpass turbo). The routing doesn’t really make any sense and it has weird gaps and there’s a little leg that’s just dangling off to the south for no reason at all:
In the UK, any ref on a motorway gets a blue sign. Any ref on a trunk road gets a green sign, and any ref on a primary or secondary road gets a white sign, without exception. In other words – the highway value plus ref fully contains all information a renderer needs to generate a shield.
So if we were to jam-fit the UK system into route relations, you have two choices. First, you could put every road with the same number into a route relation, regardless of highway class. This wouldn’t be useful to a shield renderer because it’s actually the highway value that tells me how to draw the shield. It’s also fairly questionable as a “route” given the discontinuities. but you’ll find they roughly traverse long distances.
The second option would be to put each common highway class and route together in a route relation. So you’d have one route relation for highway=trunk A44 and another for highway=primary A44 and so forth. This would give you something renderable but VERY discontinuous and wouldn’t make sense at all as a conceptual route (though I suppose you could do that with super-relations).
Anyways, whatever option you pick to ham-fist the UK numbered road system into route relations, it’s not adding any new information, and you could do everything you need to purely from existing data. In fact, this is exactly what OpenMapTiles does. Any road in the UK with an M** A** or B** ref value gets added to a virtual route at compile time. The Irish scheme is implemented in this way also. That’s what we use in Americana. So from the style’s perspective, it looks like there’s routes in the tiles but they’re really just generated at build time from the existing data. That seems a heck of a lot more reasonable to manage data-wise than to force a construct that doesn’t add any information.
2 Likes
Interestingly, a similar pattern can be observed on US Forest Service roads. Since the choice of horizontal or vertical signage depends on maintenance class, a road can change sign types as it gets more remote. Here are a couple examples showing this on the USFS 2016 map series:
1 Like
No, that’s spot on!
I think where I encounter it is probably slightly different to your main concerns with Americana, because I’m writing a bike router that prefers the lower levels in the hierarchy (=low traffic) rather than the higher ones (=fast passage for cars).
I agree the Interstates and US Routes are good. State highways are good in some places, but not relationed in others, and still have a lot of duplication between name and ref (random example that took me about 10 seconds to find: Way: State Highway AB (18341062) | OpenStreetMap). County roads are maybe at 5% relation coverage, if that. Way: Dallas 237 (12783473) | OpenStreetMap was the first one I randomly checked, and if you follow that through then who knows what on earth is going on there. Fairly typical in rural areas.
1 Like
Here’s a picture of the start of it:
Dirt road… no shield, just street sign… Pretty sure this isn’t a county route but rather just a numbered road in that county. I’m poking fun at the British system of course, but there’s legitimately a gray area as to what counts as a route where we don’t have consensus on. There are some counties in Mississippi where we’ve had similar debates. Certainly “5th Street” wouldn’t get a route relation and so there’s a legitimately open debate as to whether “County Road 5” should have one or not. But if data consumers other than shield renderers are somehow making use of route relations on such objects, that’s useful information that might guide our tagging.
Legitimate find. I had to ask what the hell kind of route this was and of course someone in Slack knew and of course we render it but that one doesn’t have a relation. Such is the complexity of the American route scheme, if you can even call it that. We should probably put something together to identify “probably routes without relations” based on searches like this.
Here’s an overpass query that folks can use to search for potentially missing route relations.
[out:json][timeout:2500];
way[highway][name~"State Highway"]({{bbox}})->.highways;
.highways < ->.routed_highways;
rel(bw.highways) -> .parent_routes;
way(r.parent_routes) -> .routed_highways;
(
.highways;
- .routed_highways;
);
(._;>;);
out skel qt;
I spotted a tagging error there, too. The way is tagged name=State Highway AB, but it shouldn’t have that tag, it should have noname=yes.
Are you sure? It looks like it’s a Missouri supplemental route to me. Or are you saying that it should be added to a route relation but not have a constructed name in the way’s name tag?
Effectively, the latter, since ref=* is not name=*.
I’m making popcorn, everybody. This is a fun space to watch right now.
2 Likes