They’re causing some issues with the CoMaps map generation and I don’t know how to fix them . See the VK validator for details (the CoMaps one hasn’t been updated yet).
As it says: there are two type=route_master relations including each as member.
It would be safe to delete one route_master (the “younger” one).
Route_masters must not have ‘role’ set for their members (here in one of them: ‘northbound’ and ‘southbound’)
I don’t know whether this will fix the CoMaps problem.
Any feedback/corrections will be gratefully received: I feel more than a little out of my depth here. As such, I think it may be best if someone else (possibly you @ToniE) tackles:
It would be safe to delete one route_master (the “younger” one).
I’d probably break everything (though for all I know I may have done that already )
Thanks for clarifying. I’m not sure what the ref would be in that case. The operator’s website just calls it “Trains from London Liverpool Street to Cambridge”. A similar relation with the same operator has a ref number but the source given in the changeset is just “knowledge”. Some train routes don’t have ref, others have the operator acronym as the ref.
In the stations, assuming they’re following what I’ve only ever seen done in the UK, intercity train routes aren’t given names, the announcer will just say “This is the 12:34 Greater Anglia train to Cambridge stopping at X, Y, Z”.
We again had some complains in the newest CoMaps PreRelease about London Transport relations beeing broken again. For some users it seems to them like the public transport mode does not work at all in London (We have now like 3 of recent map generations with London Metro map not working).
Is there something that could be done to make these relations break less often in the future?
Indeed, they are part of the Glasgow Subway and Merseyrail respectively (which are both passing validation with warnings). This thread is exclusively about London, which is currently failing validation (as it often does).
The information there is not actionable. It says, and I quote in full:
London Y J M sub: 11 / 11 lr: 16 / 23 st: 678 / 772 int: 47 / 49 ent: 17
🛑 Errors
Found 16 light rail lines, expected 23
Found 678 stations in routes, expected 772
I have no idea what “these relations” are. I vaguely know what CoMaps is, but have not used it. I don’t know what the “London Metro map” is.
People editing OSM often don’t understand the full impact of the data that they’re editing. Some parts of the “design” of particularly PTv2 relations are very prone to “breakage”. Someone who cares about this stuff needs to explain, when something has gone wrong, to the user that it happened to what they “did wrong” and what they can do in the future to avoid it happening again.
I do something similar for some foot and cycle routes in UK and IE, and an example changeset comment following a breakage is here. What happened there was that the mapper tried to make OSM reflect the reality of a separate cycle route on a road, but didn’t quite understand the implications on e.g. foot routing in the area. My comment there (a) explains what is wrong (b) links to something that demonstrates the problem and can be used to test that it is fixed and (c) invites further conversation. I often link to the various “instant validation” options (like JOSM’s) as a way of testing that a change has worked, too.
This level of conversation is what needs to happen on every breakage. The “someone who cares about this stuff” probably needs something in place ahead of a CoMaps build to detect problems as they occur, but at the very least they need to know what to look for.
Ah yes, the VK data is from 2025-11-02 and the CoMaps data is from 2025-10-27. So there was an issue but it has since been fixed (not until after the CoMaps map data update though).
Each project running its own instance of the Subway Validator is not optimal. I’ve spent an hour or two trying to fix issues that had already been fixed . Perhaps there should be a global instance, like how there’s https://taginfo.openstreetmap.org but also different instances run by different groups? That’s a topic for a different thread though
100%. The warnings and notices have plenty of info but the most important section is wonderfully vague
I think now everything critical should be fixed. Thanks whoever did that! Hopefully the next map will also include London Metro again.
But we will only know for sure when the new map data finishes generation.
. See the VK validator for details (the CoMaps one hasn’t been updated yet).
)
(eg relations, stop_positions, etc)
. Perhaps there should be a global instance, like how there’s 