User talk:ToniE/ptna

Languages

Please use your favourite language. I'll translate with DeepL or Google if DeepL does not support your language.

Veuillez utiliser votre langue préférée. Je traduirai avec DeepL ou Google si DeepL ne supporte pas votre langue.

Por favor, usa tu idioma favorito. Traduciré con DeepL o Google si DeepL no soporta tu idioma.

Por favor, use o seu idioma preferido. Traduzirei com DeepL ou Google se DeepL não suportar o seu idioma.

Si prega di utilizzare la vostra lingua preferita. Traduco con DeepL o Google se DeepL non supporta la tua lingua.

Brug dit yndlingssprog. Jeg oversætter med DeepL eller Google, hvis DeepL ikke understøtter dit sprog.

Молимо вас да користите свој омиљени језик. Превешћу са Гоогле-ом.

Molimo koristite svoj omiljeni jezik. Prevest ću sa Google.

Diskussion

Danksagung

Bevor ich hier anfange zu kommentieren erst Mal ein große Danke für diesen Service. --Skyper 00:16, 26 July 2020 (UTC)

Kreisverkehr-Handhabung

Toni, Du hast geschrieben " Kreisverkehre

   Hier ist das Tool puristisch und erwartet, dass der Fahrweg in der Relation (in der Regel: des Busses) nur die Teile eines Kreisverkehrs enthält, die auch tatsächlich durchfahren werden
       der Kreis muss u.U. mehrfach aufgeteilt, d.h. in mehrere Segmente geteilt werden (Kreisverkehr-Puristen mögen hier stöhnen)

"

Ich war froh, das es Josm mittlerweile egal ist, ob genau der Teilweg des Kreisverkehrs oder der gesamte in der Relation angegeben wird. Nach meiner Erfahrung sind gerade neue Kreisverkehre oder Änderungen an Bestehenden der Grund, warum die meisten Relationen mit der Zeit nicht mehr durchgängig verlaufen. Daher wäre eine ähnliche Toleranz bei der Prüfung analog zum Josm sehr wünschenswert --Okilimu (talk) 18:49, 22 June 2017 (UTC)

Hallo Dietmar

Die Toleranz ist gegeben :-)

• Es wird derzeit lediglich der "Fehler" (nicht Hinweis) ausgegeben dass ein kompletter Kreisverkehr eingebunden ist, obwohl nur Teile davon befahren werden (Eintritt != Austritt)
• Das gilt aber nur für echte Kreisverkehre, "closed ways", die nicht bereits aufgeteilt sind
• Im (echten) Kreis selbst wird nach dem Austrittspunkt (gleich Eintrittspunkt des nächsten Weges) gesucht und von dort aus weiter analysiert.
• Der Weg zerfällt dadurch nicht in mehrere Segmente
  • es sei denn, der nachfolgende Weg (dessen erster oder letzter Punkt) hat keinen gemeinsamen Punkt mit dem Kreis
  • es sei denn, es ist kein echter Kreis "closed way", d.h. der Kreisverkehr besteht schon aus Segmenten
• Ich werde die Kategorie von "Fehler" auf "Anmerkung" ändern - von '__issues__' zu '__notes__' - kein Problem.

--ToniE (talk) 20:17, 22 June 2017 (UTC)

Namen statt Nummern

Für den menschlichen Nutzer deiner Analyse wäre es hilfreich, wenn bei Haltestellen oder Straßen der Name (mit) angegeben würde, soweit der bei Straßen verfügbar ist. Das hilft ungemein bei der Orientierung und gegebenenfalls dabei Schwerpunkte zu erkennen. --EvanE (talk) 20:07, 22 April 2018 (UTC)

PS: Deine Analyse Einbahnstraßen in falscher Richtung hat schon dazu geführt, dass ich einen Fehler bereinigen konnte.

Danke für die Anregung, habe es notiert und auch schon eine Idee, wie das umgesetzt werden kann. --ToniE (talk) 09:28, 23 April 2018 (UTC)

Ich habe gestern bei einer Reihe von Stop-Positionen das tram=yes ergänzt. Da wären Namen recht hilfreich gewesen, um zu sehen, welche parallel geführten Linien ich gleich mit bedient hatte. Wie auch immer ist deine Analyse ein sehr nützliches Tool, um ÖPNV-Relation in Ordnung zu bringen / halten. --EvanE (talk) 10:41, 23 April 2018 (UTC)

Ich habe mal einen ersten Entwurf für DE-NW-VRS laufen lassen. Es wird noch nicht überall ausgegeben. Sieht schon ganz gut aus --ToniE (talk) 20:01, 23 April 2018 (UTC)

Danke, das ging ja echt schnell. Es verbessert deutlich den Überblick. --EvanE (talk) 18:34, 28 April 2018 (UTC)

Endhaltestellen

Bei den Routennamen wird ja gefordert, dass sie den Namen der Endhaltestellen enthalten. Speziell bei Regionalbahnen und S-Bahnen wird aber oft nur der Name der Stadt angegeben ohne die spezifische Haltestelle. Das gilt zum Teil auch für die Stadtbahnen zwischen Köln und Bonn. Das ist für Bahnen, die mehrere Städte / Kreise durchqueren für die Übersicht oft die bessere Alternative. Zum Beispiel kann ein Kölner mit Bad Godesberg Stadthalle wie es bei der Bonner Linie 63 genutzt wird wenig anfangen. Mit Bonn-Bad Godesberg wie bei der Linie 16 zwischen Köln und Bonn genutzt, kann ein Ortsfremder das wenigstens einordnen.

Zwei Dinge könnte man mit einer geringeren und letztlich auch klareren Meldung behandeln:

• Bahnhof / Hauptbahnhof fehlt (zum Beispiel S23).

Bei End-/Start-Stelle fehlt ein Namensteil (xyz)

• Name der End-/Start-Stelle wurde um den Ortsnamen erweitert (zum Beispiel Linie 16).

Haltestellenname um Ortsname (abc) erweitert.

Leider habe ich keine Ahnung, wie aufwändig eine Realisierung wäre und ob das Mehr an Information den Aufwand rechtfertigt. --EvanE (talk) 18:34, 28 April 2018 (UTC)

• Ersteres (Beispiel S23) ließe sich recht einfach machen, denn

es fehlt einfach was - "Hbf" aus 'from'/'to' ist nicht im jeweiligen 'name'

• Zweites (Beispiel Linie 16) lässt sich ebenfalls recht einfach realisieren, denn

es ist etwas zu viel vorhanden "Bonn-" aus dem 'name' ist nicht im 'from bzw. 'to'.

Aber bei der Linie 16 ist es leider auch die Mischform: "Bonn-" wurde bei 'name' hinzugefügt während gleichzeitig "Stadthalle" in 'name' fehlt.

Ich schaue mir den Code mal an, in wie weit das recht einfach und zügig zu implementieren wäre. --ToniE (talk) 14:07, 29 April 2018 (UTC)

Den Wert aus from resp. to im Meldungstext anzugeben, ist bereits eine Verbesserung. So lassen sich leicht Tipp-Fehler oder Wort-Dreher erkennen. --EvanE (talk) 20:42, 6 May 2018 (UTC)

Die Namen anzugeben war ein voller Erfolg. Vor allem nachdem ich erkannt hatte, dass from und to nicht unbedingt die Namen der Endhaltestellen sein müssen. Dadurch war es mir in den letzten Wochen möglich die ganzen Bonner Bus- und Tram-Linien fehlerfrei zu bekommen. Mittlerweile bin ich auch im weiteren Umfeld tätig (Köln, Brühl, Rhein-Sieg-Kreis links-rheinisch,...) resp. habe meine Aktivitäten auch auf Bahnlinien ausgedehnt. Aber es immer noch sehr viel zu tun, speziell im rechts-rheinischen liegt noch vieles im Argen. --EvanE (talk) 21:45, 27 May 2018 (UTC)

Mehrere Route-Master

Die Fehlermeldungen in diesem Fall können informativer sein.

• There are '%n' Route-Maser for ref '%s' and network '%s'
• Damit kann die Anmerkung auch kürzer ausfallen:
  • Operator '%s' fits expected value.

Also kurz, knapp aussagekräftig. --EvanE (talk) 17:01, 21 October 2018 (UTC)

Stimmt, ich schau mal was ich bei den folgenden drei Meldungen an zusätzlichen/geänderten Infos bringen kann

* There is more than one Route-Master | Fehler | Route-Master: Es gibt mehr als einen Route-Master für diese Linie = 'ref' (verschiedene 'network'-tags?)

* There is more than one Route-Master | Fehler | Route: Es gibt mehr als einen Route-Master für diese Linie = 'ref' plus Eltern-Route-Master dieser Route

* This Route is direct member of more than one Route-Master: %s | Fehler | Diese Route hat mehr als einen Eltern-Route-Master (%s = Liste der Route-Master).

--ToniE (talk) 07:53, 22 October 2018 (UTC)

Wenn Du Dich auf den Bus N8 vom VRS beziehst:

* "There is more than one Route-Master", das ist noch ein Bug im Code und die Bereinigung im Rahmen eines größeren Code-Umbaus dauert noch

* Danach sollte der Text beim VRS N8 nicht mehr auftauchen

--ToniE (talk) 14:40, 22 October 2018 (UTC)

Einerseits ja, andererseits taucht das auch bei den Flixbus-Linien auf. Die ref 027 gibt es dort zweimal:

* Einerseits:     Essen - München (national)

* Andererseits: Amsterdam - München (international)

--EvanE (talk) 00:14, 23 October 2018 (UTC)

Flixbus 027

* ich glaube nicht, dass wir zwei Route-Master brauchen. Laut Fahrplan fährt der Bus

** Wilhelmshaven - Essen - München

** Amsterdam - Essen - München

** xxx - yyy - München

** Das sind Varianten ein und derselben Linie: ein Route-Master.

