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)

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)