Thanks!
I must have been very blind not seing ‘history’.
No, there is no geolock. I meant: I cannot find ‘history’ elements
I just added analysis support for gtfs data for public-transport to ptna for
- DE-NW-SWM
- Stadtwerke Münster
- which is part of the DE-NW-WT
- Westfalentarif
- Region Westfalen, North Rhine-Westphalia, Germany
BTW: City of Münster is where the FOSSGIS 2025 conference (in German) will take place at the Fürstbischöfliches Schloss (Castle) from Wednesday, March 26 to Friday, March 28, followed by the OpenStreetMap Saturday on March 29th.
See you there!
I just added analysis support of public-transport data in OSM to ptna for
- US-NV-RTC
- Regional Transportation Commission of Southern Nevada
- Clark County, Nevada
- CSV data in OSM Wiki has been prepared listing what has been found in OSM
- this may differ from reality
based on discussion Bus Transit Data - import
1 Like
Asking for quick help from German and French speakers. I’m making some changes to how the text above the CSV data in the wiki appears. I’ve put this header text in a template to be transcluded into each page. This would make it easy in the future to improve wording, or write a better “how to use and edit this page” introduction. The larger goal is to make PTNA more approachable, little by little.
Currently there are just two sections to this header:
- Link to the documentation of the CSV format:
|#default|en=This page follows the PTNA CSV format. For more information, see [[Public Transport Network Analysis/Syntax of CSV data]]. |de=Diese Seite entspricht dem PTNA-CSV-Format. Für weitere Informationen siehe [[DE:Public Transport Network Analysis/Syntax der CSV-Daten]]. |fr=Cette page respecte le format CSV de PTNA. Pour plus d'informations, voir [[FR:Public Transport Network Analysis/Syntaxe des données CSV]]. - Link to the PTNA analysis page (optional but IMO very useful):
|#default|en=Results of this analysis: |de=Ergebnisse dieser Analyse: |fr=Résultats de cette analyse :
What I’m asking is simple: firstly, please make sure these translations to French and German are good. The 2nd one was translated by DeepL, I don’t know how the 1st one was translated.
Secondly, if you feel you can improve the wording of even the English version, feel free to do so 
See this template in action:
In English
In German
In French
You can edit the template on the wiki, but if you don’t feel comfortable doing that you can tell me your translation here and I’ll update it.
Currently the template is only used in those three CSV (and in the Israel CSVs), but soon enough I think they will be applied to all CSV pages on the wiki.
1 Like
Looks good for the French part. Thanks a lot.
1 Like
Looks also good for the German part, thanks.
I’ll have some time this afternoon to work on the other parts.
1 Like
Some news on GTFS injection into CSV data in the OSM wiki.
The code and catalog is ready but not yet published.
We’ll start with DE-BW-bodo
Shall I replace the current CSV data with the prepared one, publish the GTFS catalog and thus enable test via “Test CSV”? The link does not work at the moment.
2 Likes
I say go for it! What’s the worst that could happen?
Yeah, revert edits in OSW Wiki only.
I published all, for DE-BW-bodo you’ll find the (T) icon on the DE-page in the last column.
This will start a test injection without updating the CSV data in the Wiki.
Yo may edit in the Wiki and then start a test injection again
Once you’re happy with the result you can request a new analysis run on the report page.
1 Like
Yay! I hope it goes well. @mcliquid, any and all feedback on this feature would help us improve it!
If any more information can be gleaned from the GTFS feed that would be useful for filtering, we can make that happen. For example, the Israel GTFS feed names the city of each bus stop. This is used to create a list of cities each route stops in.
Example can be seen here: https://ptna.openstreetmap.de/en/testcsv.php?network=IL-HA-Haifa
- catalog_number: '35030', city: 'זבולון,קרית אתא,רכסים', internal: 'yes'
30;bus;מק״ט: 35030 ([https://markav.net/line/35030/ מר קו]);קרית אתא - מרכז;;אגד;IL-MOT;28562
The ‘city’ hidden variable lists the 3 cities this route stops in: זבולון, קרית אתא, רכסים
DE-BW-bodo currently does not have any hidden variables. Hidden variables are only visible in the injection test page, not in the final CSV uploaded to the wiki.
If you have any more questions, feel free to ask.
@bergaufsee I think we will do DE-BE-VBB next. (Actually, @ToniE, do you think we can do it right now too?)
Actually, yes. It is a matter of few minutes only. Copy two files from bodo to VBB, download and analyze the GTFS and call the post-publish.sh manually.
The rest is manipulating the CSV data.
I can start in 2 hours or so: 23:00 CEST
1 Like
DE-BE-VBB is ready to be used with GTFS injection, but there are some reports although injection is not yet configured in the CSV data (using ‘@…’)
A template with some @ is available here, but has never been tested and might wreak some havoc: Verkehrsverbund Berlin-Brandenburg/Analyse/DE-BE-VBB-Routes/Template test - OpenStreetMap Wiki
I’ll try it out myself.
I’m not sure what to do about those errors. Are these routes duplicated in the GTFS data, or are they distinct routes with some subtle difference we’re missing?
I checked train RB25, appears twice with different GTFS-route_type but otherwise identical.
I checked bus 652, appears also twice with different GTFS-route_type and otherwise nearly identical.
Sounds like the importer should remove one of each. Are these route_types only used for duplicates? Or are there some unique routes with each route_type?
Apollo 13: “Houston, we have a problem!”
e.g. GTFS: “S5 Suburban Railway” is mapped to OSM “S5;train”
Some mappers actually map this as route=light_rail (e.g. in Berlin) and not route=train (as in Munich)
route=light_rail never made it to an approved value, discussions are ongoing and mostly put “on hold” - don’t touch it.
This is the current global mapping of GTFS-route_type to OSM-route
route_type,sort_key,string,osm_route
109,1600,"Suburban Railway",train
During the import of an individual GTFS feed I could change this on a per-feed-basis to “light_rail”. What else can we do?
Interesting. I just encountered this issue in the CSV page and left a note about it.
If there turn out to be too many problems then we should restore the last hand-crafted version of the page. I’ll let you and @bergaufsee decide.
I’ve seen many GTFS-route_type=Bus with no corresponding route_type=Bus-Service
I think we should maintain this section (where light_rail is used) manually and not by the injector.
=== S-Bahn
S1;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S1;light_rail;2024-01-05 - 2024-12-14;;;DB Regio AG
S2;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S2;light_rail;2024-01-05 - 2024-12-14;;;DB Regio AG
S3;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S4;light_rail;2024-01-05 - 2024-12-14;;;DB Regio AG
S5;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S7;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S8;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S9;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S25;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S26;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S41;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S42;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S45;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S46;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S47;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S75;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
S85;light_rail;2024-01-05 - 2024-12-14;;;S-Bahn Berlin GmbH
1 Like
The U lines seem to be train in the import, but subway in the handcrafted CSV.
Really getting the sense that a specialized import script is needed. Maybe this is a good opportunity for me to show you how to do that! Let’s talk about it in private messages - but let’s do that tomorrow, I have to sleep occasionally
1 Like