Idea: Create a platform which actually manages PT-Relations for switzerland.
General Steps:
Remove/Upgrade all outdated data
Detect differences (only ptv2)
Apply differences (only ptv2)
Not in consideration:
All infrastructure (rails, platform, stations, streets) isn’t part of this. Depending on the outcome of New public transport ids/modelling in Switzerland - #4 by SaschaBrawer this point will be reevaluated.
In the past “Fahrplanfelder” were commonly used to define rail routes. Effectively they have since been replaced by “Streckennummer”. So all “Fahrplanfelder” could deleted (since they were tagged wrong party done by me) and the “Streckennummer” can be added for all rail routes. They are available in the ‘RADN’. But there I don’t have any information about the licensing. Also see discussion at: Changeset: 179083959 | OpenStreetMap
Step: Remove/Upgrade all outdated data (manual):
I’ll manually delete pt relations, which don’t exist anymore and upgrade all pt relation which don’t have any version, or are at version 1 to ptv2. Progress: overpass turbo - Swiss edition
Step: Referencing (manual):
Bus relations can mostly be referenced with the osm “nat_ref” and the swiss line id from opentransportdata.swiss.
Train relations don’t have any reference point to opentransportdata.swiss. So i’ll add a nat_ref to the train relation (on the master route relation) with the value of opentransportdata.swiss.
From those points/connections on, we should be able to hop across the connections to retrieve all necessary data.
For other modes (ship/trams/gondola) i’ll apply the same solution as for the bus/train relations.
OSM Wiki:
There are several entrys about the PTN in switzerland. Some of them have outdated and/or only manually updated informations. I intend to either automatically update the information or remove them from the wiki (example: Switzerland:Public Transport/Railways - OpenStreetMap Wiki Fernverkehr lines are incomplete). Exact actions will be first proposed here, once ready.
Looks like a cool project, but I don’t (immediately) see what you want to achieve that cannot be done with ptna.openstreetmap.de already – apart from potentially matching SLOIDs/SBOIDs etc. The PTNA project also uses GTFS data from opentransportdata.swiss (through a proxy hub, cf. here).
In PTNA you can compare OSM relations against the GTFS feeds/opentransportdata.swiss which I think is what you are trying to achieve here, isn’t it?
Adding the Streckennummer references is something entirely different than keeping the route relations up to date, isn’t it? Are Streckennummers covered by opentransportdata.swiss datasets?
Differences to PTNA would be:
To my knowledge someone has to manually add/import all the groups/lines into PTNA for every timetable year. And the connection between GTFS-OSM is only made by the gtfs tags in osm. Those get a new id every year, so someone has to update every relation with the new id, before PTNA can compare them again.
–> For my system I envision the connection via the Swiss Line ID, which doesn’t change every year (if the line stays the same eg. IC5 stays IC5, or Bus 103 stays Bus 103). Further more with this approach we could automatically identify missing version of a line, line no longer existing…
Once the exact GTFS-Feed and Relation Combo is established the comparison would be the same as PTNA.
In addition I would like to provide automatic edits. For example if the system finds a new line, it would propose the needed changes and apply it if wanted. After the timetable change I envision it could update the GTFS-Feed automatically for example.
(–> PTNA currently just compares existing GTFS with the corresponding Relation)
Note that the BAV/SBB already commissioned and has some QA tools for checking stop locations etc. it’s not quite ready for prime time but I suspect it will be soon. @datendelphin is more involved in this than I am and knows more.
Yeah, that’s pretty true. Stable “route_id” values are recommended by the “GTFS best practices” many feeds do not follow this.
route_id=91-1-B-j26-1 indicates that this is for the season “2026” (“j26”) and the last digit indicates the version of this route in 2026 (changes due to constructions, …). So, with a little luck, you’ll not only see a new route_id in December (change of time tables) but also in between.
The values of GTFS’ trip_id even change more often.
All depends on the owner and software used creating the GTFS feed.
We’ll have the monthly OSM pub meeting tonight here in Munich, DE.
There, I want to discuss some potential improvements, hmm, enhancements in comparing GTFS with OSM: calculate and present the mismatch score in the daily PTNA report, not only on-demand in the web-browser. Let’s see.