Zu 1.) die Sekunden nehme ich noch raus. die Zeiten sind aber unabhängig davon ob nur Mo-Fr oder nur Sa+So oder jeden Tag … also ein wenig Vorsicht.
zu 2.) ja das sind 'ne Menge Daten, die bei der Aggragation wegfallen … nachdem ich erkannt habe, dass sie redundant sind: ein Bus, der alle 10 Minuten fährt von 04:48 bis 26:08 (02:08 des Folgetages) hat für jede Fahrt eine eigene Trip-ID und für jede Trip-ID gibt es eine Folge von Haltestelleneinträge (immer die gleiche), die angefahren werden und all diese Trip-IDs unterscheiden sich eigentlich nur bzgl. der Abfahrzeiten - für OSM eigentlich irrelevant. Da kann man eine Menge Holz vernichten.
zu 3.) Ja, das Kreativität bei den Namen ist grenzenlos. “Fürstenfeldb.” und Fürstenfeldbr." und “Höhenkirchen-S.”, “Höehenkirchen-Sie.”, “Höhenkirchen-Sieg.”. Bei einigen Dingen habe ich den Verdacht, dass hier auf Teufel-komm-raus versucht wird auf 16 Zeichen (oder so) zu reduzieren. lat/lon ist wohl die bessere Methode.
zu 4.) Da hast du Recht. Bei allem sollte im Hinterkopf bleiben, dass es einfach anzuwenden ist und Ausreißer möglichst erkannt werden und warum das ein Ausreißer ist, verständlich und nachvollziehbar bleibt.
Heute hab ich die erste Haltestelle ein Problem mit dem runden gehabt. Dort war die Platform weit hinter der der MVV, weil die Platform beim Schutzhäuschen gemappt war. Das Schutzhäuschen war weit weg von der Straße… jetzt hab ich einen shelter type => öpnv gemacht und die platform näher der Straße gebracht
Korrekt, und dann gibt’s noch andere Unterschiede:
Bus 210: Hst Ortsmitte (südwärts) und Robert-Koch-Straße (nördlich der Straße) wurden letztes Jahr umgebaut (verlegt: 30 - >50m), in den GTFS-Daten aber nicht angepasst
Die Analyse von Stops: OSM vs. GTFS ist eine anderes Thema, dem sich Dietmar (okilimu) widmen will. Das hatten wir auf dem Hack-Weekend in Karlsruhe im Februar mal so besprochen. Evtl. basiert das dann auf einem Ansatz von Holger von mfdz.de (https://mfdz.de/blog/haltestellendaten-bw-vergleich-osm-nvbw)
Bzgl. der Stops ansich: ich werde mal mit Dietmar Kontakt aufnehmen.
Da braucht’s eine andere Art von Auswertung als bei den Routen:
Lage der Platform (OSM vs. GTFS)
Name der Platform (korrekte Schreibweise, ref_name, …)
IFOPT (sofern bekannt, beim MVV ist die stop_id = IFOPT, bei anderen nicht …)
was fehlt in OSM
was ist in OSM zu viel
welche sind PTv2-konform
was ist mit SEV, Schulbussen?
Holger von mfdz.de hat da ja eine Python-basierte Analyse, die man evtl. anpassen könnte.
Die Analyse hat Daten nicht von GTFS, sondern von NVBW, und die CSV-Daten sind umfangreicher pro Haltestelle.
Die Analyse macht von dem ‘mehr’ an Daten Gebrauch, kommt also evtl. mit "reinem " GTFS nicht zurecht / nicht sehr weit.
Download der Umgebung einer Haltestelle in Id oder JOSM
Bei der Anzeige der Details eines einzelnen Trips (Routen-Variante) kann man die Umgebung einer Haltestelle (deren GTFS-Koordinaten) in iD oder JOSM laden.
In beiden Fällen ist nicht garantiert, dass die in OSM eventuell vorhandene Haltestelle sichtbar ist (liegt leicht außerhalb des Gebietes oder existiert nicht?).
In beiden Fällen kann die Position der Haltestelle gemäß der vorliegenden GTFS-Koordinaten (derzeit?) leider nicht sichtbar gemacht werden.
Download der Umgebungen aller Haltestellen in JOSM
Bei der Anzeige der Details eines einzelnen Trips (Routen-Variante) kann man die Umgebung aller Haltestellen (deren GTFS-Koordinaten) in einem Rutsch in JOSM laden.
Ich würde alle Nodes und Ways (und wg. ‘>’ alle Nodes der Ways) und
(wg. ‘<’) alle Eltern Relationen der Nodes und Ways erwischen
Aber … ich erwische nicht sämtliche Member der Relationen. D.h. nicht alle Member eines Flixbus “Paris ↔ Moskau”, sondern nur deren Member in den Aussschnitten. Das reduziert die Menge an Daten ganz gut.
Ich probiere das mal im Zusammenhang mit JOSM … bei shape-Punkten lediglich around:5.0 und …