x

Re: PTNA - News: GTFS-Analyse


Geschrieben von ToniE (Gast) am 03. Mai 2020 11:47:04: [flux]

Als Antwort auf: PTNA - News: GTFS-Analyse geschrieben von ToniE (Gast) am 23. März 2020 16:30:

miche101 wrote:

Ruftaxi 5403 Ruftaxi

Mmh, muss da nochmals ran ... Schritt für Schritt den Code verbessern ...

Hier ist "5403 Ruftaxi" = gtfs:route_short_name -> 'ref' in OSM
Und "Ruftaxi" selber ist der umgesetzte gtfs:route_type
name = gtfs:route_type + gtfs:route_short_name: + ...

Eventuell das zweite Vorkommen von "Ruftaxi" löschen, wenn es vorne schon vorkommt.

miche101 wrote:

PS: Magst du die ganze IDs da taggen, wenn man nicht mal weiss wie beständig die sind?

Gute Frage, ich nehme an, dass "gtfs:route_id" recht stabil ist, zumindest 1 Jahr lang: "s20" könnte für "Saison 2020" stehen.

"gtfs:trip_id" könnnte genauso stabil sein, wenn denn der Trip (die Variante) das ganze Jahr angeboten wird.
Andernfalls muss ja auch in OSM nachgebessert werden.

"gtfs:trip_id:like" habe ich für eine DB-Abfrage genommen um die Abfahrzeiten von identischen Trips zu ermitteln.

Zusätzlich, wenn vorhanden, wird noch "gtfs:shape_id" ausgegeben - die ID der Fahrstrecke.

Ob man bei "ref_trips" die lange Version nimmt wie hier, oder den verkürzten Wert (wie bei gtfs:trip_id:like, ohne '%') wäre Geschmackssache.

"gtfs:*" oder "gtfs_*" gibt es schon einige Male in Taginfo. Ich habe mich für ':' als Trenner entscheiden, da 'gtfs' den Namensraum definiert, ähnlich wie bei access:*, turn:*

GTFS-spezifische Dinge zu denifieren könnte evtl. für Apps wie OsmAnd interessant sein.
Ich hatte auf der SotM in Heidelberg den Vortrag der OsmAnd-Enwickler gehört und anschließend mit einem der beiden gesprochen.
Deren Problem bei ÖPNV-Navigation ist derzeit, wie sie von einer OSM-Relations-ID (+ tags) auf die Trip-ID in GTFS kommen um weitere Informationen zu erhalten: Abfahrzeiten, an welchen Tagen, welche Uhrzeit. Das könnte man mit "gtfs:trip_id:like" unterstützen, sofern ...

Sofern die Trip-IDs einem entsprechenden Muster folgen, was hier der Fall ist (meine Interpretation, reverse engineering):

1.T0.18-540-3-s20-1.1.H

  • 1 = 1. Fahrt am Tag
  • T0 = Auskunft über 'service'-Zeiten, in welchem Zeitraum (Monate, ...), an welchen Tagen, ... entspricht wohl 'service_id' aus 'calendar.txt' und 'calendar_dates.txt'
  • 18-540-3-s20-1 = route_id
  • 1 = 1. Variante von mehreren
  • H = Hinfahrt (R = Rückfahrt)

Dieses beim MVV sichtbare Schema scheint von der Software von "Mentz DV" zu kommen und kann bei vielen anderen GTFS-Analysen von PTNA gesehen werden. Eine entsprechende Unterstützung in PTNAs GTFS-Analyse kommt nach und nach, wenn ich die Dinge selber analysiert und verstanden habe.
Siehe auch letzte Zeile der Tabelle in: https://ptna.openstreetmap.de/en/gtfs-d … -osm-table

Gruß,
Toni