PTNA - News: ÖPNV-Analyse

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.

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

Wie hier …

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

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

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

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

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:

…obwohl der Radschluss wäre geschafft wenn man aus den OSM Daten einen GTFS Feed generieren kann :slight_smile: …aber wir nähern uns…

bei GPX… wäre wpt <= OSM platform(wenn nicht vorhanden, sollte nicht sein :wink: dann stop_position), rte-Teil <= OSM stop_position, bzw. wenn nicht vorhanden Platform. Prüfen anhand des name=* :wink:

… über diese Dinge kann man reden :slight_smile:

Im Moment bin ich gerade fertig geworden einen / zwei Fortschrittsbalken zu realisieren und den Code so umzustellen, dass der Browser nicht blockiert, wenn’s mal etwas länger dauert.

Jedes Member wird durch eine Funktion analysiert, die durch einen setTimeout( handleMember, 0 /* msec Pause */, ++index ) am Ende einer solchen Analyse für das nächste Member gestartet wird.

Dadurch bleibt der Browser offen für Mouse-, Keyboard-, … und andere Events. Viel langsamer wird’s dadurch insgesamt nicht, aber “bedienbar” :smiley:

S 1 in München geht noch recht flott

ICE von Hamburg über Berlin nach München dauert mit 1315 Ways schon recht lange, aber der Browser und das Map-Fenster können noch bedient werden und man kann der Liste der Ways beim Wachsen zusehen :wink:

Aber, wie schon einmal geschrieben: für große Relationen braucht man Geduld, bei kleineren merkt man kaum eine Verzögerung.

…a ja des Problem kenn ich das muss man asynchron laden :slight_smile:

aus:

request.open( "GET", url, false );

wird:

request.open( "GET", url, true );

In der Funktion wird dann geregelt… was passiert wenn sich er Status änder…

request.onreadystatechange = function() {

bzw. was passiert wenn es fertig geladen ist:

if ( request.status === 200 ) {

:slight_smile: Der Balken ist gut :sunglasses: