Hello all! Would it be worth the trouble to change the multi-state super road route relations from type=route to type=superroute? This seems to follow the wiki better.
Inspired by Changeset: 177671531 | OpenStreetMap
1 Like
There are two competing tagging schemes, one that uses route superrelations and the other that uses superroute relations. We previously discussed the choice of route superrelations regarding U.S. Bicycle Routes, which are modeled after U.S. Routes in the real world:
I have a few concerns with using superroutes in this context. With a couple of exceptions in California and on Lake Michigan, these relations are not arbitrarily divided for technical reasons, as superroutes are intended for. They’re divided at state lines because each national route is a coordinated collection of state-designated routes, but the overall collection is also a route in a federal sense. Moreover, we often need more than two levels of relations due to cardinal directions, so if superroutes somehow help us avoid nested superrelations, they don’t anyways.
But now that you mention it, my main concern with the linked changeset is that it’s obviously historical mapping. @Flap_Slimy_Outward has experience contributing to OpenHistoricalMap, so I don’t know why they’ve felt the need to introduce historical route alignments to OSM.
Thanks for the mention.
I’m not sure if this is the place to mention it, but OpenHistoricalMap’s iD is stuck at Version 29, while OSM’s iD is at Version 37.3 (as of January 27, 2026). This makes certain things harder to edit (such as _links), and road numbers don’t even appear on OHM’s default renderer anyway (or any other renderer, for that matter, AFAIK).
There are many roads tagged with “name=Old Highway nn,” which I’ve converted into “ref=[network] nn Old.” So, this isn’t “historical” mapping per se, but rather an attempt to standardize these “Old Highway” names (isn’t that what ref=* is for?).
Formally speaking, standardizing “Old Highway 123” names is not a goal at all for OSM. You can add old_ref=* to individual ways when a decommissioned route leaves behind roads clearly named after the route, but name:etymology:wikidata=* is more useful for that purpose. In practice, old_ref=* has turned into a bit of a junk drawer of old route information. But your network=US:US:Old old_ref=US 123 ref=123 tagging even confuses this junk drawer with real-world historic route designations that are signposted on the ground.
I first noticed your historical route mapping a few weeks ago after you mapped Old Highway 58 in Barstow, California, as both a network=US:CA:Old ref=58 route relation and ref=CA 58 Old on individual ways. This is causing maps to variously show the number “58” (CoMaps, OSM Americana), an actual State Route 58 shield (Mapbox), or a “CA 58 Old” badge (OSM Carto).
I thought maybe you were thinking of this single guide sign along northbound Interstate 15 that pairs Old Highway 58 with a standard state route shield. But this sign is erroneous: the exit is at a location that would’ve been renumbered from 179 to 186 back in 1969 had Caltrans used exit numbers back then, and Old Highway 58 should not have a shield.
I wondered if maybe Caltrans had made enough mistakes along these lines that we could consider Old Highway 58 to have a shield unofficially. It would be pretty cool if OSM were the only one to notice. So a couple weeks ago, I took a big detour to Barstow to look for more shields. Unfortunately I could only find that one sign, nothing else. The guide sign is correct on the northbound lanes of I-15:
I don’t mind being led on a wild goose chase once in a while. I find surveying fun. But this is actively misleading people who use OSM more seriously to get around. We should not have a route relation for the former State Route 58 alignment – especially not one that continues where the pavement ends:
At the very least, you should’ve stuck to the old_ref=* tags on ways and nothing else. But since you’ve gone too far and brought all this historical mapping to the fore, we’re forced to probably eliminate even those invisible tags too.
2 Likes
OHM is in the middle of upgrading to the latest version. It’ll be deployed after some testing on staging this week. In the future, if some software issue is preventing you from contributing to OHM, please speak up about it on OHM’s forum or GitHub issue tracker instead of trying to turn OSM into OHM.
The OSM Americana project is working on an OHM Americana renderer that would include historical routes with historical route shields. Come see my talk at Mapping USA this Friday, and swing by the town hall on Saturday if you’re able to make it. You’re exactly the person whose help we need to take this beyond a simple technology demonstration. None of your historical contributions will have the impact they could have if you keep trying to jam them into OSM.
2 Likes
That depends whether they are ONE real world object or not. As @Minh_Nguyen mentioned we discussed it for the USBR cycle routes.
The highest OSM-relation should be matching the highest real world object. route=superroute relations are not a group of separate objects, but are just a technical need in case ONE real world object exceeds the practical OSM-relation limitations.
Like if there is one CA15, but the elements exceeding the practical limits of one route-relation, split it in multiple relations and put all of them in one superroute-relation. Otherwise no superroute-relation is needed. There is no need to create one to just collect “related” objects.
By contrast, the best reason to use type=route would be that a relation represents the real-world concept of a route. In the real world, Interstate 15 is a single federally designated route that consists of six state-designated routes, one per state. Each of those routes consist of a northbound and a southbound route relation. The federal route is one real-world concept, as are each of the six state-level routes. Both realities coexist at different levels of detail.
If anything in this description is not a real route, it would be that lowest level in the hierarchy, such as the northbound lanes of Interstate 15 in one of these states, but we use type=route for backwards compatibility, consistency with undivided highway routes, and consistency with PTv2. Awkwardly, neither American English nor British English has a word for this concept. We’re all too shy to turn them all into type=subroute relations.
Unfortunately, this changeset created some very confusing relation structures that would be unusual for either relation type. Why is California’s Interstate 15 a member of three different route or superroute relations? Sure, the English Wikipedia chose to merge California’s 6-mile-long State Route 15 and Interstate 15 into a single double-headed article to fool the site’s notability police. Sure, for the handful of people who care, the state’s Streets and Highways Code only recognizes a single combined Route 15. But practice, no one thinks of it as a single route, certainly not on the road.
Why are the northbound lanes of Idaho’s Interstate 15 simultaneously a direct member of both Idaho’s I-15 relation and the federal relation, forming a diamond inheritance pattern?
Why is Interstate 15 Alternate a member of the federal Interstate 15 relation? The alternative role is used on recreational routes where the alternative is not a route in its own right. But an Alternate Interstate Highway is a real route approved by AASHTO separately from its parent route, or at least something signposted with the “ALT” banner. No record of this very short route exists as far as I can tell. What is this route relation based on?
What a mess.
Looking at satellite, it looks to me like that’s mainline I-15 and what currently in OSM as mainline I-15 is just a C/D ramp, but I haven’t been up there in almost 10 years so that’s all I have to go on. The project website is useless, no signage plans there that I can see.
I-86/I-15 System Interchange | ITD Projects
Because the California Streets and Highways Code defines “Route 15” as what everyone else calls I-15 and State Route 15.
I tried to separate them out, but iD complained that the changeset size was too large. Therefore, I had to download the changeset and upload it using JOSM instead, in which I had to resolve conflicts.
Edit: I fixed it.
Honestly, I have no idea what’s happening there. Based on the changeset histories, I-15 was rerouted slightly, leaving the original roadway abandoned. (Someone please tell me more. I don’t remember any of this from the last time I went to Cali from I-15.)
Edit: Apparently, Idaho decided to do the same thing at the eastern terminus of I-86. Seriously, what is going on here?
(sorry, I don’t want to reveal my face and/or voice to random internet users; AI scams and privacy are huge concerns in 2026…)
Route 15 is a Legislative Route Number (LRN), as opposed to a Sign Route Number. OSM used to have extensive coverage of LRNs as redundant route relations, but we deleted most of them. There were even relations for some unbuilt routes that mappers snapped to the closest road. One of the few remaining examples is an LRN 51 relation coterminous with U.S. 50 Business. No one is silly enough to claim that the remaining LRNs are signposted. They’re all tagged unsigned_ref=* rather than ref=*.
The only reason why the legislative Route 15 came up in the Wikipedia article is that the article’s authors needed a reason to justify combining the two routes (from a lay perspective) into a single article. I understand that the AARoads Wiki, which forked the English Wikipedia’s road-related articles, intends to split apart such combined articles.
What do the signs say? You can’t just presume that a roadway is an ALT or SPUR of the route it branches off of.
In ITD’s simulation of the project, what you have as I-15 Alternate is actually the mainline I-15. The destination sign for it says I-15 North for Idaho Falls. The former mainline alignment is now a collector–distributor lane, which should be retagged as highway=motorway_link. It also has a destination sign saying I-15 North for Idaho Falls, so no way ref=* or route relation would be appropriate as far as I can tell.
If you have any sources to the contrary, please share them, but in general I don’t think we should be conjuring up routes based on supposition.
It was a webinar-style Zoom call where you don’t see the other attendees. We used Slack as the peanut gallery chat room. Anyways, my writeup has links to a recording of my talk and a live demo of the renderer. Hope to see you back on OHM, where your Las Vegas–area mapping is paying off.
Wouldn’t this violate the “one feature, one element” rule?
I went ahead and changed them to match this. (I also extended the Business Loop to I-15 proper, to be consistent.)
Oh, wow, that’s actually pretty cool! I’ll definitely check out your writeup and return to OHM (it’ll finally be satisfying to see Route 66 or 91 or 93 or 95 evolve with proper shields!)!
1 Like