OpenStreetMap
Proposal: Sunset ref=* on ways in favor of relations
Posted by Baloo Uriza on 6 November 2015 in English.ref=* on ways has become an unmitigated hot mess for maintainability, and now that relations have been around for a considerable amount of time. Let’s kill this dinosaur like Linux killed ext filesystem support already. It’s so long in the tooth it’s starting to go from egregious to just sad.
Background: Prior to 2007 and the 0.5 API, OpenStreetMap had no “relation” data type, just nodes and ways. A stopgap measure to deal with routes was to tag them on ways. However, this quickly developed into a major issue as routes with their own refs for different modes and memberships cropped up as OSM developed past being merely a traditional street map. Relations were introduced, and quickly adopted as the standard tagging for routes of all kinds, with tags for most networks moving off the member ways to the relations. Presets for creating road routes with relations exist in (at least) JOSM and have for years now (I’d consider it a glaring, almost egregious, omission for any general purpose or highway-oriented editor at this point).
The problem: It’s now been 8 years since the introduction of relations, and only route=road seems to be the sticking point for consistent route tagging, with qualities that should be part of the relation are instead still getting legacy-tagged on ways. This ends up being a major maintainability nightmare in places where multiple routes share the same way, especially whenever a new route is introduced or an old route is later deleted, and only gets worse the more routes share the same way (Illinois being an extreme example with some highways carrying as many as 9 signed routes), or the more road networks in play (Texas being an extreme example with 7 state level networks).
There’s also the situation where ways themselves have their own refs often disconnected from the route (Oregon for sure for any highway with no route, all highways prior to 1928 and most highways 1928-2007, which is to say all but ~20-30 highways statewide) and possibly Pennsylvania (with the four-digit state highways) has this situation, but PA’s case might just be a borderline case of routes with unsigned-ref).
Even in European cases, thanks to “E” routes in the EU, this is decidedly not a strictly North American situation.
In any case, adding or removing members and checking the relation’s consistency is far easier, and easier to validate, than juggling multiple ref values in any sort of coherent fashion. And this is before even getting into issues of which order the refs go in…
The fix: I propose a goal of December 31, 2016 to eliminate ref=* as a method to describe an overlying route; this should be more than ample time for existing data consumers to catch up on doing a move and ensure data consistency for routes. Kill the dinosaur:
Deprecate ref=* on ways from having anything to do with the routes they run over, use relations instead and phase out the use of route-describing refs on ways (be it removal of the tag or replacement of the key’s value with a ref that actually applies to the way instead of the route).
Stop rendering this key and instead render the relations in opencarto and other featured layers.
Discussion
Comment from Richard on 6 November 2015 at 13:13
Nope.
You’re welcome to do it in the US (indeed, I’d encourage you to do so), but that’s no reason why other countries need to adopt hard-to-edit, hard-to-parse relations for the sake of another country and the 0.1% E road edge case.
Comment from Baloo Uriza on 6 November 2015 at 13:52
So what makes motorists somehow privileged as a mode to do it differently than we already handle foot, bus, bicycle, and literally every other kind of route?
Comment from Baloo Uriza on 6 November 2015 at 13:53
Especially since many of these routes are already multiplexed with the only difference being the mode of travel.
Comment from Sanderd17 on 6 November 2015 at 15:46
There’s a conceptual difference between the European refs and the US refs.
In Europe, it’s custom that an official body gives a road one and only one ref. The ref is only used to name the road, but with numbers as they lack some naming inspiration. This means that refs don’t have to be continuous. F.e. a national road can stop when it meets a ring-road (who have their own ref system in many countries), and start again on the other side of that ring road. Expressing this with route relations would be silly: routes are supposed to be continuous, our refs aren’t.
The fact that the EU also gives their own ref to the road doesn’t change that principle. They use their EU ref to name the road, while nations use their national ref to name the road. In most cases, the nation prefers to keep using their refs and their refs only. In other cases (like Belgium), the nation adopts the European reference system, and is phasing out the legacy national refs where EU refs can take over (that means sings get replaced, maps get updated, …).
This is completely different from route refs, where a route is bound to be continuous, thus some roads belong to multiple routes. The route reference system you mention is indeed more similar to PT, bicycle and pedestrian routes than to the European ref system.
The difference is IMO big enough to need two ways of tagging. So I agree with Richard: you can go ahead with the US (though the US community should decide on this), but the schema you propose won’t work very well for Europe.
Comment from robert on 6 November 2015 at 19:38
So how would id users supposedly edit them?
Comment from Govanus on 6 November 2015 at 21:37
->robert:- in id select a way to include go to the bottom of the way setings pannel on the left of the screen click on the arrow to open the relation editng sub-part if not already expanded chose a new relation or pick one you have made for the previous way that shows in the list of local relations(id picks local ones so you may need to zoom out and around so it picks it up in the list -working from the end of one way to the next should be sufficent for id to work in most cases)
selecting a pre made one just adds it to the list clicking on the relations name in the tag box brings up the relations settings editing pane similar to other feature where you add new tags look at other members of the relation and the relation to a superseting relation (one with the current relation as a mere member to the beiger relation.
chosing new lets you name it then you canmove on or click on its name like above and start tagging and adding to larger relations.
I hope that gives you a start
as for the tags I’d look at copying the E05 (aka A34) or E30 (aka M4) near the city of Oxford, UK, Europe which mainly only show in relations mainly. or try the locations that the original author has been working on, if my suggestions are currently in bad repair.
Comment from Govanus on 6 November 2015 at 21:59
This is a good suggestion it was a nightmare on my first edits trying to int-ref tags to the M27. As routing lines are going to get evenmore cutup in the uk at least if we start spliting all the parkbay rule changes and lane and width changes that there is presure for (Hilltop road near the large park called south park in Oxford UK, EU is due to be split into 30-50 parts and its only a few 100 meters long!) Also this could solve problems that croped up in other parts of the uk with the rights-of-way system clashing with the road numbering for highway purposes (independent legislation and sometimes seperate local authority departments in carge of them). Its true you can create new forms of ref but oftern these are made with little advertisement to end users or even original contributers in some known cases leading to rendering breaks that don’t get spotted sometimes till complaints come back form users of finished maps. Using relations alows multiple equal priority (who the ref tag right of way, cycleroute or highway or even waterway code ref in some places of towpaths and the like, not to mention any campus ref’s that might try to get overlaied). I know expanding ref forms solves a lot of problems and tring to tag the relation as to what a ref is a type of needs explaing in the tagging of the ref, but the fact that editing long routes downloading full routes and routeing to a set route is improved with the binding effect of the relation is a good thing. Relations also offer capacity to add multiple discriptive and note tags and aid in OHM with time ralated notes.
If we had controlled the development of ref alternatives rather than some being altered without warning we could handle thing with those but relations offer more and solve more so agree with the original author that they should get supported more and begining being used.
Comment from jremillard on 6 November 2015 at 22:52
Perhaps somebody could work out a procedure for quickly making relations from existing ref tags?
Comment from Baloo Uriza on 7 November 2015 at 07:11
@Sanderd17: That’s not true at all, or the cycleway and walking networks would have the same refs as the motoring network. It took me all of 15 seconds and zero effort just zooming in on a random location and finding a duplexed ref (in this case, road A27 and RCN CS7 in London).
Comment from Baloo Uriza on 7 November 2015 at 07:12
@robert: If id is unable to handle relations in a rational manner, given that relations are a basic data type alongside ways and nodes, that’s a major deficiency in id and should be pointed out to the devs.
Comment from Govanus on 13 November 2015 at 21:20
I’ve been thinking on this for a a while and Sanderd17 dose have a view but some of the ideas aren’t as universally true across the continent of Europe as whole the UK was like the one number system but it dose have a mess for some routes that shunt major routes though towns and so one even large one either has to disappear or the local authority (its there choice as they make most non-strategic road network signs) decides to add both for some half a mile or less to avoid though traffic confusion. The UK has also been spending much of the last century re-developing its road system and so a nice system in the 1920’s doesn’t equate well in the present so the A34 used to run from the Hampshire coast to Manchester {after being extended I think in the 1930’s old was similar to this } (I don’t know if it ever made it further north) but there are three highly separated parts at least :- M3-M40 A section running into Birmingham centre and one from central Manchester south. But that doesn’t have the problem suggested as the chopping and traffic diversion was the official solution.
There rights of way issue was a local mapping problem in Oxford with a bridleway number becoming rendered as a road number as it was defined not only in highway legislation but originally in rights of way legislation so in the absence of an assigned number for that stretch of road it was automaticly mapped as the great “320/30/10” from the great “Glanville Road” to exit of the “Oxford Spires Academy” car park and a path leading to a paddock {now disused due to intimidation of the horses by the local children from the new estate and the academy when the fences were changed} and a park!
Its a bit of a wide misconception that the EU is somehow responsible for E numbering in Europe - it isn’t and never was. It actually is the quiet effect of the local offices of the United Nations that set them up and works with countries to implement the plans. In this respect the EU is just another country of level of planning bureaucracy to liaise with. The EU has money and plans (see Trans-Europen-Motorways) of its own but the numbering is a UN co-ordinated effort. Both the EU and the UN attempt to do a similar role for major railways and the EU also used to do waterway traffic too.
As the UN is global the some other local offices have looked a copying the idea and so Vietnam proposed to bring a scheme into Asia (originally known as the Asian Highway). So AH roads can now be found at the ends of West-East E roads. For example you can drive from Cork in Ireland on the E30 and with a couple of ferry links can find the road turning into the AH6 as you go through the Urals (I think they overlap a lot locally) and then follow the road though all the way to Busan in the south of South Corea ready for a ferry to Japan!
The Americas has a sort of Pan-American highway system though south American and into the North American systems and Africa also has some semblances of a pan-African system (cold-war stirrings of coups, civil wars and economic problems hampered it a lot but transcontinental road traffic is big business there now).
Making a system that is universal adoptable makes it simpler for data users to get useful consistency. An end to simple ref ‘ing here an prow-ref there and near random misuses of varieties desc and name don’t in the end help the simplifying consistency aim.
Relations are still new to some people and to be fair the whole of OSM is new to others being only around a decade old (when is the party date?) but if we learn from the ad-hoc past and properly plan some world wide consistent uses for the likes with ref’s and joining up roads splintered by parking, lanes and areaised traffic islands. Before parts feel they really need it and other go on doing it differently again (like as now). We could produce a better end database for everyone in the future.
In such a good spirit I hope to formally get all my evolved tagging developments properly into the main wiki-manual soon too.
Comment from Govanus on 13 November 2015 at 21:23
correction above I used an “of” instead of an “or” in third paragraph.
Comment from Govanus on 13 November 2015 at 21:36
@jremillard I like your thinking. If we figure out a good schema for the relations ref’s first then role it out and use a semi-automatic tool to find a help migrate especially when things become splintered too much and it becomes a big chore otherwise. I that the first rollings out will need to be dual then an announcement then the old now duplicated tags are removed of the ways (making them leaner and easier to handle). The short gap gives time for data users to test out new formatting codes on the new relations before the old ref’s start leaving and the data users can parse for both and not have any side-effect if either of options is on its own.
Comment from Govanus on 13 November 2015 at 21:45