Ich hab große Probleme bei Bahnhöfen im AVV die IFOPT-Nummern aus dem DELFI Datensatz zuzuorden bzw. die Systematik dahinter zu erkenne. Beispiel für Aachen Hbf:
Der hat folgende Nummern laut DELFI:
de:05334:1008:7:70
de:05334:1008:90:1
de:05334:1008:90:90
de:05334:1008:91:2
de:05334:1008:91:3
de:05334:1008:92:6
de:05334:1008:92:7
de:05334:1008:93:8
de:05334:1008:93:9
de:05334:1008:98:98
Es scheint so zu sein, dass
de:05334:1008:90:1
de:05334:1008:91:2
de:05334:1008:91:3
de:05334:1008:92:6
de:05334:1008:92:7
de:05334:1008:93:8
de:05334:1008:93:9
Die Bahnsteigkanten sind und
de:05334:1008:90
de:05334:1008:91
de:05334:1008:92
de:05334:1008:93
die Bahnsteige. Das kommt hin.
Komplett aus dem Rahmen fällt aber die de:05334:1008:7:70 und laut den GTFS-Daten vom AVV halten da aber alle Züge. Kann sich also eigentlich nicht um einen Bahnsteig handeln aber was ist das dann? Bei den anderen Bahnhöfen ist es teilweise noch merkwürdiger, aber das zieht sich durch, das da offenbar keine bahnsteigscharfe IFOPT genommen wird, sondern irgendeine andere, wo ich keine Ahnung habe, wie die ins schema passt. Weiß jemand, was die Systematik dahinter ist? Die Zuordnung durch https://gtfs.mfdz.de/delfi/region_de05334.html erscheint mir in diesen Fällen auch wenig vertrauenerweckend.
Was bedeutet NO_MATCH_AND_SEEMS_UNSERVED auf Deutsch KEINE_ÜBEREINSTIMMUNG_UND_SCHEINT_UNVERDIENT auf Deiner genannten Seite, auf der ich mit F3 “de:05334:1008:7:70” eingegeben habe?
Ich habe noch ein Punkt den ich hier gleich mit ansprechen kann. Wenn ich mich länger mit dem Thema IFOPT und den entsprechenden Tools beschäftige, wird eine Sorgen immer größer: Einige Tools und Router sehen es offenbar sofort als perfekten Match an, wenn die IFOPT an dem OSM-Objekt dran ist und passt. Zum einen Ist damit die Verantwortung sehr groß, weil man im Fehlerfall möglicherweise vieles kaputt macht und schwer zu findende Fehler produziert. Zum anderen frage ich mich auch, ob sich da nicht die Katze selber in den Schwanz beißt, wenn ich tools wie https://gtfs.mfdz.de/delfi/ nutze um komplizierte Fälle zuzuordnen was dann wieder dazu führt, das dieses Tool das in zukunft als perfekt passend ansieht. Ich denke, ich sollte da in jedem Fall vorsichtig sein.
Bedeutet, der Stopp konnte nicht zu OSM daten zugeordnet werden, allerdings existieren auch im entsprechenden GTFS-Feed keine Fahrten, die diesen Halt bedienen.
Unserved heißt in diesem Zusammenhang nicht bedient, also Haltestelle wird von keiner Linie angefahren (laut GTFS-Daten).
Offenbar gibt es hier aber einen Unterschied zwischen den DELFI-Daten und den AVV-DAten. Beim AVV wird diese Nummer angefahren, siehe PTNA - Compare GTFS trip with OSM route. http://gtfs.mfdz.de/delfi/ hat drei IDs zugeordnet, das ist plausibler, aber gibt auch nicht 100% Sinn.
Ich würde mal vermuten, dass das eine allgemeine Nummer für Aachen Hauptbahnhof ist, wenn keine bahnsteigscharfe Zuordnung möglich oder gewollt ist. Man sieht z.B. bei PTNA - GTFS Analysen, dass bei jedem Halt die IFOPT auf “7:70” endet. Ausnahme ist Stolberg Hbf Gleis 44, weil hier der Bahnsteig eindeutig bestimmt ist.
Das sieht mir auch so aus, wäre aber nach meinem Verständnis eine Verstoß gegen den Standard. Genau zu diesem Zweck sind IFOPTs ja hierarchisch aufgebaut und wenn man statt Bahnsteigkante 7 (de:05334:1008:92:7) nur Aachen Hbf sagen wollte müsste das dann einfach de:05334:1008 sein. Damit kann man dann auch ungenaue Zuordung von einer Fehlzuordung unterscheiden denn de:05334:1008:7:70 wäre demgegenüber eine (virtuelle?) Bahnsteigkante.
Laut AVV ist der Sachverhalt tatsächlich, dass die Nummer ein Platzhalter für ein „nicht näher definiertes Gleis“ ist, da sich bei dem Format für die Daten der Bahn momentan das Gleis noch nicht praktikabel auswerten lässt.
