Talk:Nürnberg/Transportation/Analyse

Diskussionen

(11.11.2024): Der Suchbereich für das PTNA-Tool ist zu klein: da sind Iphofen und Kitzingen noch nicht enthalten. Kann es sein daß die Definition des VGN-Verbundgebietes 3878887 3878887 in OSM um Jahrzehnte zu alt ist? Wer legt diese Relation fest? Sie wurde zwar erst vor wenigen Tagen zuletzt geändert, aber Iphofen kam 2006 zum VGN, Kitzingen wenige Jahre später. Und sie fehlen noch immer. Haßfurt dagegen ist in der Relation enthalten. Was läuft da schief?

(12.11.2024): OK. Seit 01.01.2017 ist der gesamte Landkreis Kitzingen im VGN. Zuvor waren seit 2006 nur Teile im VGN. Haßberge ist seit 2010 im VGN. Bin noch auf der Suche nach den Dokumenten, Landratsamt KT hat keine Permalinks auf Sitzungen/Sitzungsvorlagen. Werde dann die Relation ändern.

(19.11.2024): Mir ist nicht klar, weshalb in der Analyse einige Stadtbusse von Schweinfurt auftauchen: Linien 21, 31, 32, 33, 43, 44, 49, 51, 52, 59, 61, 62, 63, 64, 65, 71, 82... Das Problem ist daß Nürnberg die gleichen Nummern für Stadtbusse verwendet. Und PTNA findet dann mehrfache RouteMaster. Die Fehler die für die Schweinfurter Linien gemeldet werden hängen wohl z.T. daran daß da noch nicht auf PTv2 umgestellt ist. Ich fürchte, ich habe da schon versehentlich Änderungen vorgenommen weil mir nicht sofort aufgefallen ist daß das eine Schweinfurter Linie ist (Roßmarkt ist halt kein seltener Name).

Was ist da los, am Suchgebiet kann es ja eher nicht liegen. --Wyk (talk) 11:53, 19 November 2024 (UTC)

Doch, indirekt liegt es am Suchgebiet.

- Wenn ich die OSM-Daten mit Overpass-API suche, reicht es aus, die Originalgröße des VGN zu nehmen. Die Suchabfrage von PTNA mit Overpass findet alle Route-Relationen (und deren Eltern - route_master), die mindestens einen Node (auch Node of Way) im Suchgebiet haben, plus deren Geschwister-Route-Relationen: selbst wenn die komplett außerhalb sind.

- Es wird in PTNA auf Planet-Extracts und OSMIUM umgestellt. Geschwister-Route-Relationen können nicht gefunden werden (z.B. Bus 451-Variante von Burglengfeld nach Regensburg). Daher wird pauschal das Suchgebiet erweitert (VGN + x KM drumherum), und so kommen dann vermehrt Route-Relationen aus Nachbarverbünden hinzu.

Lösung: 'network' setzten, so viel und so oft wie möglich, d.h. auch bei den Stadtbussen von Schweinfurt. Die fallen dann wegen nicht-passendem 'network' aus der Analyse raus.

--ToniE (talk) 17:45, 19 November 2024 (UTC)

Ich arbeite noch daran sowohl das Original-Suchgebiet (bei Overpass, siehe 2. Spalte auf Überlick) als auch das erweiterte Suchgebiet (bei OSMIUM) zusammen auf einer Karte zu zeigen. Schauen wir mal, wie und ob ich das hinbekomme.

--ToniE (talk) 17:53, 19 November 2024 (UTC)

Danke. Ja, ich hatte das Überlappen der Linien auch in Erwägung gezogen und nach Stellen gesucht aber nix gefunden. Stadtbus von Schweinfurt ist schon ein ganzes Stück vom VGN-Bereich entfernt. Könnte es sein daß ein Haltestellenname oder eine Buslinie einmal falsch verlinkt wurde weil es den Namen in beiden Bereichen gibt? Hab ich auch noch nix gefunden. --Wyk (talk) 22:31, 19 November 2024 (UTC)

Und wieso tritt das bei so vielen Linien auf. Ich hatte Roßmarkt als Name im Verdacht, gibts aber im VGN nicht, nur Großmarkt mit 'roßmarkt' im Namen. Aber wieso tritt der Effekt nicht mit VVM auf, der ja auch an Schweinfurt grenzt. Dort heißen die Busse "Stadt-Bus", in Schweinfurt und Nürnberg "Stadtbus". --Wyk (talk) 22:44, 19 November 2024 (UTC)

Mit 'Namen' hat das nichts zu tun. In OSM haben nur die Nodes eine lat/lon, und darauf kommt es an. Es werden alle Relationen und Ways berücksichtigt, die mindestens einen Node im Suchgebiet haben. Für den VGN habe ich das Suchgebiet bzgl OSMIUM erweitern müssen, beim VVM nicht. Die Notwendigkeit das Suchgebiet zu erweitern sehe ich im z.B. im VVM-Logfile anhand von "Error in input data: insufficient data for relations of route 'ref' = 'RB 79'". Sollte hier einen Busnummer auftauchen, so erweitere ich gegebenenfalls das Suchgebiet. Für Regionalzüge mache ich das nicht, es gibt ja noch die Analyse DE-Bahnverkehr. --ToniE (talk) 14:06, 20 November 2024 (UTC)

Danke, wieder was gelernt! Ich denke dein obiger Vorschlag mit den network-Tags ist das Richtige und hilft auch wirklich. Leider sind die Schweinfurter Buslinien noch nicht auf PTv2 umgestellt. Ich hatte gestern Kontakt zu Michael der die meisten Änderungen an den Schweinfurter Linien vorgenommen hat. Er will im Dezember daran arbeiten. Zuvor sollten wir noch wissen wie Schweinfurt die Anpassung an NVM plant, sonst muß man jedes Objekt zweimal anfassen. Ich lasse also vorerst die Finger von Buslinien mit zweistelligen Busliniennummern, gibt genug anderes zu tun. --Wyk (talk) 14:47, 20 November 2024 (UTC)

(19.11.2024): Wg. Liniennummern der Busse: Ich habe soeben mal beim Landratsamt KT nachgefragt, wie sie das Problem lösen wollen daß die neuen Kitzinger Busliniennummern 300-399 mit den 3xx Nummern vom VGN in Bayreuth kollidieren. Hintergrund meiner Frage war daß der VGN angefangen hat die 2025 Fahrpläne zu verteilen. Und was passiert wenn man Nummernkreise doppelt benutzt hatte ich bei obenstehendem Problem gesehen. Ich zitiere mal aus der Antwort:

"die Liniennummern im NVM-Gebiet werden künftig 3##er Nummern sein, für den VGN haben wir uns mit den Kollegen in Nürnberg vereinbart, dass die neuen 3##er-Nummern um eine vorangestellte 8 ergänzt werden. Das ist unglücklich, lässt sich jedoch durch die doppelte Verbundzugehörigkeit des Landkreises Kitzingen im NVM und VGN nicht vermeiden."

Allmächd. Und mit welchem ref-Wert soll ich dann bei OSM taggen? ref=3xx, ref:NVM=3xx; ref:VGN=83xx; ref:VVM=* (VVM nur für die Übergangszeit) ; --Wyk (talk) 13:38, 19 November 2024 (UTC)

ref="3xx/83xx/*" + ref:NVM="3xx" + ref:VGN="83xx" + ... ist leider so bei Kooperationen

--ToniE (talk) 17:45, 19 November 2024 (UTC)

(22.11.2024): Mir ist nicht klar was diese Fehlermeldung mir sagen soll: "Fehler in den Inputdaten: nicht genügend Daten für 'relations': Relation 5368303 (iD, JOSM)" Die Platformen am Bahnhof Würzburg werden an verschiedenen Stellen angemeckert, hier ist es die Linie RE10 (544546 544546) mit der Platform 5368303 5368303. Ich sehe nicht was da falsch sein soll. --Wyk (talk) 20:24, 22 November 2024 (UTC)

Da sind keinen Fehler. Die Meldungen hängen mit Osmium zusammen. Anders als bei Overpass kann Osmium keine Relationen in Relationen (MP Platform bei Zugrouten) finden, wenn diese nicht im Suchgebiet liegen. Diese Daten fehlen bei der Analyse dann. Für Regionalzüge will ich das Suchgebiet aber auch nicht erweitern, da es hierzu ja noch die DE-Bahnverkehr-Analyse gibt.

Damit bin ich nicht glücklich. PTNA muss aber von Overpass auf Osmium umsteigen, da PTNA die Fair-Use-Policy von Overpass verletzt und tag-täglich mehr Daten absaugt als "fair gegenüber anderen Nutzern" ist. --ToniE (talk) 13:06, 23 November 2024 (UTC)

Danke für die Erläuterungen. --Wyk (talk) 12:13, 25 November 2024 (UTC)

(25.11.2024): wg. GTFS: Was mache ich mit den GTFS-Tags für RouteMaster und Route wenn die GTFS-Daten die Route(n) nur ungefähr beschreiben? Ich möchte vermeiden daß irgendwer aus den GTFS-Daten die Routen aktualisiert und dabei die eigentlich korrekte Route zerschießt:

• Generell: Die GTFS-Daten für VGN sollten einmal überarbeitet werden: die GTFS-Routen stimmen nicht mit den Fahrplandaten überein.
• Bei Landkreisüberschreitungen enthalten die GTFS-Daten nur einen Teil der Strecke, nämlich nur soweit wie der (VGN-)Tarif gilt.

Ich habe jetzt angefangen die GTFS-Tags zu setzen, auch wenn die Route nur ungefähr paßt. --Wyk (talk) 12:13, 25 November 2024 (UTC)

Das ist das Problem mit den GTFS-Daten. Ich habe noch keinen einzigen GTFS-Datensatz gesehen, der nicht (z.T. gravierende) Fehler enthielt. Die Übereinstimmung der GTFS-Daten mit den online-(PDF-)Fahrplandaten des MVV kann ich eigentlich nur für den süd-östlichen Landkreis München prüfen. Da zu sind wohl Ortskenntnisse notwendig. Die "Macher" = Verkehrsverbünde lernen noch, es wurde aber im Laufe der Jahre besser. Prinzipielle Fehler bleiben meist recht lange drin.

In wie weit man unter diesen Umständen die "gtfs:route_id", "gtfs:trip_id", ... in den Relationen setzt, kann ich nicht pauschal beantworten. Da kommen auch andere Faktoren hinzu: wie stabil sind z.B. die "trip_id"-Werte in den GTFS-Daten? Ändern die sich mit jeder neuen GTFS-Version? Dann lieber die Finger davon lassen. --ToniE (talk) 15:32, 25 November 2024 (UTC)

Man könnte die GTFS-Daten (feed,route_id) in den CSV-Daten setzen, damit macht man zunächst mal keine OSM-Daten kaputt. Bei der QA wird es helfen, da es entsprechenden "GTFS" und "Compare" links im Report erzeugt. Siehe z.B. feed=DE-BY-MVV und route_id=20-970-s24-1 in den CSV-Daten für den MVV X970;bus;Expressbus;Bad Tölz;Starnberg (S);Geldhauser;DE-BY-MVV;20-970-s24-1 --ToniE (talk) 16:07, 25 November 2024 (UTC)