I just added the last of another 14 analysis of #public_transport for
- India
to ptna @ the sub-page for India
The empty entries will be filled during the next run @ 23:30 UTC
I just added the last of another 14 analysis of #public_transport for
to ptna @ the sub-page for India
The empty entries will be filled during the next run @ 23:30 UTC
I just started a new thread about comparing two GTFS feed versions using PTNA
I added analysis of #public_transport for
to ptna based on GitHub issue #93
gtfs support will follow later
I added gtfs analysis of #public_transport for
to ptna based on GitHub issue #24
I fixed a bug in GTFS analysis reported by @JesseFTW based on observations for US-MA-MBTA concerning shape_ids.
Shapes describe the route a vehicle uses to get from stop to stop.
Attention is required for example for the following situations where a shape_id may be
PTNA’s GTFS analysis did not handle the issue #1 correctly and aggregated both to a single trip, omitting one of the two shape_ids. This has been fixed - a trip is identified by the stops (stop_id) it touches plus the route (shape_id) it takes.
The fix will be available for all GTFS feeds downloaded and analysed started October 1st, 2023 and later.
See the details in GitHub for PTNA’s
BTW: PTNA’s GTFS analysis does not check whether two different shape_ids describe exactly the same route - I’ve seen some of them. I see this as a task for a GTFS validator, not for PTNA. And: is this actually a bug or “room for improvement”?
I just added gtfs analysis for the Netherlands
to ptna based on discussion in “GTFS in Nederland”
Hi, für DE-BE-VBB gibt’s Fehlermeldungen der Art Fehlende Linie für ‘ref’ = ‘RB23’ und ‘route’ = ‘train’, aber die Relationen sind doch da? https://www.openstreetmap.org/relation/15401288, https://www.openstreetmap.org/relation/303295. Was verstehe ich falsch?
Zunächst einmal die gute Nachricht: Die OSM-Daten sind korrekt!
Die GTFS-Daten des VBB listet die RB23 zweifach auf, warum weiss ich nicht, denn eine davon ist nicht im VBB-Gebiet sondern bei Insel Usedom (Beispiel).
Für die PTNA-Analyse habe ich seinerzeit (04.04.2020) die Liste der VBB-Linien aus den GTFS-Daten erstellt.
In dieser Liste ist die RB23 (mit Operator = DB Regio AG) nun doppelt enthalten und PTNA weiß nicht welchem Eintrag die RB23 im VBB-Gebiet zuzuordnen ist. Daher listet PTNA diese RB23 (und andere) unter dem Kapitel “Nicht eindeutig zugeordnete Linien” auf.
Wie kann ich’s beheben?
Für die RB23 kann der erste Eintrag (“RB23;train;19686_100;;;DB Regio AG”) in der Liste wohl entfernt werden, da diese nicht im VBB-Gebiet liegt.
Für andere nicht eindeutig zugeordnete Linien müssen ‘operator’ in der Relation und in der Liste übereinstimmen, damit PTNA eine Zuordnung machen kann. Sollte das nicht reichen, dann müssen noch ‘from’ und ‘to’ entspr. gesetzt werden (bitte in dem Fall nochmals rückfragen).
Die Liste im OSM-Wiki wurde bisher fast nur von mir bearbeitet - das ist aber nicht Sinn der Liste. Die Liste ‘gehört’ lokalen Mappern und sollte/kann von diesen jederzeit aktualisiert, korrigiert, neu-sortiert, anders strukturiert werden.
HTH Toni
I just added analysis of #public_transport for
to ptna
I just added analysis of public-transport for
to ptna
I just added analysis of public-transport for
to ptna
gtfs data has been added now
I have a feature request for the gtfs analysis.
If the stop name of the first or last stop contains common abbreviations, automatically change them to the long name in the tagging proposal for to
, from
and name
.
Example:
name
should be Sankt Bartolomä Ort instead of St.Bartholomä Ort
That has been implemented in the “normalization” step.
“St.” is a tricky part. Sometimes “St.” is the more correct form, so I skipped that.
But this special case (and others) can easily be added.
To avoid wrong expansions, the list of generic changes is rather short and the focus is on known cases
Generic cases:
Str\. -> Straße
Str$ -> Straße
str$ -> straße
str\. -> straße
Specials:
R\.-Diesel -> Rudolf-Diesel
Ludw\.-Ganghofer -> Ludwig-Ganghofer
Wobei man bei language=de_CH “Strasse” nehmen müsste - was nicht der Fall ist.
Maybe such “tricky cases” could be highlighted to raise the attention for manual checks?
For example:
St.Bartolomä Ort
Sankt Bartolomä Ort
And colour those table cells red.
Currently the
So, recognizing that “St.Bartolomä” is a candidate for expansion is task @ #1, but not done.
Marking tricky cases (colour, strike-out) is task @ #2, but there is no code for that and I want to avoid having analysis code here.
But: I can add “St.Bartolomä Ort” → “Sankt Bartolomä Ort” to the “normalization” step.
What I could add in general to task #2: mark all occurrences of all normalized names in light-yellow or so.
The Web-code knows whether there is the ‘name’ (stop_name, …) only or in addition also a ‘normalized name’
In Austria, the most manual corrections I perform are:
And those, which I believe can only be done manually
Yep, I’ll add the first 5 transitions.
I also change the layout of the Web-pages, adding a column, displaying the ‘name’ and ‘normalized name’. This will make the changes more transparent to the readers.