PTNA - News: ÖPNV-Analyse

Communities Deutschland (Germany)
7

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/

8

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'};
9

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.

10

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

11

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.

12

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?

13

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…

14

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.

15

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

16

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.
17

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.

18

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

19

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 …
20

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.

21

Ist dennoch hilfreich, wenn z.B. bei 52 Haltestellen nur die 1. und letzte eine stop_position haben :confused:

Wie hier …

22

…und für was soll das hilfreich sein? Das man allen 52 Haltestellen eine stop_position verpasst? Ich seh diese als praktisch für das Routing… oder bei Busbahnhöfen… aber sonst meist rein erfunden/geraten. Ich verstehe nicht wie man diese vor Ort aufnehmen kann… in den aller meisten Fällen. Deshalb werde ich diese auch nicht fixen, wenn sie von der Lage grob abweichen ( zu großer Aufwand, komplex ). Deshalb kommt in diesem Fall nur eine Löschung in Betracht. Bei Plattformen das gleiche… da werden Flächen oder Linie gemappt die man vor Ort so nicht aufnehmen kann…, weil die z.B. ein ordinärer Gehweg ist ohne irgendwas. Die erste und letzte nimm ich für dich auf :wink:

23

… hast ja Recht.

Das PTv-irgendwas ist verkorkst. Es definiert ein großes Ziel mit Platform, (Stop-Position?), Stop-Area, Relation, … mit dem man schon was anfangen könnte.
Auf der anderen Seite läßt es zu viele Freiräume, die, wenn man die Freiräume (konsequent) ausnutzt, eine Relation unbrauchbar zurück läßt.
Mir erschließt sich der Sinn von Stop-Positionen auch nicht so recht, d.h. ich sehen nicht wirklich einen “Abnehmer” (eine App), die diese Daten wirklich benötigt.
Zudem fehlt fast immer eine Kennzeichnung der Stop-Position auf der Straße: “gezackte Linie auf der Straße = hier darf man nicht parken” - die Position ist also, wie du schon sagtest, in der Regel “geraten”.
Vermutlich hat die Stop-Position historische, rückwärts-kompatible Gründe Richtung: “highway=bus_stop” muss auf und nicht neben die Straße.

Würde mich nicht wundern, wenn eine Relation: “jede 2. Haltestelle als stop_position und jede andere 2. Haltestelle als platform gemapped” nach PTv2 immer noch “gültig” ist. Nur: ob mit so einem Mischmasch was anzufangen ist?

“Das Beste hoffen, das Schlimmste erwarten” trifft auf PTv2 wirklich zu und “das Schlimmste” findet man häufig vor.

Man muss mehr tun als nur die ‘mandatory’ oder ‘required’ Dinge zu tun. Wir hätten heute z.B. keine Smartphones und 3. / 4. / 5. Generation, wenn sich die Hersteller auf Netz- und Handy-Seite (aus Aufwandsgründen; weil man nicht weiß, ob es sich amortisiert) immer nur auf die ‘mandatory’ Features der Standards beschränkt hätten. Da kam immer der Druck von außen, mehr zu realisieren.

Aber, wie gesagt, bei PTv2 kann man mit den ‘mandatory’ Features nicht viel (nichts?) anfangen. Und welche ‘optionalen’ Features zum Ziel (der Brauchbarkeit) führen ist unklar, auch weil es keine Priorisierung und Use-Cases (wenn dieses gemacht wird, dann können wir das daraus machen) gibt.

Das führt, zugegebener Maßen, auf meiner Seite dazu, dass ich alles, so viel wie möglich, auch redundant (was die ‘tags’ angeht) mappe.

24

Ich sag mal… ptv2 ist nicht das Ende der Reise :wink: Man sieht ja immer wieder wo man an die Grenzen des darstellbaren kommt, oder mit des nachhaltens…, oder oder oder :expressionless: Und da muss man halt auch einmal was ändern… um den Daten noch einen Nutzen entziehen zu können und nicht nur veralterte/lückenhafte/falsche Datenbestände zu haben. Ptv2 ist zu viel verlangt da gibt es zu wenig men-power zum erfassen und pflegen… siehe MVV Bus 600er, 700er, 800er, 900er usw. Da hab ich vor 3 Jahren ganz viel gemacht… aber seit dem ich auch nicht mehr viel passiert… :frowning:

Gruß Miche

25

Update:

Aus den Anregungen und Code-Beispielen von miche101 und axelr ist was entstanden …

Eine grafische Übersicht der Reihenfolge der Platforms und Stops auf einer Karte, mit ausblendbaren Layers …

Beispiel: https://ptna.openstreetmap.de/relation.php?id=1773068&lang=de

Diese Analyse ist direkt aus der normalen PTNA-Analyse erreichbar (“PTNA”).

Die Analyse ist hauptsächlich für ÖPNV “route” Relationen gemacht, mag bei anderen Relationen auch irgendwie funktionieren.

  • Platforms (blau)
    ** PTv2: ‘role’ ist “platform” oder “platform_entry_only” oder “platform_exit_only” oder ‘public_transport’ = “platform”
    ** sonst: ‘role’ enthält ‘platform’

  • Stops (grün)
    ** PTv2: ‘role’ ist “stop” oder “stop_entry_only” oder “stop_exit_only” oder ‘public_transport’ = “stop_position”
    ** sonst: ‘role’ enthält ‘stop’

  • Ways (rot)
    ** PTv2: ‘role’ ist leer
    ** sonst: ‘role’ ist leer oder ‘role’ enthält “forward” oder “backward” (sofern es nicht ein “forward_stop” oder so ist)

  • Others (schwarz)
    ** alles andere (z.b.: Ways mit ‘role’ “Ende”)

Was fehlt (mir) noch?

  • Entweder kann man innerhalb von langen (Way-)Tabellen scrollen oder die Karte wandert beim Scrollen mit.
    ** Scrollbare Tabellen sind nicht einfach, wenn der Inhalt mittels JavaScript gefüllt wird, oder?
  • Bei Ways: am rechten Tabellenrand eine Anzeige, ob die Route Lücken hat - so wie im Relationseditor von JOSM auch.
    ** sofern die Geschwindigkeit des JavaScripts nicht massiv leidet.
  • Beim Fahren mit der Maus über Namen von Wegen, Platforms, Stops, … ein Hervorheben des Objektes auf der Karte?
  • Ein Fortschrittsbalken, denn bei langen/großen Relationen kann’s schon mal dauern …

Weitere Ideen, Anmerkungen?

Gruß
Toni

26

jetzt ist die Relation-Analyse dem GTFS fast gleich auf :wink: Jetzt wäre noch ein GPX download mit und ohne Shape noch fehlen… und die Möglichkeit des Routings

Eventuell könnte man bei der Relations-Analyse gefundenen Fehler auch in der Karte darstellen :confused: