Semi-automatischer Edit der GTFS-Tags (Feed DE-HE-REB) in der Region Fulda

Hallo an euch,

ich habe eine Frage an die, die sich mit ÖPV und speziell mit GTFS auskennen.

OrganicMaps hat angefangen, Fahrpläne usw. mithilfe der GTFS-Feeds in der App in Echtzeit verfügbar zu machen, was für ÖPV-Nutzer eine ungeheuere Hilfe ist. Zur erleichterten Einpflegung haben die diese Seite erstellt: https://gtfs-osm-matcher.organicmaps.app/
Das Feed, was für Deutschland benutzt wird, ist DE-complete (Quelle: https://gtfs.de/).
Bei mir in der Region gibt es noch den Feed DE-HE-REB, was ich in den letzten 2 Jahren zumindest stadtweit eingepflegt habe. Leider wird der von OrganicMaps (bisher) nicht benutzt. In der entsprechenden Wiki-Seite wird u. a. beschrieben, dass der Tag gtfs:feed veraltet ist. Stattdessen soll der Feed in die übrigen GTFS-Tags eingesetzt werden, z. B. gtfs:stop_id:DE-complete=*
Das ermöglicht die Einpflegung von mehreren Feeds, ohne dass sie sich in den Tags kollidieren.
Zur Vorbereitung will ich einen semi-automatischen Edit bei den Haltestellen und (Master-)Routen mit GTFS-Tags durchführen.
Folgende Tags würde es betreffen:

  1. Bei Haltestellen public_transport=platform
    gtfs:stop_id=*gtfs:stop_id:DE-HE-REB=*
    gtfs:name=*gtfs:stop_name:DE-HE-REB=*
    ref=*gtfs:stop_code:DE-HE-REB=*
  2. Bei Routen type=route mit route=bus
    gtfs:route_id=*gtfs:route_id:DE-HE-REB=*
    gtfs:shape_id=*gtfs:shape_id:DE-HE-REB=*
    gtfs:trip_id:sample=*gtfs:trip_id:sample:DE-HE-REB=*
  3. Bei Master-Routen type=route_master mit route_master=bus
    gtfs:route_id=*gtfs:route_id:DE-HE-REB=*
    ref=*gtfs:route_short_name:DE-HE-REB=* (ref wird behalten)
    Zusätzlich gtfs:route_long_name:DE-HE-REB=* (Beispiel bei ref=1: gtfs:route_long_name:DE-HE-REB=Aschenberg Ost-Frauenberg-Stadtschloss-Ziehers Nord)
  4. Generell
    gtfs:release_date=*gtfs:release_date:DE-HE-REB=*
    gtfs:feed=DE-HE-REB wird entfernt

Wird PTNA dann meckern, wenn ich an den Tags den Feednamen dranhänge?

PS: Dieses Thema bezieht sich zwar auf DE-HE-REB, aber trifft bestimmt auch auf andere Feeds zu.

Unabhängig von der allgemein erforderlichen Diskussion über den geplanten Import und ob (?) die Daten von anderer Stelle mit anderer Lizenz erhältlich wären:

Ich verstehe noch nicht ganz, wie die Lizenz geregelt ist. Wenn man hier die “kostenlose” Version nutzt, dann steht dort “CC 4.0”.

Würde Deed - Attribution-NonCommercial-NoDerivatives 4.0 International - Creative Commons also gelten, dann wäre das nicht mit unseren Bedingungen kompatibel (“NonCommercial”).

Hallo @greenie11,

magst du bitte im Titel des Threads ergänzen, um welche Region es geht. Im Text steht nur “DE-HE-REB”. Wer oder wo ist das?

Sind die GTFS-IDs stabil oder ändern diese sich jede Woche?

Ich sehe dein Anliegen allgemein mit Skepsis. gtfs.de bereitet die Fahrplandaten aus ein oder mehreren Quellen auf (mein Arbeitgeber hat dort auch schon einmal eingekauft). Es gibt aber mancherorts mehrere parallel veröffentlichte GTFS-Feeds, z.B. den vom DELFI e.V. und einen vom Verkehrsunternehmen selbst.

In OSM sind wir eher zurückhaltend, was die Aufnahme von Fremdschlüsseln angeht. Wir haben jetzt schon die DHID, die Ril100 (nur Eisenbahn und einzelne Straßenbahnsysteme), UIC-Nummern, IBNR und mancherorts GTFS-IDs. Von den GTFS-ID sollte meiner Meinung nach nur eine erfasst werden.

OSM ist keine kostenlose Datenbank für Drittanbieter-Apps, wo man sein Haltestellen-Mapping abladen kann. Es kann IMHO erwartet werden, dass Konsumenten mittels bereits der zahlreichen bereits erfassten Fremdschlüsseln (ref:*=*), durch Namensgleichheit, Namensähnlichkeit (wir erfassen oft mehrere Schreibweisen) und räumliche Nähe (falls der Feed Koordinaten hat) die Zuordnung vornehmen.

Viele Grüße

Michael

3 Likes

PTNA unterstützt derzeit nur den Punkt 1., nicht die Punkte 2., 3. und 4. - das wäre aber machbar.
Bei Punkt 4. würde ein Fehlen von ‘gtfs:feed’ zum fall-back ‘network:guid’ führen, wenn das fehlt zum Namen der Auswertung (z.B. DE-BY-MVV)

Haltestellen können durchaus von mehreren Verkehrsverbünden angefahren werden.
Da macht der feed-Suffix durchaus Sinn.

Bei den Punkten 2. und 3. sehe ich nicht so richtig, dass eine Linie aus mehr als einem Feed kommen sollte, in OSM getagged werden sollte. Das macht die Wartung nicht einfacher.
Aber immerhin könnte man sich das ‘gtfs:feed’ sparen.

Da könntest du noch ‘gtfs:platform_code:feed_suffix’ hinzu fügen, das würde auf ‘local_ref’ abgebildet.

Problematisch bleibt die Lizenz der Daten.

Gemacht. Auf den Rest der Beiträge gehe ich noch ein

Edit: Ich schlafe eine Nacht und mache nichts, bis ich das Thema besser verstanden habe. Grob sehe ich aber wenig Sinn, zumindest was den Import-Teil angeht.

1 Like