PTNA - News: ÖPNV-Analyse

Ankündigung

Aus dem Thread “PTNA - News: GTFS-Analyse”, Betrag #154 und #155 https://forum.openstreetmap.org/viewtopic.php?pid=785530#p785530

Das habe ich als Anregung genommen, eine neue Prüfung in PTNA einzubauen.

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen …

*** bus, trolleybus, share_taxi, coach**

** highway = motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, unclassified, residential, service, track, footway, cycleway, path, pedestrian, living_street, road, construction

*** train, light_rail**

** railway = rail, light_rail, narrow_gauge, preserved, construction

*** subway**

** railway = subway, light_rail, tram

*** tram**

** railway = tram, rail, light_rail, narrow_gauge

** … und so weiter …**

Das deckt schon mal so ziemlich alles ab was ich bei einem ersten Durchlauf an einigermaßen plausiblen Dingen gefunden habe.

Es kam auch railway=disused|abandoned|razed, highway=steps und anderes Schreckliches zum Vorschein.

highway=footway|cycleway|path|pedestrian|construction werden in einem anderen Schritt geprüft, ob psv=yes oder bus=yes dran hängt.

Die Meldungen sehen im Wesentlichen so aus:

  • PTv2 Route: ein falscher Wegtyp wird benutzt (falscher Wert: ‘highway’ = ‘give_way’): ‘Breslauer Straße’ 61580672 ( iD , JOSM )

  • PTv2 Route: ein falscher Wegtyp wird benutzt (fehlender Schlüssel: ‘highway’): ‘Cäcilienbrücke’ 22981747 ( iD , JOSM )

Was noch fehlt: akzeptieren von “Bus, der eine Fähre nimmt” - d.h. kein highway= aber route=ferry mit motor_vehicle=yes oder so …

Gruß,
Toni

Tool zur Visualisierung… wären noch toll :wink:

so wie z.B.:
https://osmrm.openstreetmap.de/relation.jsp?id=11029369
http://ra.osmsurround.org/analyzeMap?relationId=11029369

und eine Map… die die Platformen… mit einer Linie in der Reihenfolge verbindet, auf einer Karte… wie bei der GTFS analyse. Damit lassen sich Fehler auch schnell finden :slight_smile:

z.B:
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=30.T5.19-213-s20-1.5.H

Gruß Miche

Hey, gute Idee!

Vor allem das mit den “Platformen” und “Reihenfolge” und … ist gut und ein wenig “tricky” wenn Platformen ‘way’ oder ‘relation’ sind (lat/lon herausfinden).

Lässt sich alles in der Spalte “Relation (=id)” unterbringen.

Moin,
also track, footway, cycleway und path würde ich ja mal als seltsam ansehen. Das sind ja dinge die nicht für Motorisierte Fahrzeuge bzw keinen normalen Verkehr gedacht sind.

Auch living_street sehe ich noch einigermaßen kritisch. living_street ist für den ruhenden Verkehr nach StVO. D.h. eine Busroute da durch halte ich für äusserst Fragwürdig. Ich weiss das es das in ganz komischen fällen wirklich gibt aber IMHO ist das dann ein Fehler der Straßenverkehrsbehörde die diesen Abschnitt nicht hätte Verkehrsberuhigt erklären dürfen.

Flo

Bei uns fährt der Bus sogar auf dem Fussweg: https://www.openstreetmap.org/way/23128083 :smiley:

Moin,

ich stimme dir zu.

Diese neue Prüfung behandelt an dieser Stelle zunächst nur den technischen Aspekt - ist der Wegtyp prinzipiell geeignet.

Eine andere, ältere Prüfung behandelt den “rechtlichen” oder “sinnhaften” Aspekt. D.h. an einem ‘pedestrian’ , ‘footway’, ‘cycleway’, ‘path’ oder ‘construction’ oder wenn ‘access’ / ‘motor_vehicle’ / … = ‘private’ / ‘no’, …: dann muss zusätzlich ein 'psv = ‘yes’ oder ‘bus’ / ‘taxi’ / ‘share_taxi’ / … = ‘yes’ oder so dranhängen.
So wie es die Schilder in Realität dann auch freigeben würden.

‘living_street’ ist so eine Sache: in OSM schließt das keinerlei motorisierten Verkehr aus - allenfalls ‘hgv’?

Gruß
Toni

Ja, living_streets sind seltene Fälle, aber gerade beim share_taxi können die schon vorkommen. Wirklich befahren werden sie dann aber selbst mit dem wohl sehr selten, da deren Route beim “AnrufSammelTaxi” ja immer nur an das “on-demand” angepasst ist.

Auf der anderen Seite wird in die “living_street” in Deutschland (gerade NRW) mittlerweile ja alles Mögliche reingepackt, nur um Verkehrberuhigungen zu “propagieren”. In Neubaugebieten ist oft alles living_street, auch die hineinführenden Straßen (auf denen dann eh 30 gefahren wird), damit man keinen Bürgersteig bezahlen muss. Hier gibt es 40 m living_street auf der Hauptverkehrsstraße: https://www.openstreetmap.org/way/683503425/

Update:

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte Wegtypen benutzen …

Die im ersten Beitrag beschriebenen Änderungen sind aktiv und werden in der nächsten Nacht das erste Mal angewandt.

Die genaue Belegung, d.h. welches Fahrzeug darf welche Wege benutzen ist unten im Code-Fenster zu sehen (zu aufwändig, das alles anders darzustellen).

Das sieht für ‘train’, ‘subway’ und ‘tram’ noch ein wenig wild aus. Aber diese Kombinationen habe ich massenhaft gefunden. Später mal kann man das gegebenenfalls strenger auswerten, bei Bedarf.

“Bus, der eine Fähre nimmt” ist auch gelöst.

Gruß,
Toni

my %transport_type_uses_way_type = ( 'train'     => { 'railway'   => [ 'rail',   'light_rail', 'tram', 'narrow_gauge', 'preserved',  'construction' ] },
                                     'subway'    => { 'railway'   => [ 'subway', 'light_rail', 'tram' ] },
                                     'tram'      => { 'railway'   => [ 'tram',   'rail',       'light_rail', 'narrow_gauge', 'subway' ] },
                                     'monorail'  => { 'railway'   => [ 'monorail'  ] },
                                     'funicular' => { 'railway'   => [ 'funicular' ] },
                                     'ferry'     => { 'route'     => [ 'ferry'     ] },
                                     'aerialway' => { 'aerialway' => [ 'cable_car',     'gondola',        'mixed_lift',   'chair_lift' ] },
                                     'bus'       => { 'highway'   => [ 'motorway',      'motorway_link',  'trunk',        'trunk_link',    'primary',      'primary_link',
                                                                       'secondary',     'secondary_link', 'tertiary',     'tertiary_link', 'unclassified', 'residential',
                                                                       'service',       'track',          'footway',      'cycleway',      'path',         'pedestrian',
                                                                       'living_street', 'road',           'bus_guideway', 'construction'
                                                                     ]
                                                    },
                                   );
   $transport_type_uses_way_type{'coach'}       = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'share_taxi'}  = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'trolleybus'}  = $transport_type_uses_way_type{'bus'};
   $transport_type_uses_way_type{'light_rail'}  = $transport_type_uses_way_type{'train'};

Das Problem ist lösbar http://www.roeltgen.com/gpx/ibro_ol4ptunnel.html?idt=66044,11029369
Ich würde nicht die geometrische Mitte der Platform sondern den Übergabepunkt als Referenzpunkt der Haltestelle nehmen. Von der stop_position rechtwinklig auf den platform-way. (Bei mir mit rotem Punkt markiert)

Bei den 15 Varianten von Bus 501 wird das aber etwas unübersichtlich http://www.roeltgen.com/gpx/ibro_ol4ptunnel.html?idt=4582153 wenn man hier noch die gtfs mit einblendet.

Danke Axel,

das mit der geometrischen Mitte ist eigentlich nicht so wichtig. Wenn es vornehmlich darum geht, zu beurteilen, ob die Haltestellen in einer “augenscheinlich” richtigen Reihenfolge sind, reicht irgendein Punkt des ways, der relation aus- auch weil ich in PTNA mit lat/lon derzeit überhaupt nicht arbeite und eine stop_position in der Nähe evtl. nicht existiert…

Zum Beispiel: http://www.roeltgen.com/gpx/ibro_ol4ptunnel.html?idt=7603199

Wenn man hier die Haltestellen gemäß ihrer Reihenfolge in der Relation nummerieren würde, könnte man recht schnell sehen, ob da was nicht stimmt.

Z.B. ist die selbe Linie https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=1.T0.18-732-1-s20-1.9.H gemäß GTFS völliger Blödsinn - es ist ein Ruftaxi mit flexibler Route (on-demand).

Zumindest hatte ich Miche so verstanden.

Gruß
Toni

Wenn du ids= statt idt= nimmst steht die Haltestellenabfolge unter der Karte (Glühbirne anclicken).
http://www.roeltgen.com/gpx/ibro_ol4ptunnel.html?ids=7603199

Ich hatte bisher darauf verzichtet die Haltestellennummern in der Karte aufzuführen, da dies bei wenigen Varianten unübersichtlich wird. Ein kleiner Pfeil für Folgehaltestelle ist in dieser Richtung scheint mir praktikabler zu sein.

Zu deinem Beispiel: Bei AST-Routen ist es einfacher nur einen Hauptweg in der Mitte vollständig aufzunehmen und die abgelegenen Haltestellen nur als Platform aufzuführen.

Im Gegensatz zu den anderen Darstellungen wollte ich hier ausschließlich die lat/lon der Platforms in der Reihenfolge der Relation darstellen mit Luftlinienverbindung - und nicht die Ways berücksichigen? …

Oder doch? Die Relation mit Ways darstellen und in anderer Farbe die Luftlinienverbindung zwischen den Platforms.
Wäre es dann möglich, mit den Augen, irgendwelche Abweichungen wahrzunehmen?

@Miche: kommt das deinem Vorschlag am nächsten?

Ja das mein ich… ob man die Ways zusätzlich in einer anderen Fahre (eventuell als eigenen Layer) auch noch darstellen kann ist mir einerlei…

OK, bin noch am überlegen wie ich das am günstigsten hinbekomme:

Button, der JavaScript startet, neues Fenster mit Karte, der Einfachheit halber der JavaScript-Funktion die lat/lon der Platforms als JSON mitgegeben: die Infos habe ich eh schon, und JavaScript muss sich die Infos nicht nochmals per Overpass oder OSP-API besorgen, berechnen, ausfiltern, …

Schauen wir mal, das muss im Kopf noch reifen … macht aber nur bei PTv2-Relationen wirklich Sinn.

kannst dir hier abschauen: (von mir :wink: )
https://greymiche.lima-city.de/bus-relation/ptv2_platform_to_rte/index.html?relation=10981156

Klar, alle Daten müssen aus dem ptna-Bestand kommen.

Ich hab mal eine Vergleichsseite mit bestehenden Möglichkeiten hingehuddelt
http://www.roeltgen.com/gpx/ibro_ol4ptgtfstestN47.html?ids=919808
Bus N47 (VRS) gpx(gtfs) heruntergeladen und festverdrahtet.
Eine derartige Darstellung (mit später mal nummerierten Haltestellen) wäre brauchbar.
Man erkennt die vergessene Haltestelle und die abweichenden EFA-Koordinaten.

Die Handhabung von 15 Varianten wird aber ein Problem bleiben.
Nach meiner Meinung müssen wir aus gtfs per Majoritätswertung eine Variante als Nennlinie ausmachen und Teilrouten-Varianten ausschließen.

Und natürlich nicht blauäugig ans Mappen gehen, denn

  • die Koordinaten in osm sind meist besser als in gtfs oder eva und
  • die Routen in gtfs haben auch Fehler.

Genau so und die Reihenfolgenummer der Haltestelle sichtbar: dann kann man grobe Fehler in der Reihenfolge sofort sehen.

Diese Darstellung wäre optimal, setzt aber GTFS-Daten voraus, und dass ich zur OSM-Relation eine passende Trip-ID gefunden habe - das tag; “gtfs:trip_id=…” in der Relation hilft hier :slight_smile:

Aber auch ohne GTFS als SOLL-Vorgabe und mit Nummerierung der Haltestellen und die rote dicke Linie auf Basis der lat/lon der OSM-Platforms in der gegebenen Reihenfolge … würde grobe Fehler sichtbar machen.

Und selbst ohne die rote Linie:

http://www.roeltgen.com/gpx/ibro_ol4ptgtfstestN47.html?ids=9041933

Hier fehlt im Westen “Dachau (S)” als Haltestelle, das weiß ich.
Oder aber die Frühlingstraße ist die erste Haltestelle und die Ways von Dacheu (S) bis Frühlingstraße davor sind überflüssig (was auch ein Fehler wäre).

Aber beide Ansätze gehen in die richtige Richtung.
Ich hatte auch schon überlegt, brouter mit den Positionen der Platforms zu füttern (kein eigenes JavaScript, … keine eigene Page, …) aber irgendwie sollten die OSM-Ways der Relation drunter liegen.

Was mir mittelfristig vorschwebt: die PTNA-Analyse bekommt beim Aufruf die Lage der SQLite-DB (die der GTFS-Analyse) mitgeteilt und kann versuchen eine Routen-Variante (Relation-ID) mit einer Trip-ID zu vergleichen: hinsichtlich Haltestellen-Position, -Name, -Reihenfolge, … bis hin zu “shapes” (sofern vorhanden).
Aber zu einer Relations-ID eine passende Trip-ID zu finden dürfte nicht einfach sein … ohne false-positive oder false-negative Match. …: “gtfs:trip_id=…” in der Relation würde etwas helfen.

So, für die Anzeige ist schon mal ein erster Versuch verfügbar.

Nicht komplett:

  • Platform als MP-Relation werden noch nicht dargestellt (so wie bei osm.org auch nicht), sie müssen ‘nachgeladen’ werden
  • Stop-Positionen sollen noch als gelbe Marker kommen
  • zwischen Platforms und auch zw. Stops noch jeweils eine Luftline
  • das alles über Layer ein- und ausblendbar
  • in der PTNA-Analyse noch nicht verlinkt

https://ptna.openstreetmap.de/relation.php?id=1549762

Gruß
Toni

Ein gutes Stück weiter gekommen …

In der PTNA MVV Analyse bereits verlinkt (‘PTNA’ in der Spalte “Relation”).

Was fehlt?

  • Platform als MP-Relation werden noch nicht dargestellt (so wie bei osm.org auch nicht), sie müssen ‘nachgeladen’ werden
  • Stop-Positionen sollen noch als gelbe Marker kommen - da bräuchte ich eine eigenes Icon
  • Tooltip ist derzeit die Reihenfolgenummer innerhalb der Relation - ein onClick() kommt noch …

schön schön, die “Stop-Position Route” bräuchte ich jetzt nicht. Die Stop-Position sehe ich nur im Zusammenhang mit Routing… als hilfreich an.