** Zugegeben, Amsterdam und Wilhelmshaven liegen weit auseinander, aber bezogen auf die Gesamtentfernung ist das wie ein Regionalbus, der mal im Dorf A und mal im Dorf B abfährt.

* Wenn der Code mal verbessert ist, können die beiden Linien unterschieden werden: nicht am Operator, sondern an From und To.

** From und To zu analysieren, wenn der Operator identisch ist, brauche ich auch für VMS, da hier z.B. die Linie A 5 mal in 5 verschiedenen Gemeinden auftaucht mit 3 unterschiedlichen Betreibern

--ToniE (talk) 07:34, 23 October 2018 (UTC)

Wo findet man eine Übersicht der verschiedenen Flixbus-Linien? Ich bin da weder auf MeinFernbus.de noch auf Flixbus.de fündig geworden. Dann kann ich (und andere) allfällige Änderungen selber rausfinden.

Der Grund der doppelten Nummern-Vergabe dürfte im Zusammenschluss von MeinFernbus mit Flixbus liegen. Nun ja, wenn man das so macht, dass die zwei Linien Zweige einer einzigen Linie sein sollen, so hat man das Problem "elegant" gelöst.

--EvanE (talk) 19:10, 29 October 2018 (UTC)

Die erste Version der Daten stammt von marcoSt, evtl. könntest Du mit ihm Rücksprache halten. Er arbeitet auch recht viel an Flixbus-Linien.

--ToniE (talk) 14:36, 30 October 2018 (UTC)

Route-Master has less Routes than actually match

Bei der Zählung der Routen mit passenden 'ref' könnte man die Routen bei denen 'public_transport:version' auf einen anderen Wert als '2' gesetzt ist (z.B. '1' oder 'not-2') aus der Zählung weglassen, da anders als bei fehlender Angabe klar ist, dass dies keine PTv2-Relation ist und möglicherweise nie wird. Die Fehlermeldung kann für diese Fälle natürlich entfallen. Ein Hinweis in der Spalte Anmerkung wäre dennoch sinnvoll.

Hintergrund sind die vielen PTv1 Relationen, die wahrscheinlich in absehbabrer Zeit nicht umgestellt werden. Ebenso die Krüppel-Dinger von Netzwolf (public_transport:version=not1not2). Oft bleiben die alten Versionen auch erhalten, da es einfacher erscheint, die PTv2 Routen daraus komplett neu und ohne Geschichtsbalast zu erstellen. Manchmal will man auch die Geschichte - so wie sie ist - erhalten, ohne sie durch Umstellung auf PTv2 zu überdecken.
--EvanE (talk) 00:05, 27 November 2018 (UTC)

Das möchte ich nicht machen.

Man muss sich schon entscheiden, ob man eine Route mit Version ungleich '2' oder komplett (und ohne Ausnahmen) auf Version=2 mapped.

Einen Mix gibt es nach meiner Meinung nicht. Wenn da ein Route-Master ist und/oder mindestens eine Route mit PTv2 ist, dann darf es da nichts anderes geben - mittelfristig zumindest. In der Übergangsphase aber schon.

Sorry für die verzögerte Antwort, ich war unterwegs und hatte mich dann auch noch an der Internationalisierung (I18N) des Tools festgebissen und wäre fast verzweifelt.

--ToniE (talk) 09:50, 11 December 2018 (UTC)

Das führt uns direkt zu einem allgemeineren Problem: Was mit den dadurch veralteten Routen machen?

• Löschen lässt gleichzeitig die Geschichte verschwinden.
• Weiterverwenden, erzeugt Relationen mit langer Versionsliste.

Bei den alten Netzwolf Relationen ("Bitte nicht ändern ...") habe ich das dadurch gelöst, dass ich als ref "old-511" / "old-577" verwendet habe, aber das ist nicht für alle Fälle sinnvoll und bläht die Liste der Relationen ziemlich auf.
Insgesamt fällt es mir schwer die Geschichte einer Relation einfach wegzuwerfen.

Deine Probleme mit deutscher / englischer Version habe ich wohl bemerkt. Von daher kein Problem, dass die Antwort länger gedauert hat. --EvanE (talk) 22:05, 16 December 2018 (UTC)

Veraltete Route?

Linien, die es im VRS nicht mehr gibt? Löschen.

Linien, die von altem Mapping auf PTv2 umgestellt werden?

Die alte Relation verwende ich dann als Route-Master und erzeuge für die Route-Relationen neue Relationen. Das hat den Vorteil, dass Links im Wiki auf die alte Relation noch funktionieren. Die Historie des neuen Route-Master ändert sich danach nicht mehr viel.

"Bitte nicht ändern ..."

Netzwolf scheint noch aktiv zu sein. Ob er sich seiner alten Versuche noch bewusst ist?

So weit ich das noch gesehen habe sind seine Versuche 5 Jahre alt - wenn er nicht antwortet würde ich ändern und korrigieren.

--ToniE (talk) 13:32, 17 December 2018 (UTC)

public_transport:version bei route_master?

Hi Toni, ich bin erst vor kurzem über PTNA gestolpert und bin ziemlich begeistert. Danke dafür! Mir ist aufgefallen, dass im Zusammenhang mit der Arbeit mit PTNA der Schlüssel public_transport:version bei route_master-Relationen verwendet wird. Nach meinem Verständnis ist der Schlüssel dafür da um zu unterscheiden nach welchem Schema eine Route erstellt wurde. Demnach macht der Schlüssel nur bei Routen Sinn. Die PTNA-Auswertung motiviert aber den Schlüssel bei Master-Routen zu verwenden. Was meinst du dazu? --Kristjan (talk) 23:35, 6 January 2020 (UTC)

Servus Kristjan, Danke für das feedback. Was public_transport:version bei route_master angeht: da gebe ich dir Recht. Da ist PTNA strenger als PTv2. Bei so manchen anderen Schlüsseln übrigens auch (network, name, ...), die sind als optional oder recommended definiert, werden von PTNA aber erwartet - weil es Sinn macht und weil andere Tools ohne sie nicht vernünftig funktionieren würden. public_transport:version ist bei route_master allerdings noch nicht einmal definiert - PTNA sollte die Prüfung also unterlassen, auch weil es route_master eh nur für PTv2 gibt.

--ToniE (talk) 08:28, 7 January 2020 (UTC)

operator-Chaos im RMV

Heute bin ich auf ein gewaltiges Problem gestoßen:

Im RMV gibt es in Frankfurt und in Bad Homburg Liniennummern, die miteinander kollidieren. Die Linien haben jeweils den selben Betreiber und lassen sich auch nicht durch from und to unterscheiden, weil es in Frankfurt Hin- und Rück-Varianten gibt (in Bad Homburg sind nur Nacht- und Schulbusse betroffen).

Was tun? Eigentlich bräuchte man hier ein Tag "subnetwork"... -- Eiskalt-glasklar (talk) 07:57, 17 May 2020 (UTC)

... das Problem hat mich schon vor Jahren Nerven und Zeit gekostete, sollte aber mittlerweile lösbar sein.

Was ich nicht möchte: OSM Daten so zu manipulieren, damit PTNA damit zurecht kommt.

Das Problem gibt es auch beim DE-SN-VMS mit den Linien A, B, C, ...

Was muss/kann gemacht werden - und auch nur, wenn es die Linie mehrfach gibt?

* 'operator', 'from' und 'to' müssen in der Relation gesetzt sein.

* 'Betreiber', 'Von' und 'Nach' der CSV-Daten sollten die gleichen Werte wie 'operator', ... in der Relation haben (einfachster Fall)

* 'operator' darf Teil von 'Betreiber' sein und umgekehrt und für 'from'/'Von', ... gilt das auch

* 'from'/'Von', 'to'/'Nach' sowie 'from'/'Nach' und 'to'/'Von' werden erst verglichen, wenn 'operator'/'Betreiber' mehrdeutig sind.

* 'Von' und 'Nach' dürfen 'ODER' Angaben haben: 'Von' = 'A-Straße|B-Platz" und 'Nach' = 'C-Center|Bahnhof'

** damit könnte man alle Varianten finden

** ist aber nicht immer notwendig: Es reicht eine Variante zu finden, dann wird der Route-Master einbezogen und alle weiteren Varianten auch

* im RMV-Fall: müsste eigentlich reichen, wenn man eine exotische Variante in 'Von' und 'Nach' angibt

Hast du ein konkretes Beispiel? Das könnten wir für die weitere Diskussion nehmen.

--ToniE (talk) 10:37, 17 May 2020 (UTC)

Ein konkretes Beispiel? Nehmen wir mal den Bus 24 in Frankfurt: 389433 389433 und den Nachtbus 24 in Bad Homburg: 8728289 8728289 (der operator ist in der Relation noch falsch, aber schon richtig auf der PTNA-Seite, sollte beides derselbe operator "Transdev Rhein-Main" sein). Wenn ich es an dem Beispiel verstehe, dann denke ich, bekomme ich es für alle anderen Fälle auch hin. -- Eiskalt-glasklar (talk) 10:42, 17 May 2020 (UTC)

Das Beispiel dürfte recht einfach sein, die 'from' und 'to' sind jeweils eindeutig.

Was ich vergessen hatte: 'from'/'Nach' und 'to'/'Von' werden natürlich auch miteinander verglichen auf Gleichheit bzw. "enthalten in" - Die Rückrichtungen sollen ja auch erfasst werden. Habe ich oben noch eingefügt.

--ToniE (talk) 11:14, 17 May 2020 (UTC)

VRN Overpass-Abfrage

Hallo, wäre es möglich, aus der Overpass-Abfrage für den VRN die Übergangsgebiete herauszunehmen? Die sorgen für jede Menge unnötige Überschneidungen mit benachbarten Verkehrsverbünden. Ausbrechende VRN-Linien werden auch ohne die Übergangsgebiete vollständig erfasst. -- Eiskalt-glasklar (talk) 06:04, 1 July 2020 (UTC)

