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… 
Hi,
passt hier schon das Tagging? Zwei mal Ruftaxi?
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… 
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 
… viel zu aufwändig.
Man kann die Relation wunderbar “ver-Routen” und sich ein Shape erzeugen… wenn man braucht… Routing hat auch den schönen Vorteil man findet immer wieder Fehler im Tagging der OSM Daten 
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 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
Korrigiert, morgen sichtbar.
Korrigiert, dann auch “Ruftaxi” nicht mehr in ‘ref’.
Super, danke 
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 
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.
Ich halte jedes Routing der ÖPV-Verkehrsmittel für schädlich:
Wenn eine Brücke wegen irgendwelcher Probleme gesperrt wird und ein Mapper das einträgt, dann ist das völlig in Ordnung. Wenn ein Kartenprogramm dann irgendwelche Phantasierouten für Busse produziert, dann ist das nicht die Schuld des Mappers sondern der Kartensoftware. Ich werde mir solche Karten jedenfalls nicht ansehen. Was wir in so einem Fall brauchen, ist eine Fehlermeldung für die Route. Dann kann jemand ermitteln, wie der Bus jetzt wirklich fährt … welche Haltestellen ausgelassen werden … welche Ersatzhaltestellen eingeplant wurden … welche anderen Routen angepasst wurden um den Bedarf zu decken.
Alles klar.
- Wenn es keine Ways in der Relation gibt, dann muss nicht auch noch gemeldet werden, dass eine stop_position nicht auf den Ways liegt - das ist zwangsläufig so.
- Wenn es mindestens einen Way in der Relation gibt, so wird gemeldet, wenn eine stop_position nicht auf einem der Ways liegt.
Den letzten Halbsatz nach … :
- die Ways sollen eine durchgehende und sortierte Strecke bilden, ohne Lücken
- der erste Way muss mit einer stop_position beginnen, das muss die erste stop_position der Relation sein
- der letzte Way muss mit einer stop_position enden, das muss die letzte stop_position der Relation sein
→ das wird momentan geprüft.
→ die Reihenfolge der stop_position in der Relation vergleichen mit der Reihenfolge, wenn man den Ways folgt: passt nicht immer, vor allem dann nicht, wenn es Schleifen gibt (Haltestelle mit selben Namen in beiden Richtungen,…).
Der letzte Satz: verstehe ich nicht ganz.
Gruß
Toni
Ich auch, d.h. die automatisierte Berechnung einer Route an Hand der Haltestellen um daraus eine Karte zu machen.
Das geht aber nicht ohne eine “Vorgabe”: d.h. ein Mapper macht eine PTv2-Relation und gibt an, wie die Route zu dem Zeitpunkt ist.
Eine Fehlermeldung beim Bau einer Brücke, … (sofern in OSM auch gemapped) meldet PTNA derzeit, weil highway=construction oder access=no (ohne psv=yes) sind.
Eine Abweichende Routenführung eines Busses (mit Auslassen von Haltestellen) wegen Baustellen (kurz-, mittel- oder langfristig?) bekommen wir mit, wenn Mapper “am Ball bleiben” und den Verkehrsverbund “beobachten” (Pressemeldungen, Webseite des Verbundes, …) - theoretisch (*).
GTFS mit oder ohne shapes bietet zumindest ansatzweise eine Möglichkeit OSM mit (halbwegs) aktuellen Daten der Verbünde zu vergleichen.
Die GTFS-Analysen bei PTNA sind (für mich) eine Vorbereitung dahin gehend, dass PTNA selber die Daten benutzt um sie bei der Analyse mit den OSM-Daten zu vergleichen.
Wie das optimal geht, wie weit das gehen kann, was man “rauskitzeln” kann? Ich weiß es noch nicht … ist aber spannend.
“Was soll der ganze Aufwand?” Mmh, solange Ptv2 und das ältere noch Bestand haben und kein neueres PTv-irgenwas kommt oder ÖPNV komplett aus OSM verschwindet ist es doch OK an sowas zu arbeiten.
Toni
(*) “In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon!” (Autor unbekannt)
Ja. Aber die stop_position muss auf einem zu den “xxx=yes”-Angaben geeigneten Way liegen … egal ob der Weg in der Relation ist oder nicht. Natürlich gibt es keine Pflicht, dass zu melden.
Ja. Das ist zwar kein Fehler (Routen dürfen ja unvollständig sein) aber eine interessante Sache.
Hmm. Wie alle anderen Haltestellen darf die erste und die letzte Haltestelle als “nur platform” oder “nur stop” oder “beides” eingetragen werden. Bei “nur Platform” ist da kein “stop” und das ist völlig OK.
Hatte ich auch schlecht formuliert. Bei Gleisen ist ja normalerweise jede Spur ein eigener Way und bei Straßen sind die Spuren in einem Way. Dadurch haben wir oft direkt nebeneinander drei Ways: einen für die Straße in der Mitte und Straßenbahngleise auf beiden Seiten direkt daneben. Der Stop der Straßenbahn (falls vorhanden) muss auf dem Gleis liegen und der Stop des Busses (falls vorhanden) auf der Straße. Beim Splitten der Wege in Straße und Gleise ist oft vergessen worden, auch die “Stops” zu splitten.
Interessant, die Prüfung ist noch nicht drin. Ein Bus kann nicht über Trambahngleise (ohne weiteres highway=) fahren und dort seine Haltestelle haben. Ein bus’ braucht ein ‘highway=’ > path|footway|cycleway|… (es sei denn, es steht psv|bus=yes dran), eine ‘tram’ braucht ein ‘railway=tram’
“Dürfen”, ja, sollten aber nicht, denn sonst sind sie irgendwie nutzlos. Aber: wie beurteile ich bei einer sw-technischen Prüfung, ob sie vollständig sind, alle Haltestellen hat, …?
Auch wieder wahr. Ideal wäre beides, aber wenn nur ‘platform’ dann müsste man suchen, ob das Ende / der Anfang der Fahrstrecke “recht nah” bei der letzten / ersten ‘platform’ liegt. “recht nah” == “< 20 Meter”?
IIRC, bei einer neueren Diskussion über “stop_position ist generell unnötig” wurde bzgl. 1. und letzte stop_position eine Ausnahme gemacht, was wiederum nicht konsequent zu “komplett ohne stop_position” ist - irgendwie braucht’s man dann doch mal wieder?
Verstanden, sehen wir oft in München, wo die Gleise in der Fahrbahn liegen, in OSM aber als zwei railway=tram rechts und links neben dem highway= liegen.
Das wird in PTNA erkannt, sofern bei einer Tram sowohl das “railway=” als auch die “Tram-stops auf dem railway=” in der Relation sind, für den Bus analog. Fehler würde man gemäß 1. Punkt oben heraus finden, ‘tram’ auf ‘highway=’ ohne ‘railway=’ und tram-stop auch auf highway.
ich finde die stop-position praktisch, wenn man z.B. Routing betreibt. Weil da kann es sein das die Platform einer anderen Straße näher steht, als der in der der Bus fährt… dann kann die stop-position die lat/lon der Platform für Routing ersetzen…
Z.B.
wenn man stop-position die lat/lon ersetzt würde es so ausfallen
Na ja. Es kann auch die Haltestelle fehlen und der Weg drin sein oder umgekehrt. Oder jemand mappt die Haltestelle und traut sich nicht an die Relationen. Oder ist mit dem Bus gefahren und hat Haltestellen übersehen.
Beides zu mappen finde ich garnicht ideal. Viele mit einem einzelnen Node für beide Richtungen gut gemappte Haltestellen werden jetzt zu vier Objekten plus einer zusammenfassenden stop_area-Relation ohne dem Informationsgehalt irgendwas hinzuzufügen. Das war damals ein Kompromiss, der die “bus_stop auf die Straße” - und die “bus_stop neben der Straße” - Fraktionen von weiteren Edit-Wars abhalten sollte: “Wenn da schon einer den bus_stop an die für Dich falsche Stelle gemacht hat, dann kannst Du jetzt mit public_transport=xxx das andere Ding auch noch hinzufügen und es kommt dann gleichberechtigt in die Route”.
Aber da geht man doch von der Vorstellung immer vollständiger Routen aus. Es gibt bestimmt noch viele Länder, in denen man ganz klassisch ein Stück mit dem Bus fährt und Haltestellen markiert und notiert und diese Teile dann in OSM einträgt. Oder man kommt per Rad oder zufuß an einer Haltestelle vorbei und trägt sie in die Routen ein ohne die Fahrstrecke des Busses gesehen zu haben.
Ja, genau: das sollte das Ziel sein: vollständige Routen mappen.
Warum nicht darauf hinweisen, dass eventuell eine nicht vollständige Route vorliegt?