PTNA - News: ÖPNV-Analyse

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:

Die GET-requests sind eigentlich nicht das Problem.

Den ersten (großen) GET request ans API von OSM mache ich tatsächlich asynchron. Der dauert meist so zw. 50 und 150msec und liefert fast alles was ich an Nodes, Ways und so weiter brauche - bis auf (Plattform-)Relationen.

Die weiteren kleineren GET-requests mache ich dann synchron, weil’s von der Programmablauflogik so am einfachsten ist.
Hierbei sind in der Regel Platform-Relationen nachzuladen (wenig Daten), das synchrone Laden ist nicht so kritisch.

Kritisch war die z.T. recht lange Analyse, d.h. das Abarbeiten der Member-Liste der route-Relation - nachdem die Daten schon da sind.
Diese Arbeit wurde in einer langen for-Schleife gemacht, bei der der Browser bzgl. dieses Fensters blockiert ist.

Durch das setTimeout( function(), 0, parameter-der-function ) erfolgt lediglich eine kurze Unterbrechung des JS-Programms (re-scheduling), so dass der Browser Mouse-, Keyboard-, und andere Events bearbeiten kann. Dadurch kann man den Browser im Fenster wieder bedienen (in die Karte rein-zoomen, …) während die Analyse weiter läuft.

Pro Timeout bearbeite ich mittlerweile 5 Member (nicht mehr nur einen), was insgesamt etwas schneller läuft, ohne die Bedienbarkeit des Browsers zu sehr zu stören. Das hatte ich auch mit 50, 20 und 10 Member versucht, aber das war beim Rein-Zoomen in die Karte dann nicht mehr flüssig.

Der Balken ist ein HTML5 feature “ x< %” und ‘x’ wird mittels JS aktualisiert.

Zusatz: der Balken funktioniert nur, wenn man asynchron (d.h. bei mir mit setTimeout) arbeitet.

ok… drum… is ja irre… klingt sehr kompliziert :confused:

Um präzise zu sein: - bis auf die Member der (Plattform-)Relationen.

Die brauche ich aber um sie zu zeichnen und um an eine lat/lon-Koordinate zu kommen (1. Node oder 1. Node vom 1. Way der Relation)

Schon irgendwie, spannend allemal bis es funktioniert. Man muss sich loslösen vom sequentiellen Abarbeiten des Codes …
Für die synchronen GET-requests ist mir auch gerade was eingefallen Richtung asynchron.

Wieder was interessantes gefunden: Hier darf der Bus gegen Einbahnstr. fahren :slight_smile:

Stimmt das tagging so:
https://www.openstreetmap.org/way/255282608

Korrekt, zumindest was PTNA angeht.

Update:

Drei neue Features sind fertig:

1. in den CSV-Daten kann nun ein Verweis auf die GTFS-Daten (von PTNA) hinterlegt werden:

210;bus;;Brunnthal, Zusestraße;Neuperlach Süd U S;Verkehrsbetrieb Ettenhuber GmbH;DE-BY-MVV;19-210-s20-1

Dazu wird der GTFS-Feed benannt (hier “DE-BY-MVV”) sowie die GTFS-route_id zu dieser Linie (hier “19-210-s20-1”).
Daraus wird ein Link “GTFS” auf die GTFS-Analyse von PTNA in der Titelzeile der Linie generiert.
Die Daten hierzu können mit dem Button “Download als CSV-Liste für PTNA” GTFS-Feed-spezifisch abgerufen werden (Beispiel für DE-BY-MVV).

2. “gtfs:" (und "gtfs_”) tags in den Relationen

diese werden in der Spalte “Anmerkungen” ausgegeben.

3. In der Spalte “Relation (id=)” wird ein Link auf die GTFS-Analyse von PTNA generiert wenn:

  • bei Route-Master als GTFS-Info “gtfs:route_id” abgegeben ist
  • bei Route als GTFS-Info “gtfs:trip_id” bzw. “gtfs:route_id” angegeben ist (in dieser Reihenfolge ausgewertet)

Als GTFS-Feed (Link zu den Daten) wird entweder “operator:guid” oder “network:guid” oder die Auswerteoption “–gtfs-feed=” hergenommen (in dieser Reihenfolge ausgewertet).

Die Punkte 2. und 3. sind derzeit erst für DE-BY-MVV und DE-BW-RFV freigeschaltet … die anderen kommen in Kürze

Gesteuert wird Punkt 2. durch die Option: “–show-gtfs”. Punkt 3. wird durch die Option: “–link-gtfs” ermöglicht.

Hinweis:

“route_id” und “trip_id” können sich von GTFS-Version zu GTFS-Version ändern. Beim MVV ändern sie sich definitiv im Dezember, mit dem Fahrplanwechsel.
Dabei ändern sich manchmal, aber nicht zwangsläufig auch die Routen der Busse, … (Ausschreibungen laufen beim MVV meist für 3 oder 5 Jahre).
In wie weit das Mappen von “route_id”, trip_id", “shape_id”, … in OSM sinnvoll ist? Entscheidet selbst, mir hat’s schon viel geholfen.

Ausblick:

Eine weitere Option “–check-gtfs” ist in Arbeit: sie wird prüfen ob

  • “gtfs:route_id” für Route-Master und alle Member-Routes identisch ist, ob
  • “gtfs:trip_id” unter allen Member-Routen eindeutig ist, ob
  • eine entsprechende Route-ID/Trip-ID in der GTFS-Analyse zum GTFS-Feed zu finden ist,
  • wenn eine Trip-ID in den GTFS-Daten gefunden wird kann geprüft werden,
    ** ob alle Haltestellen in der Relation enthalten sind,
    ** mit korrekten Name (was immer “korrekt” meint),
    ** in der richtigen Reihenfolge, …
    ** bis hin zu Auswertung evtl. vorhandener Shape-Daten gegenüber dem gemappten Fahrweg, …

Bei z.B.: Bus 561 finde ich es das es das ganze ganz schön aufbläht und unübersichtlich wird… man könnte vielleicht die Spaltenbreite erhöhen :confused: oder weg lassen…

'check_date' =
 '2020-05-04'
'gtfs:route_id' = '19-561-
s20-1'
'gtfs:trip_id' = 
'17.T0.19-561-s20-1.7.H'
'gtfs:trip_id:like' = 
'%19-561-s20-1.7.H'

Der Link zum GTFS find ich gut :slight_smile:

Stimmt, aber könnten wir das für eine Übergangszeit noch drin lassen (läßt sich durch wegnehmen von --show-gtfs leicht wieder entfernen)?

An den Spaltenbreiten möchte ich bewusst nicht drehen, da komme ich irgendwann in Teufels Küche und weiß nicht mehr wo, was, wie gedreht werden sollte.

Bei uns mit MVV wegen fehlender Shape-Daten nicht relevant, für DE-BW-RVF z.B. aber schon:

  • bei Route als GTFS-Info “gtfs:trip_id”, “gtfs:shape_id” bzw. “gtfs:route_id” angegeben ist (in dieser Reihenfolge ausgewertet)