die Übergangsgebiete sind Ende April erst hinzugefügt worden. "Rainero" hatte mich auf den Bus 549 hingewisen, der nicht im Kerngebiet fährt. --ToniE (talk) 15:36, 1 July 2020 (UTC)

Hm, wenn es wirklich Busse gibt, die das VRN-Gebiet nicht betreten, landen die beim richtigen Tagging eh nicht in der Auswertung. Die müssten dann ein network=KVV bekommen (es werden nur KVV-Fahrkarten verkauft) und fallen damit aus der VRN-Auswertung raus. Das heißt, die betreffenden Linien wären dann wohl eher beim KVV mit auszuwerten - ist aber nur meine Meinung. -- Eiskalt-glasklar (talk) 17:28, 1 July 2020 (UTC)

In der Theorie ja, soweit bin ich mit dir einer Meinung. Beim KVV (deren GTFS-Daten) taucht der 549er aber nicht auf. Ohne die Übergangsgebiete des VRN würde der 549er unter gehen, nirgends erfasst werden. Gemapped ist er mit 'network' = 'Verkehrsverbund Rhein-Neckar'. --ToniE (talk) 19:25, 1 July 2020 (UTC)

Ich hab mit dem Kollegen gesprochen. Er hat gesagt, dass er die Linie 549 deshalb dem VRN zugeschlagen hat, weil sie im GTFS-Feed des VRN vorkommt. Ich hab mal geschaut und die Linie scheint ein Irrläufer zu sein, da andere Linien aus dem Landkreis Germersheim die VRN-Gebiet nicht betreten nicht im GTFS-Feed des VRN auftauchen (stichprobenartig mit PTNA quergeprüft). Er hat versprochen, die Linie 549 als network=VRN;KVV umzutaggen. Mal schauen... -- Eiskalt-glasklar (talk) 18:23, 2 July 2020 (UTC)

Dann sollte es passen, ist aber schon eigenartig. --ToniE (talk) 18:34, 2 July 2020 (UTC)

Linien mit unterschiedlichen refs

Hallo,

das hier: 1907351 1907351 sollte laut Dokumentation funktionieren, tut es aber nicht. Das Problem wird sich zwar in einem Jahr ohnehin von selbst lösen (bei der nächsten Ausschreibung wird die Linie aus Hessen verbannt) aber in der Zwischenzeit wäre ich über eine Lösung froh, weil es nicht nur diese Linie betrifft... -- Eiskalt-glasklar (talk) 05:21, 24 July 2020 (UTC)

in den CSV-Daten muss 'ref' immer genau so stehen wie in der Relation, d.h. der Eintrag müsste lauten:

53/K53;bus;;Aschaffenburg;Babenhausen;Verkehrsgesellschaft Untermain

Die Beschreibung bezieht sich darauf, dass zusätzlich geprüft wird ob hier ref:VAB=53 und ref:RMV=K53 existieren.

--ToniE (talk) 07:01, 24 July 2020 (UTC)

Ist ja blöd. Dann ist es fast noch sinnvoller die Bus-Relation einfach zweimal anzulegen, einmal mit der hessischen und einmal mit der bayerischen Bezeichnung, auch wenn es ein und dieselbe Buslinie ist. grmbl... -- Eiskalt-glasklar (talk) 12:26, 24 July 2020 (UTC)

Ist ja nur eine einzige Buslinie mit zwei Nummern, daher auch nur einmal mappen.

Das andere war von mir falsch formuliert (hab's grad' im Code nachgeschaut): wenn der Wert von 'ref' nicht in 'name' auftaucht und ref:* existieren, dann wird geprüft ob die Werte von ref:* in 'name' auftauchen, und zwar zusammen mit dem '*'. D.h. 'VAB' bzw. 'RMV' --> name='Bus VAB 53/RMV K53: ...' in diesem Fall.

Bei anderen Linien scheint das ja zu funktionieren:

Aber darüber kann man diskutieren, ob hier 'VAB' und 'RMV' in 'name' unbedingt vorhanden sein müssen.

Vorschlag: 'ref' = '53/K53', 'name' = 'Bus 53/K53: ...', 'ref:VAB' = '53', 'ref:RMV' = 'K53', ...

Das fände ich allerdings sinnvoller. Die Aufnahme der Verkehrsverbundsbezeichnungen halte ich in Verkehrsverbünden die regulär Buslinien mit Buchstaben bezeichnen für wenig praktikabel, ich denke da gerade an "Bus VAB 30/RMV AB-30" (das wäre der da 3372140 3372140). Im Übrigen scheint ja der Trend OSM-weit eher dahin zu gehen den Vollnamen des Verkehrsverbundes zu verwenden und keine Abkürzung, auch wegen der bekannten Kollisionen AVV/AVV und VVM/VVM. -- Eiskalt-glasklar (talk) 12:55, 24 July 2020 (UTC)

Bzgl. "Trend": ein Grund mehr, die Prüfung zu entschärfen, d.h. hier nicht 'VAB' und 'RMV' in 'name' zu suchen, sondern nur (exakt) die getaggten 'ref:*'-Werte - werden den Code mal ändern.

OSM-Wiki Seite

Ein Auftritt von PTNA im OSM-Wiki wäre sehr praktisch.

Willst/Kannst Du eine anlegen oder soll ich einfach mal unter Public Transport Network Analysis selber loslegen? --Skyper 00:16, 26 July 2020 (UTC)

Servus skyper, Du kannst gerne anfangen, und, wie in einer PM schon erwähnt, auch eine Weiterleitung von PTNA auf diese neue Seite einfügen. --ToniE (talk) 13:27, 26 July 2020 (UTC)

Salli, habe mal die Seite erstellt. Ein Screenshot oder zwei sind vielleicht noch angebracht. Leider noch ganz puristisch das ganze, aber kein "Stub". --Skyper 17:52, 28 July 2020 (UTC)

Ein Screenshot ist jetzt vorhanden. Habe mich für eine Relations-Analyse entschieden. --Skyper (talk) 18:44, 31 July 2020 (UTC)

Danke, ich werde auch dran arbeiten. Gibt es aus deiner Sicht eine Priorität, was man als Wichtigstes als erste beschreibe sollte? --ToniE (talk) 10:20, 1 August 2020 (UTC)

Wohl als erstes die Netzwerk-Analyse-Seiten, die Beschreibung bekomme ich noch hin, aber bei den ganzen Checks habe ich noch keinen Überblick. In den FAQs wird wohl die erste Frage sein, wie neue Seiten hinzukommen können, sowohl bei der Analyse als auch im GTFS. --Skyper (talk) 13:46, 1 August 2020 (UTC)

Da ich bzgl. PTNA ja ein wenig betriebsblind bin, wäre es sogar hilfreich das mal aus einer anderen Perspektive zu sehen: was ist aus Anwendersicht interessant, wichtig, ... die häufigsten Fragen, ... --ToniE (talk) 13:27, 26 July 2020 (UTC)

Gut, mache mich daran die zwei Hauptbestandteile ein wenig mehr zu beschreiben. Für FAQs gibt es schon die Seite auf PTNA. Kann auch den Inhalt kopieren und eine Unterseite im Wiki anlegen. Vorteil ist, dass dort alle editieren können. --Skyper (talk) 18:44, 31 July 2020 (UTC)

FAQ im OSM Wiki hat den Vorteil, dass jedermann dort eine Frage stellen kann; Fragen, auf die ich nicht kommen würde. --ToniE (talk) 10:20, 1 August 2020 (UTC)

JOSM Unterstützung (GTFS)

Ich habe mal angefangen Objektvorlagen und Validierungsregeln, insbesonder zum Thema GTFS und PTNA, für JOSM zu schreiben. Vielleicht helfen sie nicht nur mir persönlich. Viel Spaß beim Mappen. --Skyper 00:16, 26 July 2020 (UTC)

Danke für die Presets und die Rules, ich bin mal kurz drüber geflogen ...

Bei ref:IFOPT=* und gtfs:stop_id=* ist die RegEx [a-z]{2}:[0-9]{5}:[1-9][0-9]{0,4}:[1-9][0-9]{0,1}:[1-9][0-9]{0,1} leider nur der Idealfall.

Oh, da habe ich die Vorlage vergessen anzupassen: [a-z]{2}:[0-9]{5}:[1-9][0-9]{0,4}:[0-9]{1,2}:[1-9][0-9]{0,1}

Oder soll ich die RegEx doch lieber aus der Vorlage ganz entfernen. --Skyper 15:08, 26 July 2020 (UTC)

Hängt davon ab, ob die anderen Bestandteile in eine RegEx gepresst werden können. -- ToniE (talk) 15:23, 26 July 2020 (UTC)

RegEx geht immer bleibt nur der Kompromiss zwischen Lesbarkeit und nicht zu weit fassen. Haben hier ja keine Mailadressen zu checken. Habe mich für einen zusätzlichen Link auf ref:IFOPT=* und eine allgemeiner RegEx ([a-z]{3}:[0-9]{4,5}:[1-9][0-9]{0,4}:[0-9]{1,2}:([A-Z]+[ ]?)?[1-9][0-9]{0,2}[A-Z]?) in der Vorlage entschieden. --Skyper 11:46, 27 July 2020 (UTC)

Ich habe im Bereich des MVV schon vieles anderes gesehen:

- gen:9184:2315:0:1, was eigentlich identisch mit de:09184:2315:0:1 sein sollte, wenn 's denn mal korrigiert würde. --ToniE (talk) 13:41, 26 July 2020 (UTC)

Da bin ich bisher davon ausgegangen, dass die veraltet Schreibweise nicht mehr in OSM gehört und die Gesellschaften mal ihre Daten aktualisieren sollten. --Skyper 15:08, 26 July 2020 (UTC)

Solange die es noch 'falsch' machen gilt deren 'falsch' für uns als 'richtig', weil faktisch? --ToniE (talk) 15:18, 26 July 2020 (UTC)

- de:09162:970:3:OHR 2 oder de:09162:1179:3:KIF 1 oder de:09162:1182:3:LIN 2. --ToniE (talk) 13:41, 26 July 2020 (UTC)

Also [a-z]{2}:[0-9]{5}:[1-9][0-9]{0,4}:[0-9]{1,2}:([A-Z]+[ ])?[1-9][0-9]{0,1} ?

Oder doch noch weiter fassen? Ist immer eine Zahl am Ende, die ich mit local_ref=* vergleichen kann? --Skyper 15:08, 26 July 2020 (UTC)

local_ref=* kann aber auch 'A', 'B' oder sonst was sein, dementsprechend auch der letzte Teil von ref:IFOPT?

- gen:9188:5599:0:956H, gen:9188:5599:0:956R, de:09179:6190:1:1A, de:09179:6190:1:1B, de:09179:6190:1:1C, de:09179:6190:1:1D

--ToniE (talk) 15:18, 26 July 2020 (UTC)

Danke, dann mache ich mich mal ans verbessern. --Skyper 15:44, 26 July 2020 (UTC)

Sollte jetzt passen (diff). --Skyper 11:46, 27 July 2020 (UTC)

Sorry, ich war nicht präzise genug: es kann alles mögliche kommen, z.B. auch sowas wie die 6 Beispiele mit *:956H, *:956R, ...

Eine RegEx läßt sich u.U. nicht erstellen/herleiten/allgemeingültig aufstellen --ToniE (talk) 10:16, 1 August 2020 (UTC)

Wir reden aber nur über den letzten Block oder? --Skyper (talk) 13:46, 1 August 2020 (UTC)

Fehlende Verkehrsverbünde

Meine persönliche Wunschliste für noch fehlende Verkehrsverbünde:

• RNN (DE-RP-RNN): LK Mainz-Bingen, LK Alzey-Worms, LK Bad Kreuznach, LK Birkenfeld (3158895 3158895)
• Kim (DE-BY-Kim): LK Bad Kissingen (11033790 11033790)

Ist das vorstellbar, dass die Verkehrsverbünde noch mit in die Auswertung kommen, oder ist das technisch nicht machbar/Serverlast zu hoch? -- Eiskalt-glasklar (talk) 04:22, 24 November 2020 (UTC)

kein Problem, ich denke, ich bekomme das im Laufe des Tages noch hin --ToniE (talk) 07:47, 24 November 2020 (UTC)

Bei mir in der Gegend fehlt noch der

• VGC - Verkehrsgesellschaft Bäderkreis Calw mbH DE-BW-VGC (https://www.vgc-online.de/) , er umfasst im Wesentlichen den LK Calw (62601 62601) Fx99 (talk) 06:40, 22 August 2023 (UTC)

mach' ich dann mal im Laufe der Woche. War'ne Weile nicht in der Nähe meines PCs.

Danke, habe DE-BW-VGC-Routes ergänzt. Es gibt noch viel zu tun! --Fx99 (talk) 16:43, 3 September 2023 (UTC)

Importing Croatian ZET public transport operator to PTNA

We have started to conflate our public transport in Zagreb with GTFS data[1], and would like to be a part of PTNA.

We have tram and bus routes, and have started to convert them to PT v2 scheme, and we are around 80% done (100% of trams). A reference tram line is here [2], and a reference bus line is here [3]. We use the tag network=ZET. The only tag we import from gtfs is gtfs:stop_id=*, and we are in the proces of importing all of them into OSM. Our public transport provider has a pretty bad gtfs file, stop pairs on either side of the road have the same gtfs id, but no route should have two stops with the same id.

If you need any information, feel free to contact me. We can change our tagging scheme if you find any problems, and we could import data from the gtfs file if there is any data there that would be nice to have in OSM. --Janko (talk) 16:59, 18 January 2021 (UTC)

Sure, I can include both the analysis of OSM data and the GTFS into PTNA

* for PTNA I will use the area of Grad Zagreb for the search

* for GTFS and PTNA I will use HR-21-ZET as the identitier, where HR-21 ist the ISO3166-2 code of that region (wikidata:Q1435) and ZET the 'network'

* the list of routes provided by ZET can be retrieved from GTFS as CSV data, undergo a bit of beautifying and layout adatption and the be stored in the OSM-Wiki - but where?

** suggestion: https://wiki.openstreetmap.org/wiki/Croatia/Javni_prijevoz/Zagreb/ZET_Linije

* tagging also gtfs:feed=HR-21-ZET, gtfs:release_date=2021-01-15, gtfs:route_id and (on route-relations) gtfs:trip_id:sample will help PTNA to provide/print links in the analysis to the corresponding GTFS analysis

* on the roadmap of PTNA is the comparison between GTFS data and OSM data using those gtfs:* tags to identify the corresponding GTFS data of a route relation.

--ToniE (talk) 17:40, 18 January 2021 (UTC)

* Only the area of Grad Zagreb misses a lot of routes that start and end in Zagrebačka županija [4] (wikidata:Q27038). Is it possible to extend the search to that county?

I will extend that. Each relation will be found which has at least one member (node, way) in the search area.

* Will the gtfs:feed tag change then, because it's not only the Grad Zagreb region?

No, the gtfs:feed specifies the publisher of the GTFS data, which is ZET (I guess), isn't it?

* I saw the csv of the Beograd public transport, I'll try to add something like that. https://wiki.openstreetmap.org/wiki/Croatia/Javni_prijevoz/Zagreb/ZET_Linije sounds fine.

Great, I'll prepare the configuration, such that this location will be used during the nightly analysis run.

* gtfs:route_id will be the same as ref, I agree with gtfs:release_date and gtfs:trip_id:sample

Usually, the "route_short_name" of GTFS is mapped to 'ref' in OSM. But in your case (I saw the GTFS routes.txt file) that might be the same value. We have route_id="19-210-s20-1" and route_short_name="210" for bus "210" for example.

I'll start a thread in our mailing list to add these tags, thanks for your help!

You're welcome. GTFS analysis will come tomorrow afternoon, probably.

BTW: the link to the GTFS data is specific for a release_date. Is there a 'permalink' which can be used at any time to get the latest version?

Unterschiedliche Schreibweisen von Liniennummern

Wie sollte damit umgegangen werden, wenn Liniennummern unterschiedlich geschrieben sind? z.B. erwartet die Hamburger Auswertung eine RB37, während die Niedersächsische eine RB 37 erwartet. --UncleOwen (talk) 11:41, 17 February 2021 (UTC)

Man kann die "Erwartungshaltung" im OSM-Wiki ändern: z.B. hier für HVV, hier für VBN und hier in der Auswertung für den Bahnverkehr in Deutschland

Die dortigen Listen kann man z.B. auch beim jährlichen Fahrplanwechsel anpassen, wenn Linien hinzukommen oder eingestellt wurden.

Die Listen sind für die lokalen Mapper vorgesehen, daher im OSM-Wiki hinterlegt, wo sie jeder (Account-Inhaber) anpassen kann.

--ToniE (talk) 11:53, 17 February 2021 (UTC)

VRG

Hallo,

wäre es möglich, eine Auswertung für den Verkehrsverbund Rhön-Grabfeld, für den gleichnamigen Landkreis in Bayern einzurichten? -- Eiskalt-glasklar (talk) 09:59, 16 August 2021 (UTC)

in Arbeit, ... --ToniE (talk) 10:42, 16 August 2021 (UTC)

sollte sichtbar sein --ToniE (talk) 11:02, 16 August 2021 (UTC)

AVV

Hallo ToniE ich bin vor kurzem auf das tool ptna gestoßen und fand es super spannend, da ich mich viel mit dem ÖPNV-mapping im Bereich des Aachener Verkehrsverbundes beschäftige. Was ich noch nicht verstehehe: Auf der Seite https://ptna.openstreetmap.de/results/DE/NW/DE-NW-AVV-Analysis.html steht, "Diese Auswertung enthält derzeit eine Bestandsaufnahme der in OSM gefundenen AVV-Linien.". Warum werden die Daten hier nicht mit den vorhandenen GTFS-Daten abgeglichen, wie bei anderen Verbünden? Fehlt da noch was? Kann ich da vielleicht irgendwo mithelfen?--Trockennasenaffe (talk) 13:15, 20 April 2023 (UTC)

Was ich schon mal herausgefunden habe: Der Abgleich erfolgt offenbar nicht automatisch, sondern man muss die Konfigurationsseite Manuell mit den Linien füllen?--Trockennasenaffe (talk) 13:42, 20 April 2023 (UTC)

Ja, auf der Wikiseite mit den Linien muss man das manuell einfügen. Die Informationen kann man per copy&paste aus einer Textdatei holen, die man sich aus den GTFS-Daten per "Download als CSV-Liste für PTNA" (der grüne Button) erstellen lassen kann. --ToniE (talk) 15:21, 20 April 2023 (UTC)

Danke für deine Erklärung, das reicht schon, damit ich aktiv werden kann :)--Trockennasenaffe (talk) 16:09, 20 April 2023 (UTC)

Kurze Rückfrage: Wie gehen wir eigentlich mit gemappten Linienverkehr von privaten Anbietern um wie Museumsbahnen, touristischer Verkehr usw. der nicht Teil des Verbundtarifs ist? Gibt es da eine best-praktice-Lösung in anderen Verbünden? Im AVV ist das gerade totaler Mischmasch und reine Willkür.--Trockennasenaffe (talk) 14:50, 21 April 2023 (UTC)

Für den DE-BY-MVV machen wir das so, dass wir deren 'network'-Werte bei der Analyse auch berücksichtigen (das müsste ich in anpassen). In den CSV-Daten kann man dann eigene Abschnitte einbauen.

Wenn in den privaten Bussen neben deren eigenen Tickets auch AVV-Tickets anerkannt werden, dann sollte deren 'network' auch 'AVV' (oder so) enthalten: z.B. network='xxx;AVV' --ToniE (talk) 16:54, 21 April 2023 (UTC)

Danke. Was ich noch nicht so ganz verstehe: Woher kommt die Verknüpfung mit den GTFS-Daten falls vorhanden? Es gibt ja offenbar die Möglichkeit, die PTNA-Daten an die Relationen zu taggen, als auch auf die Linien-Seite wie du exemplarisch gemacht hast. Braucht man beides oder nur eins von beiden? Wozu braucht man überhaupt die ganzen Daten zwischen den Semikolons, die Relation wird ja auch offenbar ohne gefunden. Irgendwie habe ich das Gefühl, ich verstehe immer noch nur die Hälfte.--Trockennasenaffe (talk) 17:14, 21 April 2023 (UTC)

Die GTFS-Angaben in der CSV-Liste soll einfach einen Link in die Auswertung auf die zu der Linie gehörenden GTFS-Daten erzeugen, damit man sich schneller orientieren kann.

Die GTFS-Daten in den Relationen ermölichen das selbe (GTFS-Link) an einer anderen Stelle in der Auswertung.

Wenn mir ein geeignert Mechanismus einfällt die GTFS-Angaben (aus CSV oder alternativ aus Relation) in PTNA zu verwenden um weitere Qualitätssicherung zu machen, will ich damit mal anfangen. Die Qualität der GTFS-Daten ist jedoch nicht immer so gut. Falsche Fehlermeldungen (wegen fehlerhafter GTFS-Daten) sind dann nicht zu vermeiden - sollten aber niemals kommen, um die Mapper nicht zu frustrieren.

Die Daten zwischen den Semikola werden in der Regel nicht weiter verwendet sondern nur ausgegeben - als Orientierung. Beim DE-SN-VMS (und anderen) sind sie jedoch z.T. unabdingbar um z.B. die Vielzahl von Buslinie "A" (11 mal?) in verschiedenen Gemeinden, z.T. sogar mit identischem Operator in PTNA zu unterscheiden. Da braucht's den Abgleich zwischen 'from', 'to' und 'operator' bei den Relationen mit den CSV-Daten. --ToniE (talk) 18:27, 21 April 2023 (UTC)

Ich bin gerade dabei, die GTFS-Daten zu den einzelnen Linien hinzuzufügen. Was ich mich mittlerweile frage ist, wie stabil die verwendeten IDs sind. Wenn die sich mit jeder neuen Version ändern, kann ich die Arbeit wohl neu beginnen bevor ich damit fertig bin .--Trockennasenaffe (talk) 06:03, 25 April 2023 (UTC)

Ich hab mal selber rein geschaut. Offenbar scheint sich zumindest die Shape-ID mit jeder Version zu verändern. Damit ist sehr fraglich, ob sich der ganze Aufwand lohnt. Ich würde wohl viele Wochen brauchen um alle Linien abzuarbeiten und bis dahin wären die IDs nicht mehr aktuell.--Trockennasenaffe (talk) 06:37, 25 April 2023 (UTC)

Hmm, ja beim Bus 10 (Stichprobe mit kleiner Menge) scheint das so zu sein, aber: die Trip-ID bleibt dort konstant. Wie ich auch user 'skyper' sagte: shape_id ist nicht so wichtig (bzgl. Qualitätssicherung) wie die trip_id. Bei manchen Verbünden gibt es die shapes noch nicht einmal. Rein programmtechnisch ist die trip_id besser, da man darüber leichter auf die Stops kommt + die shapes, wenn vorhanden.

Ob und wann, wie oft sich die route_id, trip_id, shape_id, stop_id ändert kann ich nicht sagen, das macht wohl jeder Verbund anders.

* PTNA aktualisiert die GTFS-Daten nur ein mal im Monat.

* DE-BY-MVV aktualisiert nur alle paar Monate

* DE-BY-MVG quasi täglich

* Viele Daten stammen von Software von Mentz DV, dem Dienstleister von MVV und vielen anderen.

** z.B. als trip_id "105.T0.20-200-X-s23-2.2.H"

*** 105 ist die Fahrtnummer (gem. Abfahrtzeit)

*** T0 ist die Serviceklasse - z.B. an welchen Tagen der Woche fährt der Bus

*** 20 ist die Fahrzeugklasse ?

*** 200-X ist die Busnummer X200

*** s23 ist die Saison 2023

*** 2 ist die Version - die Daten enthalten oftmals auch noch die Version 1, 3, ..., auch noch nicht gültige oder nicht mehr gültige Zeiträume, zum Teil Teilräume: '1' gilt das ganze Jahr, '2' ist eine Baustellenvariante mit kurzer Dauer innerhalb des Zeitraums von '1'

*** 2.H ist die 2. Variante der Hinfahrt

*** Die Daten (Versionen) sind z.T. recht langlebig

* Wir mappen Baustellenvarianten beim DE-BY-MVV/MVG nicht, konzentrieren uns also auf die route_ids/trip_ids mit langem Gültigkeitszeitraum, z.B. die erste von 4 Varianten des 236er, daher ändern sich die Daten nicht so häufig.

* Das geht beim AVV scheinbar nicht, hier gibt es für jede Busnummer genau eine Zeile in der Tabelle

Man könnte in die CSV-Daten noch ein Release-Datum anhängen z.B. "2023-04-06" und in die Relationen noch gtfs:release_date=2023-04-06.

Man könnte in die CSV-Daten und als gtfs:release_date auch noch den Verweis auf Langzeitdaten "long-term" setzen und mir sagen, welches Datum dahinter stecken soll (eine Idee von skyper, wird nicht oft genutzt).

Aus beiden Ansätzen ergeben sich andere Probleme: wie erkennt man (in PTNA), dass es die route_id/trip_id im aktuellsten Datensatz nicht mehr gibt, wenn man sich immer auf die Version von Mitte Dezember bezieht.

--ToniE (talk) 08:57, 25 April 2023 (UTC)

Ich habe mal geschaut. Leider bleibt die Trip-Id auch nicht konstant. Konkretes Beispiel: DE-NW-AVV - 2022-09-18 Linie "N1", Trip-Id = "251837510", DE-NW-AVV - 2023-04-06 Linie "N1", Trip-Id = "294153650" und das obwohl sich nichts in den Daten geändert hat.--Trockennasenaffe (talk) 13:38, 25 April 2023 (UTC)

:-( Soviel zum Thema (völlig) offene Daten ... mit denen man nicht viel anfangen kann. Denn: GTFS-Daten müssen konsistent sein, aber nur innerhalb des selben ZIP-files. --ToniE (talk) 14:01, 25 April 2023 (UTC)

Wie steht's mit der Langlebigkeit von route_id aus? --ToniE (talk) 14:03, 25 April 2023 (UTC)

Es scheint so zu sein, dass die route_id konstant bleibt. Zumindest habe ich bisher kein Gegenbeispiel gefunden. Die Daten stammen beim AVV von einer Software von HaCon. Der GTFS-Export oder zumindest der upload wird wohl manuell angestoßen, wenn es Änderungen gibt. trip_id haben wohl keine semantische Bedeutung und werden nur irgendwie durchnummeriert. Prinzipiell stehe ich da in gutem Kontakt zum AVV, allerdings ist es so, dass da nur wohl nur eine Person für die Fahrplandaten zuständig ist und klar gestellt hat, dass es für OpenData Support nur in minimalem Umfang gib, allerdings ist man andererseits immer sehr dankbar, wenn ich Fehler in den Fahrplandaten melde.

Das der AVV pro Buslinie eine Zeile hat liegt wohl daran, dass das hiesige Busunternehmen keine Baustellenvarianten einpflegt und nur lange Baustellen den weg in die Online-Fahrplanauskunft finden. Alles andere wird nur mit Hinweistexten abgehandelt. Mit der einen Zeile stimmt auch nicht ganz: Manchmal gibt es eine Zeile für die Normalen Linienfahrten und eine für die Anruflinientaxis. Die unterscheiden sich durch ein angehängtes "alt" an die Liniennummer.--Trockennasenaffe (talk) 15:08, 25 April 2023 (UTC)

Hmm, dann würde ich die trip_id/shape_id in den Relationen nicht verwenden. Macht mehr Arbeit die zu pflegen als dass es hilft - derzeit macht PTNA damit noch keine QA, gibt lediglich Links aus.

Ob die route_id in den CSV-Daten und den Relationen dauerhaft brauchbar ist, weil sie sich nicht oder nur sehr selten ändert, bleibt abzuwarten. Letzendlich könnte ich mir auch eine QA seitens PTNA vorstellen, die trip_id und shape_id nicht nutzen wird sondern lediglich auf die route_id setzt. --ToniE (talk) 10:32, 26 April 2023 (UTC)

Mhh, die trip_id/shape_id in den Relationen fungieren für mich eher als Quellenangabe (obwohl ich auch meist source=* mit direkten Link verwende) und erzeugen als Nebeneffekt einen schöneren Link in der Auswertung.

Die route_id in den CSV-Daten dienen mir auch eher als Verweis, wobei bei monatlich neuen route_id ich meist das Datum von release_date von longterm verwende um nicht jeden Monat Aktualisieren zu müssen. --Skyper (talk) 22:39, 27 April 2023 (UTC)

Hallo ToniE ich habe das Thema jetzt zwei Jahre ruhen lassen, da ich damals mit den GTFS-Daten, die keine stabilen IDs hatten nicht weiter gekommen bin. Hab gesehen bei ptna hat sich in der Zwischenzeit wohl einiges getan. Meinst du es lohnt sich, sich das noch mal anzuschauen, oder werde ich da wieder das Problem haben, dass die Daten vom AVV einfach untauglich sind?--Trockennasenaffe (talk) 14:00, 12 May 2025 (UTC)

Sieht so aus, als ob die "route_ids" konstant bleiben: Du kannst hier den Vergleich zweier GTFS-feed Versionen anstoßen. Es sieht so aus, als ob "route_short_name" (auch nach Klick auf "Show all") nicht mehrfach vorkommen. Bei Stichprobe auf Bus 10 (2025-05-02 vs 2024-04-02) und Bus 66 (2025-05-02 vs 2024-04-02) habe ich auch die selben "trip_ids" gesehen. "shape_ids" scheinen mir wenig interessant zu sein, die Haltestellen (stops) sind darin ja nicht enthalten. Für einen Vergleich GTFS vs OSM sind die Haltestellen (Position, Name, ref:IFOPT, ...) entscheidender als der befahrene Weg. --ToniE (talk) 14:57, 12 May 2025 (UTC)

Wenn ich das richtig sehe, gibt es da nur zwei Versionen, die ca einen Monat auseinander liegen. Ich glaube nicht, dass es sehr aussagekräftig ist, diese zu vergleichen. Warum gibt es da keine älteren?

Die Festplatte auf dem FOSSGIS-Server ist recht voll, wir hatten auch schon mehrfach 100% belegt. Daher speichere ich nur die vorangegangene und aktuelle Version. Außerdem, um nicht all zu oft neue Versionen (mir wechselnden IDs) zu speichern, wird nur jeweils die erste Version eines Monats gespeichert. --ToniE (talk) 22:48, 12 May 2025 (UTC)

Was ich mich auch noch frage: Ich habe in Aachen viele IFOPTs an die Haltestellen getaggt. Wäre es da vielleicht vorteilhaft auf einen GTFS-Feed mit IFOPTS als stop ids vorteilhaft? Den gibt es nämlich auch.--Trockennasenaffe (talk) 17:25, 12 May 2025 (UTC)

Wo gibt es den? Den würde ich dann natürlich nehmen. --ToniE (talk) 22:48, 12 May 2025 (UTC)

Die verschiedenen GTFS-Datensätze von AVV liegen alle parallel unter https://opendata.avv.de/current_GTFS/ Dateien die "Global-ID" im Titel haben enthalten die IFOPTs. Da gibt es also AVV_GTFS_Masten_mit_SPNV_Global-ID.zip und AVV_GTFS_Masten_ohne_SPNV_GlobaleID_oFremd.zip. Zu beachten ist wohl noch, dass diese Daten im Gegensatz zu den "normalen" mastscharf sind, ich weiß nicht, ob das ggf. Probleme machen könnte. Was mir auch noch aufgefallen ist: Die route_ids, die ich damals an die Relationen getaggt habe, sind wohl größtenteils noch da und funktionieren auch noch. Ich dachte die wären damals auch gelöscht worden, aber das betraf wohl nur die anderen IDs. Vielleicht ist das doch alles nicht so schlimm, wie ich es in Erinnerung habe.--Trockennasenaffe (talk) 05:30, 13 May 2025 (UTC)

Danke ich habe nun als Quelle: AVV_GTFS_Masten_mit_SPNV_Global-ID.zip genommen. Hier scheinen zum überwiegenden Teil die GTFS 'stop_id' dem OSM ref:IFOPT=* zu entsprechen. Was mit noch aufgefallen ist: für viele Stops ist auch der GTFS 'platform_code' vorhanden (Beispiel: Bus 10, erster Trip), dieser entspricht dem OSM local_ref=* an der Haltestelle. --ToniE (talk) 09:05, 13 May 2025 (UTC)

Vielen Dank! Ja die platform_code sind sehr hilfreich bei der zuordung der Masten, da die Koordinaten generell eher ungenau und oft auch grob falsch sind. Leider gibt es die nur für die Städteregion Aachen und nicht für den gesamten AVV.--Trockennasenaffe (talk) 10:30, 13 May 2025 (UTC)

DE-SPNV

Beim Aachener Verkehrsverbund wurde offenbar die GTFS-Daten ohne SPNV genommen. Ich nehme an, für den SPNV muss ich daher die Quelle DE-SPNV nutzen? Wenn ich davon die CSV-Datei runter lade, steht in der zweiten Spalte immer "bus". Müsste das nicht "train" sein?--Trockennasenaffe (talk) 15:23, 22 April 2023 (UTC)

Ja, für AVV habe ich die SPNV weg gelassen, DE-SPNV gibt es ja parallel.

Das mit 'bus' ist ein Fehler, sollte 'train' sein. Die Abbildung aus GTFS ist nicht komplett. Für "route_type" in routes.txt gibt es mittlerweile mehr Werte. Mein JavaScript fällt bei unbekanten route_type-Werten auf 'bus' (OSM) zurück. Im PHP (Webseite) habe ich das angepasst, hier bei JS wohl vergessen. Danke für den Hinweis, werde ich korrigieren.

--ToniE (talk) 18:52, 22 April 2023 (UTC)

DE-VPE

Beim Verkehrsverbund VPE fehlen in DE-BW-VPE zumindest die Stadtbuslinien in Pforzheim (Linie 1 bis 10, sowie 41-43).

Kann das daran liegen, dass es einen Landkreis PF (Enzkreis) und einen "Stadtkreis" PF (Stadt Pforzheim) gibt? --Fx99 (talk) 15:47, 28 September 2023 (UTC)

Hmm, und sorry: die GTFS-Daten stammen vom NVBW, einer offiziellen Stelle in BW. Der NVBW sammelt die Daten aus verschiedenen Quellen ein. Mehr weiß ich auch nicht.

Sorry, anscheinend bin ich vom Wiki nicht informiert worden, obwohl ich die Seite beobachte. --ToniE (talk) 16:09, 3 November 2023 (UTC)

Hallo, die Verkehre in Pforzheim Stadt und Enzkreis werden von überregionalen Verkehrsunternehmen wie RVS (Südwestbus) und S-Bahnlinien vom KVV gefahren. Deshalb sind im GTFS-Datensatz von VPE keine Linienverkehre enthalten.

viele Grüße Dietmar Seifert, NVBW

Danke Dietmar. Siehr so aus, als ob die Pforzheimer Busse (zumindest der 10er, den habe ich kurz gesucht) im GTFS-Datensatz von DE-BW-RVS enthalten sind. --ToniE (talk) 18:14, 4 November 2023 (UTC)

MaxHeight einer Route prüfen

Wenn PTNA schon Einbahnstraßen und viele Varianten von Barriers prüft, könnte man doch auch die maxheight Werte einer Route prüfen, sonst passiert sowas. Problem ist ja, daß für eine Route ggf. unterschiedliche Fahrzeuge eingesetzt werden: morgens zur Schülerbeförderung große Busse, nachmittas / abends / an schulfreien Tagen aber Kleinbusse. Man könnte eine Route mit 'required_minheight' oder sowas taggen und damit die Route optional auf maxheight prüfen. Wenn man nach steckengebliebenen Bussen googelt findet man auch Fälle wo eine Prüfung auf maxwidth sinnvoll sein könnte; finde ich aber nicht so dringend. --Wyk (talk) 09:43, 4 December 2024 (UTC)

Das wäre(n) in der Tat gute zusätzliche Prüfungen, die mit 'maxweight=3.8' und'maxweight:psv=none' noch Varianten mit sich bringen würden.

Ich habe mal einen 'issue' in GitHub aufgemacht. --ToniE (talk) 10:49, 4 December 2024 (UTC)

Normalized-name

Bei der GTFS-Analyse eines Trips in der Haltestellen-Tabelle sind manche Haltestellennamen grün hinterlegt; oder in HTML-Sprech: die Spalte Name hat zusätzlich zum class Attribut 'gtfs-stop-name' das class Attribut 'normalized-name'. Was soll uns das sagen? --Wyk (talk) 06:14, 5 December 2024 (UTC)

Die Verkehrsverbünde sind ziemlich einfaltsreiche, wenn es um Abkürzungen von Haltestellenamen geht: z.B. "W.-Heisenb.-W." wird von PTNA beim Import von GTFS-Daten 'normalisiert' zu "Werner-Heisenberg-Weg". : Bei den grün hinterlegten Flächen (oder (i)-Icon) gibt's bei 'mouse-over' den GTFS-stop_name zu sehen. --ToniE (talk) 07:51, 5 December 2024 (UTC)

Ah, Ja! Prima Idee, elegante Lösung, gefällt mir! --Wyk (talk) 10:09, 5 December 2024 (UTC)

Dark Mode

Ach, und wo wie schon bei Farben sind: OSM hatte ja am 14. November den DarkMode aktiviert. Gibt es bei PTNA bald auch einen Dark Mode? Ich benutze ja das DarkReader Plugin bei Firefox, damit kann ich das selbst regeln. Aber nur mal so gefragt... --Wyk (talk) 06:14, 5 December 2024 (UTC)

Muss ich mich mal schlau machen, wie man das machen könnte. Wenn's dazu "cookies" braucht, dann wohl eher nicht. Per reinem 'css', dann wäre das machbar. --ToniE (talk) 07:51, 5 December 2024 (UTC)

geht mit StyleSheet und MediaQuery (@media (prefers-color-scheme: dark) {...}). Aber du hast den Analysefile so wunderschön detailliert mit class-Attributen gespickt daß das sehr viel Aufwand ist für jedes Detail eine DarkMode Einstellung festzulegen. Und vor allem darf man nicht vergessen bei jeder Änderung / Erweiterung an zwei Stellen zu ändern. Also erstmal hintan stellen! --Wyk (talk) 10:09, 5 December 2024 (UTC)

Verbesserungsvorschläge

Hallo ToniE,

ich bin ein großer Fan von deinem Tool. Es ist super und hat offensichtlich in gerade auch in letzter Zeit noch viele tolle Funktionen dazu bekommen. Ich beschäftige mich seit wenigen Tagen wieder näher damit und habe schon einiges damit verbessern können. Da hat sich mehr und mehr herauskristallisiert, das ein paar Funktionen noch hilfreich wären, falls du noch Anregungen suchst:

1. Für unsere Region wäre es super, wenn sich beim vergleich GTFS/OSM auch noch der platform_code mit dem local_ref vergleichen ließe. Beide werden angezeigt, aber offenbar gibt es nicht die Möglichkeit, beide zu vergleichen? Das wäre hilfreich um seltene, aber ansonsten schwer zu findende Fehler zu finden, bei denen die Daten innerhalb einer Haltestelle "verdreht" sind.

Das ist geplant, ich habe noch nicht die Zeit gefunden, das zu implementieren. --ToniE (talk) 16:55, 14 May 2025 (UTC)

Das funktioniert schon mal, aber führt dazu, dass bei mir alles als Fehler gewertet wird ("H.1" vs "H1"). So genau habe ich da leider vorher gar nicht drauf geschaut. Ich schwanke noch etwas, ob man den Vergleich etwas großzügiger machen sollte, oder ob wir da tatsächlich falsch liegen und uns dem GTFS anpassen sollte. Ich schaue noch mal, wie das tatsächlich an der Haltestelle steht.--Trockennasenaffe (talk) 13:09, 2 June 2025 (UTC)

Ich sehe allerdings auch immer wieder, dass GTFS-Daten falsch sind. Warten wir's mal ab. --ToniE (talk) 17:11, 2 June 2025 (UTC)

1. Ich finde die Prozent-Metrik die noch farblich hervorgehoben wird, super hilfreich. Ich frage mich ob man nicht vielleicht in der Ergebnis Übersicht auf der Wiki-Seite noch an jede Relation jeweils der Wert des besten "Matches" (Niedrigster Prozentwert) dran schreiben könnte, damit man direkt sieht, wo es sich vielleicht lohnt, noch mal genauer hinzuschauen, ohne in alle Relationsauswertungen rein schauen zu müssen.

Ist ebenfalls geplant. Hier gibt es zwei Quellen von GTFS-Infos die ich berücksichtigen kann

* die GTFS_Angaben in der CSV-Liste im Wiki. Diese enthält "nur" die "route_id", so dass ich alle OSM routes des OSM route_master mit allen GTFS trips der GTFS route vergleichen muss - das kann aufwändig werden (zeitlich, CPU-Zeit)

* die gtfs:trip_id* Angaben in den OSM route relationen. Hier kann ich jeweils einen 1:1 Vergleich mit dem GTFS trip machen --ToniE (talk) 16:55, 14 May 2025 (UTC)

Ich persönlich fände die erste Variante deutlich besser. Das taggen der gtfs:trip_id an die Relationen hat sich zumindest bei uns als sehr aufwändig, fehleranfällig und wenig stabil herausgestellt, so dass ich sehr froh wäre, wenn man darauf nicht angewiesen wäre.--Trockennasenaffe (talk) 06:51, 15 May 2025 (UTC)

1. Zumindest im AVV stimmen die GTFS trips in der Regel nicht 1:1 mit den OSM routes überein. Das ist nicht unbedingt ein Fehler, da es wahrscheinlich nicht sinnvoll ist, alle Varianten zu mappen. Oft ist es glücklicherweise so, dass es pro Richtung eine "Hauptvariante" gibt von der alle anderen nur Teilabschnitte sind. Es gibt aber auch Linien, bei der es diverse, Varianten gibt, die keine Teilmenge der anderen sind und die von der Bedienhäufigkeit mehr oder weniger gleichberechtigt nebeneinander stehen. In solchen Fällen sollte meines Erachtens der Mindeststandard beim mappen sein, das jeder Fahrweg irgendwo vorhanden ist, damit zumindest Netzkarten stimmen. Es wäre also super, wenn das Tool die Weg-Segmente liefern könnte, die in den GTFS trips aber nicht in den OSM routes enthalten sind um am besten noch, wie häufig die befahren werden. Weg-Segmente, die in den OSM routes enthalten sind aber in keinem GTFS trip sind natürlich auch Fehler. Ich denke allerdings, das dürfte ein recht kompliziertes Feature sein.

Das wird sehr komplex und (CPU-)Zeit-intensiv: prüfe für jedes GTFS stop Paar jeden GTFS trips of diese Kombination irgendwo in einer OSM route relation vorkommt. --ToniE (talk) 16:55, 14 May 2025 (UTC)

Viele Grüßen und Danke für deine Arbeit

Gerne --ToniE (talk) 16:55, 14 May 2025 (UTC)

--Trockennasenaffe (talk) 06:34, 14 May 2025 (UTC)

Ansonsten haben sich noch weitere Dinge herausgestellt: Ich fände es sehr hilfreich, wenn man auch zwei GTFS trips "nebeneinander legen" könnte, sowohl auf der Karte als auch von den Haltestellen. Manchmal ist bei mehreren trips Start und Ziel, sowie die Anzahl der Halte identisch und man würde gerne einfach und schnell sehen können, was überhaupt der Unterschied ist.

Da ließe sich was machen, denn ein Vergleich zwischen GTFS und GTFS ist derzeit schon möglich, wenn auch nicht so komfortabel wie du es skizzierst.

Auf GTFS für Deutschland siehst du in der letzten Spalte als letzten Icon den Link zu einem GTFS/GTFS-Vergleich: DE-NW-AVV über den man sich weiterhangeln kann.

Für die komfortable Lösung müsste ich allerdings auf (z.B.) Vergleich GTFS route vs OSM route_master vorne zwei weitere Spalten einfügen, wo man (mit Radio-Button) auswählen kann, welcher GTFS trip mit welchem anderen GTFS trip verglichen werden soll. --ToniE (talk) 07:51, 22 May 2025 (UTC)

So, nun habe ich doch noch eine Lösung implementiert. Zwar ohne runde Radio-Buttons, aber mit den vorhandenen quadratischen Check-Boxen in der ersten Spalte. Wenn man exakt zwei der Check-Boxen auswählt wird oben drüber im Tabellenkopf ein Button aktiviert, der zum Vergleich zweier GTFS tips führt. Das sieht genau so aus wie GTFS trip vs OSM route.

Ich werde das morgen (2025-05-25) mal freigeben, vorher noch ein wenig testen. --ToniE (talk) 11:33, 24 May 2025 (UTC)

Danke, das ist sehr hilfreich soweit ich das bisher gesehen habe. Werde das in den nächsten Tagen mal näher ausprobieren.--Trockennasenaffe (talk) 07:40, 26 May 2025 (UTC)

Was auch nett wäre ist, wenn der Vergleich GTFS trips/OSM-Routen Verschiebungen beim Linienweg erkennen könnte, z.B. ob nur ein stop fehlt oder zu viel ist. Das ist im AVV tatsächlich relativ häufig, da manchmal in AVV-Datensatz Haltestellen doppelt vorhanden sind. In dem Fall geht die Score direkt in den Keller, obwohl höchstens ein Stop fehlt.--Trockennasenaffe (talk) 06:51, 15 May 2025 (UTC)

Einige Analysen sind heute schon drin: z.B. GTFS trip 4 ist Teilroute von GTFS trip 2, was am Icon mit dem 'S' erkennbar ist. Siehe hierzu auch die Liste der Icons auf Seite 15 von PTNA: FOSSGIS 2025 Beitrag.

Weitere Analysen? Ich denke mal drüber nach. Eine Verschiebung am Anfang verursacht derzeit einen deutlich höheren Score als eine fehlende Haltestelle am Ende, so recht zufrieden bin ich damit auch noch nicht. --ToniE (talk) 07:51, 22 May 2025 (UTC)

Danke schon mal für alles, das hat mir sehr weiter geholfen. Ich hab noch eine Idee: Ich tagge ja gerade die IFOPT-Nummern für den AVV und bin da auf das Problem gestoßen, dass es außerhalb der Städteregion Aachen keine flächendeckend verfügbaren, lokalen Mastbezeichner gibt. Mein bisheriges Verfahren, die Haltestellendaten als zusätzlich Ebene in JOSM einzublenden und die Daten dann rüber zu kopieren hat sich da als nicht praktikabel erwiesen, da eine Zuordnung nur über die Koordinaten zu unsicher ist. Was aber halbwegs zuverlässig ist, ist die Zuordnung Anhand der Linien, die dort halten, was ich bisher auch im Zweifelsfall mittels PTNA zu Rate gezogen habe. Was ich mich jetzt Frage: PTNA kann ja schon Daten aus GTFS auf Knopfdruck in OSM-Routen injizieren. PTNA kann auch anhand einer Linienrelation, die Haltestellendaten aus GTFS und OSM nebeneinander legen und vergleichen. Es wäre doch ein Traum, wenn man dann beim Missmatch einfach die Daten wie bei üblichen 2-way diff tools von der GTFS zur OSM Seite rüber schieben könnte, oder nicht?--Trockennasenaffe (talk) 13:07, 27 May 2025 (UTC)

Wenn ich dich richtig verstehe, wäre dass eine super Idee: Du meinst also, dass ich z.B. auf GTFS trip versus OSM route in die Spalte "name" der Stop-Nummern 6, 21, 34, ... eine Injektionsnadel baue, mit der der "stop_name" aus GTFS als "name" in die OSM-Platform kopiert wird (was ist dann mit der zugehörigen stop_position?). Selbiges für ref:IFOPT, ...? --ToniE (talk) 16:04, 27 May 2025 (UTC)

So konkret mit Injektionsnadel oder wie auch immer hatte ich das bisher gar nicht durchdacht, aber du hast offensichtlich die Grundidee verstanden. Also ich möchte eine Möglichkeit, die Daten von links in die korrespondierende spalte rechts zu kopieren sozusagen. Wie man das konkret macht, da gibt es sicherlich mehrere Möglichkeiten. Könnte mir z.B. auch Checkboxen an jedem Wert die man markieren kann und dann irgendwo eine große "Injektionsnadel" oder so vorstellen. Am liebsten natürlich für alle Werte aus GTFS die in OSM potentiell sinnvoll wären, also in jedem Fall name und ref:IFOPT aber für mich speziell auch sehr gerne local_ref. Es gibt doch auch in JOSM ein Tool, mit dem man bei Bearbeitungskonflikten an einer Node beide Versionen manuell Wert für Wert wieder zusammenführen kann, so ähnlich hatte ich mir das ursprünglich vorgestellt, aber das muss nicht das beste sein, da gibt es vielleicht noch bessere Ideen, wie das konkret aussehen würde.--Trockennasenaffe (talk) 16:49, 27 May 2025 (UTC)

Ich überlege noch, wie das Handling (wie muss was, wie oft angeklickt werden um alle sinnvollen Daten zu kopieren) zu realisieren wäre um möglicht wenig oft zu klicken aber auch exakt eine Auswahl treffen zu können welche Daten denn tatsächlich kopiert werden sollen. GTFS-Daten enthalten auch oft Fehler. JOSM kann beim 'injekt' so konfiguriert werden, dass nicht jedes mal (nur beim ersten mal) gefragt wird ob und was kopiert werden soll. Dann wären für den Anwender z.B. 15 einzelne selektive Klicks auf die "Injektionsnadel" einfacher als 15 mal eine Check-Box + ein mal die "Injektionsnadel" (wo auch immer die plaziert ist!). Ein "kopiere alles von links nach rechts" möchte ich hier vermeiden. --ToniE (talk) 13:47, 28 May 2025 (UTC)

Ja ich wollte definitiv auch, das man jeden Wert einzeln auswählen muss, der übernommen werden soll, alles andere wäre sicherlich zu fehleranfällig, nur sollte dazu optimaler weise nicht mehr als ein klick nötig sein, wie auch immer das dann aussieht.--Trockennasenaffe (talk) 17:02, 28 May 2025 (UTC)

Ein Klick pro relevanter Zelle in der Tabelle ist zunächst am einfachsten zu implementieren. Wenn man, wie gesagt, JOSM "stumm schaltet", bleibts dann auch bei einem Klick pro Zelle.--ToniE (talk) 17:19, 28 May 2025 (UTC)

Einen Ersten Entwurf habe ich fertig. Der enthält noch nicht die Stop-Positionen der OSM-Platforms. Ein Injizieren der Daten wird nicht angeboten, wenn die Platforms (GTFS vs OSM) mehr als 100 Meter auseinander liegen. ie Chance, dass das nicht die selben Haltestellen sind ist recht groß, man kann ja immer noch manuell, ohne PTNA-Unterstützung anpassen. --ToniE (talk) 09:31, 2 June 2025 (UTC)

Gute Arbeit. Eine Anmerkung habe ich noch: Ich bekomme die Injektionsnadel nur da angezeigt, wo schon Daten vorhanden sind. Ich brauche die aber insbesondere da, wo die Daten, z.B. ref:IFOPT komplett fehlen.--Trockennasenaffe (talk) 13:57, 2 June 2025 (UTC)

Hast du ein Beispiel? Bei "Aachen, Ponttor" liegt das daran, dass GTFS und OSM 121 m auseinalder liegen (>= 100m), da ist PTNA vorsichtig, es könnte sich hier häufig um zwei unterschiedliche Haltestellen handeln. --ToniE (talk) 17:11, 2 June 2025 (UTC)

Hmm, stimmt, das ist meistens ein Problem mit der Entfernung. Ich hab hier lediglich noch den Sonderfall dass noch gar keine ref:IFOPT da ist, dann verschwindet die ganze Spalte: https://ptna.openstreetmap.de/gtfs/compare-trips.php?feed=DE-NW-AVV&release_date=&trip_id=474251940&relation=1307938 --Trockennasenaffe (talk) 17:33, 2 June 2025 (UTC)

'ref:IFOPT' z.B. gibt es nur in Europa, und 'local_ref' oder 'gtfs:stop_id' werden in manchen Gegenden nicht verwendet, 'platform_code' ist in vielen GTFS-feeds nicht enthalten.

Spalten auszublenden ist irgendwie ein Kompromiss zwischen zu breiter Tabelle (alle möglichen Spalten zeigen) und Anpassung der Tabelle an die lokalen Gepflogenheiten bzgl. der Gegend in der das 'network' ist und der GTFS-feed erzeugt wird.

'platform_code' und 'local_ref' tauchen gemeinsam auf, wenn mindestens eine Haltestelle einen der Werte enthält. Bei den anderen Spalten ist es analog.

Eine zentrale Haltestelle(ngruppe) in der Stadt manuell mit 'ref:IFOPT' zu taggen dürfte ein gute Anfang sein, an das sich PTNA dann anpasst und die Spalte zeigt. --ToniE (talk) 20:40, 2 June 2025 (UTC)

Nachtrag: Grundsätzlich wäre es bei vielen Werte sinnvoll, wenn die auch an die zugehörige stop_position dran kommen, wie z.B. ref:IFOPT. Für mich persönlich wäre allerdings schon ein groß0er schritt die über haupt an die platform zu kopieren. Ich kann mir da selbst schnell ein Tool basteln, das die Nummer auch an die zugehörige stop_position kopiert, wenn die nur dort noch fehlt. Für andere aber vielleicht wichtig, dass weiß ich nicht.--Trockennasenaffe (talk) 16:53, 27 May 2025 (UTC)

Theoretisch machbar wäre das in PTNA: ich kenne ja die ID der platform, ich weiß, an welcher Stelle der Liste der Member der Route-Relation die ID auftaucht, ich könnte in der Liste eine Position davor die stop_position vermuten, deren name, ref:IFOPT, ... mit der der Platform vergleichen und, bei Gleichheit, die stop_position mit in die Injekt-Liste aufnehmen. Das setzt eine wohl-sortierte Route-Relation voraus. Alternativ könnte ich die stop_position aus der Liste aller stop_position dieser Relation wählen (und danach die Werte vergleichen), die am nächsten dran liegt (auch mit gewisser Unschärfe behaftet). --ToniE (talk) 10:20, 29 May 2025 (UTC)

Was mir heute noch als Idee gekommen ist. Bin vielleicht nicht der erste, der das anregt, aber wäre es vielleicht sinnvoll, in PTNA auch den deutschlandweiten GTFS-Feed von Delfi anzubieten https://www.opendata-oepnv.de/ht/de/organisation/delfi/startseite?tx_vrrkit_view%5Baction%5D=details&tx_vrrkit_view%5Bcontroller%5D=View&tx_vrrkit_view%5Bdataset_name%5D=deutschlandweite-sollfahrplandaten-gtfs&cHash=af4be4c0a9de59953fb9ee2325ef818f ? Die Daten scheinen zumindest für den AVV gleichwertig zu sein, die beinhalten durchgehend die IFOPT-Nummern, Lizenz passt auch und vielleicht wäre das hilfreich für Regionen, die keinen eigene Feed haben.--Trockennasenaffe (talk) 10:36, 28 May 2025 (UTC)

DELFIs Lizenz ist CC-BY 4.0 und die ist nicht kompatibel mit OSM. Es braucht ein zusätzliches Schreiben, ob die geforderte Namensnennung mit einem Eintrag unter "Contributors" ausreichend ist. Ein solches Schreiben liegt nicht vor. --ToniE (talk) 13:47, 28 May 2025 (UTC)

Ah ok, da bin ich einem Irrtum erlegen. Die Erlaubnis gilt nur für die Haltestellendaten der Delfi, das war mir nicht klar.--Trockennasenaffe (talk) 17:02, 28 May 2025 (UTC)

Holger von mfdz.de hatte auf der FOSSGIS im März angekündigt, dass er bei DELFI nachhaken wolle, scheint noch keinen Erfolg gehabt zu haben (Eigenschaften von Bushaltestellen). --ToniE (talk) 17:19, 28 May 2025 (UTC)

Normalisierung des Haltestellennamens

Bei der Haltestelle "STAWAG" in Aachen scheint die Namen-Normalisierung schief zu laufen. Die macht daraus "StarnbergWAG", siehe z.B. https://ptna.openstreetmap.de/gtfs/compare-trips.php?feed=DE-NW-AVV&release_date=&trip_id=464949472&relation=1231833 Das ist natürlich falsch und passt dann so nicht mehr zusammen. Das steht in Wirklichkeit für Stadtwerke Aachen AG und wird praktisch nirgendwo ausgeschrieben.--Trockennasenaffe (talk) 15:15, 26 May 2025 (UTC)

Hab's korrigiert --ToniE (talk) 17:42, 26 May 2025 (UTC)

Wann werden die GTFS-Daten aktualisiert?

Ich verstehe bisher nicht so ganz, wann die GTFS-Daten jeweils aktualisiert werden. Ich hatte gedacht, das passiert am Monatsanfang, aber wenn ich das richtig sehe sind die Daten vom AVV momentan vom 13.5. https://ptna.openstreetmap.de/gtfs/DE/routes.php?feed=DE-NW-AVV Konkret warte ich auf eine Fahrplanänderung, die am 24.5. rein gekommen sein sollte.--Trockennasenaffe (talk) 08:23, 2 June 2025 (UTC)

Ja, normalerweise übernehme ich die erstem im Monat verfügbaren Daten. Auf "Zuruf" kann ich aber jederzeit einen Update machen, z.B. wenn ein umfangreicher Fahrplanwechsel mitten im Monat stattfand. Das wissen aber lokale Mapper besser als ich, ich prüfe so etwas nicht. unter z.B. "DE-NW-AVV Details" kannst du sehen, welche Versionen zur Verfügung stehen, und welche seit dem letzten Update übersprungen/ausgelassen wurden. --ToniE (talk) 08:53, 2 June 2025 (UTC)

Ok, wenn ich das richtig verstehe, müsste dann die Version von heute irgendwann eingelesen werden. Meines Erachtens ist die Äderung nicht groß genug um da jetzt extra ein Update anzustoßen. Dann warte ich einfach noch was ob es jetzt so funktioniert.--Trockennasenaffe (talk) 09:05, 2 June 2025 (UTC)

Der Update-Check wird täglich um 13:15 localer Zeit Deutschland gestartet. Schauen wir mal. --ToniE (talk) 09:31, 2 June 2025 (UTC)

Ja jetzt passt es--Trockennasenaffe (talk) 12:56, 2 June 2025 (UTC)