PTNA - News: GTFS-Analyse

Hi… jetzt habt sich ein Fehler eingeschlichen :frowning: im GPx sind jetzt "" drin und “\n\r”

Doppelt maskiert :expressionless:

 var gpx_gesamt=`<?xml version=\\"1.0\\" encoding=\\"UTF-8\\" standalone=\\"no\\" ?>\\r\\n<gpx xmlns=\\"http://www.topografix.com/GPX/1/1\\" xmlns:xsi=\\"http://www.w3.org/2001/XMLSchema-instance\\" version=\\"1.1\\">\\r\\n <metadata>\\r\\n${metadata} </metadata>\\r\\n${wpt} <rte>\\r\\n${rte} </rte>\\r\\n</gpx>`;

Oops und sorry.

“Visual Studio Code” hatte vorgeschlagen einige String Definitionen zu vereinfachen

x = “<a href="” + url + “">label…”;

zu

x = `label…

nennt sich JS/TS - Template-String und dabei ist’s dann wohl passiert

Korrigiert und mit JOSM geprüft.

Gruß
Toni

Sehr gut :sunglasses:

Hi toni,

ich hab nochmal was… beim GPX Sonderzeichen “&” müsste noche gegen z.B. “&” ersetzt werden :confused:

z.B. hier:

<wpt lat="48.3124738370845" lon="11.913597309072"><name>23: Erding, Am Stadion (P&R-Platz)</name></wpt>

Danke, gefixed und auch für ‘<’ und ‘>’.

Kann ich auch Relationen ohne Wegverlauf erstellen? Weil so z.B. in Lk Freising da bring ich überhaupt keine “Körner” mit wie da gefahren wird :confused: Ja eigentlich beist es öfters aus :expressionless: , Route das alles und mache das nach “MIoO” => “Menschliche Intelligenz ohne Ortskenntnis” :wink: Eine Relation die so ist geht ja vielleicht noch aber wenn ich x-Varianten davon mache… könnte das ärgerlich werden für andere Mapper :confused: Wenn ja soll ich die speziell taggen?

Nach PTv2 eigentlich nicht (und das wäre dann ein Fehler in der Spec, da an der Realität vorbei), denn die Wege sind mandatory’ https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726 - zumindest für PTv2. Man kann ja immer noch als “PTv-garnichts” mappen.

Aber für Ruftaxis aber nicht anders möglich, da die keine konkrete Fahrstrecke haben http://localhost/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=37.T1.16-800-0-s20-5.21.R.

PTNA wird auch meckern “Route ohne Wege” (eher als Fehler als als Anmerkung, weiß nicht so genau), aber PTNA ist ja nicht “das Maß aller Dinge”.

Ja es muss ja nicht so bleiben… ich würde halt des ersten Schritt zur ptv2 Relation machen. Relation anlegen, Tagging in master Relation eintragen… und die Haltestellen Liste erstellen. Den letzten Schritt würde ich auslassen… das sollte lieber ein ortskundiger Mapper machen… Bevor ich in x Relationen eine Verbindung Mappe was nicht geht… :confused:

Hi,

passt hier schon das Tagging? Zwei mal Ruftaxi?

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=1.T0.18-540-3-s20-1.1.H

name 	Ruftaxi 5403 Ruftaxi: Dorfen, Bahnhof => Taufkirchen (Vils), Busbahnhof

PS: Magst du die ganze IDs da taggen, wenn man nicht mal weiss wie beständig die sind?

Mmh, muss da nochmals ran … Schritt für Schritt den Code verbessern …

Hier ist “5403 Ruftaxi” = gtfs:route_short_name → ‘ref’ in OSM
Und “Ruftaxi” selber ist der umgesetzte gtfs:route_type
name = gtfs:route_type + gtfs:route_short_name: + …

Eventuell das zweite Vorkommen von “Ruftaxi” löschen, wenn es vorne schon vorkommt.

Gute Frage, ich nehme an, dass “gtfs:route_id” recht stabil ist, zumindest 1 Jahr lang: “s20” könnte für “Saison 2020” stehen.

“gtfs:trip_id” könnnte genauso stabil sein, wenn denn der Trip (die Variante) das ganze Jahr angeboten wird.
Andernfalls muss ja auch in OSM nachgebessert werden.

“gtfs:trip_id:like” habe ich für eine DB-Abfrage genommen um die Abfahrzeiten von identischen Trips zu ermitteln.

Zusätzlich, wenn vorhanden, wird noch “gtfs:shape_id” ausgegeben - die ID der Fahrstrecke.

Ob man bei “ref_trips” die lange Version nimmt wie hier, oder den verkürzten Wert (wie bei gtfs:trip_id:like, ohne ‘%’) wäre Geschmackssache.

“gtfs:" oder "gtfs_” gibt es schon einige Male in Taginfo. Ich habe mich für ‘:’ als Trenner entscheiden, da ‘gtfs’ den Namensraum definiert, ähnlich wie bei access:, turn:

GTFS-spezifische Dinge zu denifieren könnte evtl. für Apps wie OsmAnd interessant sein.
Ich hatte auf der SotM in Heidelberg den Vortrag der OsmAnd-Enwickler gehört und anschließend mit einem der beiden gesprochen.
Deren Problem bei ÖPNV-Navigation ist derzeit, wie sie von einer OSM-Relations-ID (+ tags) auf die Trip-ID in GTFS kommen um weitere Informationen zu erhalten: Abfahrzeiten, an welchen Tagen, welche Uhrzeit. Das könnte man mit “gtfs:trip_id:like” unterstützen, sofern …

Sofern die Trip-IDs einem entsprechenden Muster folgen, was hier der Fall ist (meine Interpretation, reverse engineering):

1.T0.18-540-3-s20-1.1.H

  • 1 = 1. Fahrt am Tag
  • T0 = Auskunft über ‘service’-Zeiten, in welchem Zeitraum (Monate, …), an welchen Tagen, … entspricht wohl ‘service_id’ aus ‘calendar.txt’ und ‘calendar_dates.txt’
  • 18-540-3-s20-1 = route_id
  • 1 = 1. Variante von mehreren
  • H = Hinfahrt (R = Rückfahrt)

Dieses beim MVV sichtbare Schema scheint von der Software von “Mentz DV” zu kommen und kann bei vielen anderen GTFS-Analysen von PTNA gesehen werden. Eine entsprechende Unterstützung in PTNAs GTFS-Analyse kommt nach und nach, wenn ich die Dinge selber analysiert und verstanden habe.
Siehe auch letzte Zeile der Tabelle in: https://ptna.openstreetmap.de/en/gtfs-details.php?network=DE-BY-MVV#gtfs-osm-table

Gruß,
Toni

ja… aber wenn z.B. OSMand Gtfs verarbeiten kann… wofür dann noch die OSM-Relationen? Im Gtfs ist alles drin… was man für das Routing braucht… Vielleicht stimmt die Lage der Haltestellen nicht überein… oder es fehlt das Shape… oder das Haltestellen tagging ist mager… Aber die OSM-Relation nur noch zum Fixen der Haltestellen und als Shape Lieferant für das GTFS?

Aber Ideen, Vorstellungen gibt es viele viele… ich möchte jetzt auch mal was sehen was funktioniert. Das bisherige ÖPNV Routing in OSMand ohne GTFS ist ein wenig abenteuerlich. Wenn ich sehe das das funktioniert, baue ich auch Relationen dazu… :wink: Ich hab jetzt mal 3 Relationen ohne “Shape” gemacht… weil es mir auch a bisserl nervt mit JOSM wenn sich eine Route sich selbst kreuzt und Wege mehrfach benutzt werden. Da zickt der JOSM schon ganz schön rum und will das eigentlich nicht :rage: … viel zu aufwändig.

Man kann die Relation wunderbar “ver-Routen” und sich ein Shape erzeugen… wenn man braucht… :wink: Routing hat auch den schönen Vorteil man findet immer wieder Fehler im Tagging der OSM Daten :slight_smile:

Darauf läuft’s wohl hinaus und um den Renderern das Routing zu ersparen, wenn sie Buslinien auf die Karte ‘malen’ wollen.

Nicht ganz, u.U. nur dann wenn man weiß, wo der reale Bus lang fährt und das Routing eine andere Strecke vorschlägt, weil der Router z.B. “oneway:bus=no” nicht beherrscht (d.h. OSM-Daten korrekt) oder weil ein access=no dransteht (in den OSM-Daten aber das psv=yes bzw. bus=yes fehlt).

PTNA kann viele Fehler an Ways (construction, access, gegen “oneway”, …) finden, weil Mapper die Route vorgeben (mit Ortskenntnissen!?) und nicht ein Router um die Problemstellen herum navigiert. Und das Mapping kann natürlich auch falsch sein.

Beides hat Vorteile, beides hat Nachteile: beim Mappen, bei der QA, beim Rendern, … Das Konzept zur “Eier-legenden Woll-Milch-Sau” gibt es wohl nicht.

Die zweite Fehlermeldung ist eigentlich nicht richtig, weil die Stop-Positionen ist auf dem Weg :wink: nur der Weg fehlt komplett in der Relation… was ja auch festgestellt wurde. Also eigentlich kann man sich die Stop-Positionen Prüfung sparen wenn “Route ohne Way(s)” festgestellt wurde :slight_smile:

Korrigiert, morgen sichtbar. :slight_smile:

Korrigiert, dann auch “Ruftaxi” nicht mehr in ‘ref’.

Super, danke :sunglasses:

Hi Toni,
mir ist gerade was untergekommen… da war via=…;…;… getaggt aber im name=* war kein Via. Weiss nicht ob du das prüfen magst, aber wollte dir nur sagen was ich gefunden hab :wink:

Gruß Miche

Danke … da war für den umgekehrten Fall eine if-Abfrage aber kein ‘else if’ für diesen Fall.

Gruß
Toni

PTv2 verlangt, dass die stop_position auf einem für das Verkehrsmittel geeigneten Weg liegt. Ansonsten ist es ein Fehler. Wenn der Weg nicht in der Relation ist, dann ist das kein Fehler … es ist nur verdächtig falls andere Wege da sind. Da gibt es öfter mal Fehler bei zwei Tram-Ways “auf” einem highway.