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.

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)