Hello,
the past few months I’ve been adding a lot bus routes in my local area to OSM.
I’ve been using the PTv2 scheme to do it
One thing I have noticed when using the https://relatify.monicz.dev/ tool to check my work:
the ID editor seems to keep mucking up my work!
That is: it keep spontaneously re-ordering the ways in my bus route relation
Under PTv2, it’s important for stops and way to be present in a relation in the right order.
ID doesn’t seem to interfere with the order of bus route nodes, thank goodness,
but it just shuffles the ways around
This is disastrous for bus routes where the bus doubles-back on itself or takes a side loop before continuing: as I understand it, PTv2 just wants you to include each way (untagged with any role) each time it is traversed by the bus, in the order the bus encounters them. (So, if a bus doubles back on itself, that way has to be present in the relation twice).
Just to be clear: it’s got nothing to do with merely editing bus routes in ID per se –
the scope is way wider than that - any time ANYONE uses ID to split ANY road, for whatever reason,
and that road happens to have a bus route on it, ID is gonna chew up the bus route like a wrecking ball
In other words: the PTv2 scheme is ‘not ID safe’.
But ID is the default OSM editor!
Frankly I’m surprised there’s any bus routes left working at all
After creating routes in both iD and JOSM, I’m of the opinion that iD’s relation editor just flatout sucks and for routes it’s better to edit them in JOSM for a multitude of reasons:
Editing a relation in JOSM opens up a separate window so you still can edit them when you want to select member elements whereas iD only allows you to add elements to a relation through a dropdown menu on the members (which sometimes is missing the desired relations even by typing out the desired relation by name).
Editing members (sorting, changing the roles and removing them) can only be done individually in iD but multiple can be selected in JOSM.
Related to the above, the sorting tools of JOSM are superior such as the ability to reverse the order.
You can easily see which elements have been added already and which one haven’t been in JOSM in the relation editor.
You can also clone relations in JOSM to create missing branches which would have solved quite a few headaches back then when I added a branch of an existing line.
On a more minor note, JOSM’s relation editor also displays multiple ways as one line in the member table which is quite handy to find gaps in routes.
iD is fine for many other situations (particularly for quick and small edits) but complex relations like routes (especially PTv2 where the order is quite sensitive) isn’t one of them.
It is both a problem with PTv2 that doesn’t maintain enough information that the routes can actually be mechanically sorted, of iD unnecessarily trying to sort the relations (I was of the opinion that that had been fixed, does it really still do that?) and not being able to handle way splits with relation memberships.
Wrt the later: it is completely possible to split ways without breaking relations as long as you have access to the neighbouring ways (potentially the have to be downloaded) and they were already in the correct order in the route.
This is however where things already go wrong. There is no actual benefit to sorting routes (or any other relation fwiw) on geometry edits -particularly- when you are not actually generating a path that you algorithmically want to traverse (for example to generate a GPX track, or for animation purposes) . There -is- benefit to maintaining order and there is even more benefit to inserting new ways created by splitting in the correct position (not the same thing as sorting).
Even just inserting them randomly either before or after the split way would be better than the current behaviour, but doing it properly isn’t a big deal and just requires checking if the immediate neighbours of the split way in the relation are downloaded (for all occurrences of the way in the relation) and if they are not, download them. If the relation isn’t ordered locally around the way that has been split, then you can always either just show a warning or drop the user in to an relation editor, but even if you are doing the former you are not breaking anything. Correct behaviour definitely doesn’t require downloading of all relation members.
tl;dr sorting relations on geometry edits is misguided and simply doing nothing would be much preferable to the current behaviour.
PS: it isn’t as if this hasn’t been hashed out a dozen times before.
As Casper said above, it’s a known issue in iD unfortunately, and the best way to fix them is by going through JOSM. Can’t remember exactly the way, a plugin in there suitable for reordering members of relations, but that’s how bus (and any mass transit) routes are getting fixed.
It certainly does, Ed.
And it’s kinda exasperating to learn I’ve just re-reported an absolute car crash of a bug that’s been wrecking bus routes of over half a decade now! Oh noes!
To be specific, iD automatically attempts to sort the route relation’s members when you split any of its members. This is beneficial in the sense that, most of the time someone splits a roadway – say, because of a change in name, lane count, or speed limit – they don’t have any knowledge about every bus route that happens to traverse the roadway.
Where iD goes wrong is that it has to assume the relation starts out completely unordered and tries to sort the whole thing from end to end. This becomes a problem if it hasn’t loaded all the members yet and therefore doesn’t know which members to connect to which members. It’s the same reason why iD often doesn’t detect when you accidentally break a boundary relation.
iD could solve this problem in any of the following ways:
In the meantime, a mapper can accomplish the same effect more manually:
Download each member one by one before splitting a member. However, this is tedious and unlikely to happen in practice.
Go to the relation’s browse page on osm.org and click the Edit button. If the URL’s relation query parameter is set to the relation ID when opening iD, iD will recursively fetch the relation and its descendants at startup. However, this only works with one route relation at a time, not if multiple affected bus routes run concurrently along the same roadway.
Type the relation ID into iD’s main search bar and select the relation before viewing any of its members on the map. This is difficult to do in practice.
I’ve used these workarounds effectively when mapping a touristic highway route that goes up and down the countryside in a very roundabout fashion (no pun intended), loosely following a 19th-century military campaign. It often backtracks and even sometimes loops around a roundabout multiple times. The signs are so sparse that I sometimes missed a sign, so I had to go back and edit the middle of the route, putting the relation at risk of getting scrambled.
But I was intentionally mapping this route, not incidentally mapping a route that happens to touch something I’m mapping. I also got lucky because this highway route only has posted signs in one direction. I only had the map the route going eastbound and could ignore any separately drawn carriageway in the opposite direction. By contrast, some bus routes traverse a road in both directions, so the PTv2 scheme expects you to create a separate relation for the route in either direction.
I also made sure to include only the portion of each roundabout that the route actually traverses. I realize that some mappers prefer to always add the whole roundabout to a route. But this creates a loop that the sorting algorithm would have difficulty resolving satisfactorily. After all, it could indicate that the route goes all the way around the roundabout. (This could happen if a route has a stop along the roundabout itself.)
Traditionally, mappers have liked to keep the whole roundabout together as one junction=roundabout feature, but roundabouts often have to get split anyways due to changes in lane count, width, or ref – or a bus route that ends at a stop along the roundabout. Since we’re already deep into relation-land, we might as well split the roadway and use a type=junctionjunction=roundabout relation to tie the ways back together.
Bidirectional routes (which don’t conform to PTv2) and roundabouts account for almost all of the cases I’ve seen so far of iD scrambling route relations of any kind, not just bus routes. If we model the route relation to be unidirectional and avoid loops, then the scrambling is very unlikely to occur. But we know of at least one route that doesn’t involve either case, so there might still be a bug that’s unaccounted for. If you have a reproducible test case, please open an issue about it and link it to a relevant existing issue such as:
It’s tempting to conclude that iD should just remove the member sorting feature because JOSM has proven that it isn’t necessary. But I think this would be shortsighted compared to fixing the feature. If iD relies on mappers to sort route relations manually when appropriate, as JOSM does, then most mappers would not routinely sort the members when making changes. We might end up with an even bigger mess, affecting routes in general.
Moreover, I don’t see how PTv2 is specifically to blame here, this problem of breaking any route relation doing a large loop over itself will sadly also occur with a PTv1 relation.
I think we (OSM as a project) must decide whether we tolerate default editors of our map data which spoil existing-good route relations or whether a 'bot-sweeper (which exist or the pieces can be bolted together easily, geofabrik has had route checkers for many years) goes through and checks periodically looking for “bad (route) relations.”
Because, I don’t think we can have both without chaos, and/or a weird periodicity that is doomed to spiral out of control. How much chaos? Yeah, let’s control chaos as best we can. I could suggest that iD be programmatically neutered from writing type=route relations, as a start, I’m simply spitballing. Editors which wrong data which are right, we might want to nip that in the bud. And “snipping out” (code, functionality like this) can be simpler than feature creation from scratch.
I mean, I own these data, too. And I am not smiling when somebody or something knowingly messes them up. This is one of those cases where “something outweighing something…” guides. If an editor of our data is not up to snuff at writing certain data, we clip their wings (in those certain ways). Hey, we crawl, walk, run and sometimes fly. I never like saying (as to a young one) “you are grounded” but when necessary, necessary.
Maybe this has been talked about before (or to death); if so, let’s put a stake in its heart (now or soon).
Personally, I find iD’s relations so clumsy as to be effectively unusable. I don’t wish to dis (disparage) the editor entirely, I do use it for quick edits at times. Though, not for relations since in a long while when I gave up. When we have errors like these, let’s seriously trim this behavior sooner rather than later.
OSM has a lot of routes of many kinds to be proud of. Whether bus or otherwise, we shouldn’t have this.
this would require blocking all splits and combinations (merging) of ways which are part of at least one (route) relation. Rather than implementing this block, it should be tried to make these actions work as expected.
It (neutering iD) was a suggestion. It seems to have had a strong effect. It doesn’t seem likely we will agree to do this, but it has generated some conversation.
On the “positive, constructive” side of things, I use JOSM for relation editing. Something to consider.
Sure, but the issue here is not editing relations but simply editing ways which happens to be a part of a relation, which the mapper probably is not even aware of.
Creating and editing relations in iD is in many cases as simple as it could be. Removing this feature would make iD useless as standard editor for sure.
I suggested a rather simple solution at the related (duplicate) issue #7653:
Please just disable the automatic sorting feature, or, better still, make it activated by a button on the relation sidebar rather than ruining [sic] silently in the background.
At a minimum, disabling the automatic resorting by default would require a more robust UI for ordering relations manually. But I think it would probably uncover a lot of other issues that would be even more commonplace than this loop issue. If I remember correctly, automatic resorting was implemented in response to a lot of feedback that iD was mangling member order of perfectly linear relations, so those latent issues would need to be addressed at the same time.
Unfortunately, I must notice that development and bugfixing in iD has all but stalled lately. Granted, there was a huge leap during c. 2018–2021, largely due to @quincylvania 's involvement. Today, there is quite a lot low-hanging fruit that can improve user experience, but it does not get processed. Even the submitted PRs do not get reviewed and just hang in the queue forever.
I always find it a bit difficult singling out individual employees over others in such things. For example you don’t know how many hours/week Quincy was employed for vs. the current maintainer, where they have been told to set their priorities and so on.
There just seems to be something very wrong going on when the default OSM editor has a nasty bug that was logged 6 years ago and continues to mangle data, and it hasn’t yet been fixed. I mean if I wanted a map that bad I’d buy one from Fujitsu
As a frequent OSM editor, I raised this topic here on an OSM help message board, but I presume that some time in the last 6 years, this bug has been raised on some kind of iD-specific ticketing system?
