Das heißt nach dem letzten Proposal type=route und type=route_master
Also hier kann ich keine Vereinfachung erkennen.
Das jetzt keine Stoppositionen erfasst werden müssen/sollen ist soweit in Ordnung. Aber das verhindert eben bei S-Bahnen auch das man angeben kann wo welcher Zug gewöhnlich hält. Da dies aber bei der Stopposition auch nicht genau geregelt war ist es sicher verzichtbar.
Die Stoparea hat jedoch andere Funktionen. Sie soll Masten zusammenfassen, auch wenn diese unterschiedliche Namen haben. Hier wird eine Art Hirachie geschaffen, die man nicht aufgeben sollte. Beim Oxomoa schema gab es dafür mehrere Abstufungen. Als stoparea und stopareagroup. Dei Bedeutung hat sich aber nicht jedem erschlossen.
Was ich hier sehe sind die Möglichkeit Segmente zu integrieren. Das macht es nicht gerade einfacher in der Auswertung/Rendering als auch ist es nicht intuitive warum das so und dort wieder anders steht. Eine Relation je Linienvariante ist nicht nur das einfachste, sondern es ist sämtlichen mir bekannten ÖV-Verwaltungssystemen gängige Praxis. Auch die Dateiaustauchformate wie HAFS, Infopool oder GTFS kennen das nicht anders.
Ist dem wirklich so? Welche Auswerter machen das denn? Beim Rendering spielt es keine Rolle welcher der befahrenen Wege wo steht. Daher kannst du das in keiner Karte wirklich sehen. Die Haltestellen zu sortieren ist vor allem beim mehrfach anfahren kein leichtes unterfangen. Aber als Datenbankprofi fällt dir da vielleicht etwas besseres ein als die bereits vorgegebene Reihenfolge.
Ich dachte das war unteranderem ein Grund warum die Member jetzt in der API mit einer bestimmten Reihenfolge ausgegeben werden.
Nicht mehr auf Anhieb: ja. Geht aber in wenigen Schritten auch mit dem jetzigen JOSM-Relationseditor: Relation kopieren, sortieren und schon sind alle Wege hintereinander. Kopie kann nach Überprüfung weggeworfen werden.
Vom Informationsgehalt her würde ich die Haltestellen zwischen den Ways bevorzugen. Die Version Haltestellen zuerst lässt sich automatisch mit geringem Aufwand erzeugen, umgekehrt geht es nicht. Beim Rendern sieht man den Informationsverlust nicht, da Ways und Haltestellen simpel auf Grund der Koordinaten eingetragen werden. Beim Übergang zu Relationen mit type=pt2 lässt sich das doch wieder so einführen. Die meist (aber nicht immer) genutzte Version Haltestellen zuerst könnte im Relationstyp route (bis zum Aussterben in vielleicht 20 Jahren) so bleiben.
Die Segmente hätte ich sehr gerne als eigenständiges Objekt optional drin. Es gibt Linienbereiche (meist in Nähe Zentralbusbahnhof), in denen ein Dutzend Linien denselben Straßenzug nutzen. Wenn dann dort Umbauten erfolgen, muss man das wenigstens nur an einer Stelle ändern. Redundanz sollte man da vermeiden, wo das mit vernünftigem Aufwand möglich ist.
Generell ist mir nach erstem Durchlesen (mehr darf man von den meisten Nutzern nicht erwarten) nicht gleich klar geworden, wo das alte Proposal abgelöst werden soll und wo es weiter gelten soll.
Was soll z.B. aus den (wenig realisierten) public_transport=stop_position werden?
Aber es soll ja wohl auch nur eine erste Diskussionsgrundlage sein.
Kann der in talk-de erwähnte JOSM-Preset zum Ausprobieren (nicht Hochladen) zur Verfügung gestellt werden? Ich hätte da einige Gemeinheiten im Auge wie Achter-Kurs mit gemeinsamer Strecke, aber Halt nur in einer Richtung.
Was ich noch hilfreich fände, wenn man die Haltestellenart besser kennzeichnen könnte: Bussteig mit Fahrbahn auf beiden Seiten, vom Fußweg abgesetzte Haltestellen (oft auch mit Haltebucht) oder simples Haltestellenschild auf Gehweg oder am Straßenrand. Der Ansatz des Proposals ließe das m.E. ja zu. Der platform-Value ist mir da zu ungenau bis irreführend.
Auch die Ways müssen selbstverständlich sortiert sein! Hier gibt es einige Buslinien, bei denen man sonst nicht ermitteln könnte, in welcher Richtung sie zwischendrin ein Stück Kreis fahren.
Hier biegen die Überlandlinien bisweilen von der Hauptstraße ab, drehen eine Runde und kommen am gleichen Punkt wieder auf die Hauptstraße zurück. Ohne Reihenfolge der ways ist der Weg nicht mehr zu ermitteln. Das gleiche Problem hat man, wenn der Bus nach einer Schleife seine eigene Route kreuzt.
Das Sortieren und Erfassen der Route und der Haltestellen wird mittlerweile vom JOSM Relationseditor und dem public_transport Plugin recht gut unterstützt.
Ich würde generell ein Datenmodell bevorzugen, bei dem nur die Haltestellen, aber nicht die verbindenden Wege Teil der Relation sind.
Das entspricht dem Fahrplan der ÖPNV-Anbieter, die auch nicht angeben, über welche Straßen/Weichen/Wasserwege die Verbindung läuft.
Falls doch einmal die Angabe der Fahrstrecke erwünscht ist, könnte man Via-punkte ins Modell aufnehmen.
Vorteile:
weniger Arbeit beim Erstellen und Bearbeiten
keine Konflikte beim Bearbeiten des Straßennetzes
keine Verschachtelung in Segmente nötig
weniger Aufwand für Fußgängerrouting durch einfaches Datenmodell
keine widersprüchlichen/unterbrochenen Relationen möglich
Nachteile:
Kartendarstellung des Linienverlaufs benötigt einen Routingalgorithmus
Ich traue dem Frieden nicht so ganz. Denn wenn jetzt jemand die Haltestelle löscht ist auch die Information das er daran vorbeikommt weg. Im Zweifel findet der Router ganz andere Wege. Ich sehe das bei größeren ÖPNV Modellen immer wieder, das eine Kurzwegsuche von Haltestelle zu Haltestelle zwar einfach ist, aber das Problem nicht wirklich löst. Über welche Straßen darf denn der Bus? Über welche nicht? Dürfen vielleicht auch nur Linientaxis über die Anwohnerstraße, während die anderen die Bundeststraße fahren. Also du würdest damit viele Informationen einfach aufgeben. Auch Dinge wo wendet ein Bus etc. Von mir also dafür auf jeden Fall ein klares nicht besser!
Vor Löschungen ist fast kein Datum in OSM geschützt. Ich sehe eher einen Vorteil für das weglose Modell: wenn im bestehenden Modell eine Haltestelle aus einer Relation gelöscht wird, fällt es in der Linienkarte kaum auf, während eine neue Route ins Auge springt und schnell korrigiert werden kann.
Wo ein Bus/Linientaxi fahren darf, ist durch die access-Tags (speziell “psv”) festgelegt.
Mancher Bus nimmt je nach Verkehrslage verschiedene Strecken, das Anruf-Linien-Taxi wendet an anderer Stelle als der Bus und lässt ohne Anforderung manche Umwege aus, der Zug fährt über verschiedene Weichen in den Bahnhof und die Fähre nimmt je nach Wasserstand und Wind unterschiedliche Kurse. Wenn wir eine Variante als Strecke definieren, schaffen wir in vielen Fällen nur eine Pseudoinformation.
Falls der Verlauf wichtig ist, kann man durch einen via-Punkt die Strecke festlegen.
Bei Buslinien gibt es (zumindest teilweise) offizielle Fahrtwege, die auch meist eingehalten werden und Züge haben (zumindest in Deutschland) einen Regelweg und ein paar Alternativwege für Störungen, aber wir wollen ja den Normalfall erfassen. ALT sind eh eher wie kostenloses Taxi und zu Fähren kenne ich nicht.
Wie wollte ihr das eigentlich ohne Fahrtweg machen, wenn der Fahrtweg bekannt ist, die Positionen der Haltestellen aber nicht?
Zum ursprünglichen Vorschlag: Ist da nennenswert etwas anders als es momentan genutzt wird? Also ausser den kryptischen neuen Bezeichnungen (und den jetzt hinzugekommenen Segmenten)?
Nein! Ein Accesstag regelt immer nur offizielle Verbote. Es gibt in keinem Fall an wo der Bus am besten durchkommt. Ist es die Erste oder die Zweite Querstraße? Oder ist gar ein Umweg über die Hauptstraße nötig etc. Busse fahren außer auf tertiary auch noch auf residentials und in Busspuren bevorzugt auf services. Da kannst du das PKW routing gleich mal ganz neu entwickeln.
+1, ich sehe das prinzipiell als deutlich besseres Konzept an. Die Reihenfolge, in der Haltestellen angefahren werden, ist aus meiner Sicht ohnehin die entscheidende Information - der genaue Fahrtverlauf ist für den Fahrgast nur in den seltenen Fällen wirklich interessant, wo an beliebigen Stellen ein Stopp angefordert werden kann. Und in der Regel dürfte, ggf. mit sehr wenigen “via”-Punkten, auch der Fahrtverlauf eindeutig abzubilden sein.
Als Bonus wird gleich noch getestet, ob das routingrelevante Tagging zwischen den Haltestellen stimmt.
Es gibt schon ein Routing-Plugin in JOSM. Das ist zwar momentan ziemlich … ähm, minimalistisch, aber vielleicht lässt es sich mit GraphHopper-Code oder etwas Fleißarbeit aufpeppen? Man könnte also durchaus im Editor eine Vorschau für die berechnete Strecke umsetzen, das ist kein fundamentales Problem.
Gehen wir mal davon aus, dass es im Editor noch klappen würde. Aber beim Rendern? Wenn das alles kein Problem ist warum braucht man dann für jeden zweck eigene Datenstrukturen? Auch Abfragen über die Overpassapi scheitern, wenn der Konkrette Linienverlauf und die beteiligten Wege gefragt sind. Wenn dann noch auf die Stopstellen verzichtet wird, wird es auch schwerer das Lot auf die befahrene Strecke zu fällen. Denn es sind jetzt Punkte neben der eigentlichen Strecke verbunden. Also mich als Anwender der Daten kann das noch gar nicht überzeugen.
Ich verstehe nicht, worauf sich dieser Satz bezieht. Wofür braucht man eigene Datenstrukturen?
Ja, die Overpass API hat das nicht im Funktionsumfang, sondern man bräuchte dann eine der Routing-APIs (wobei bisher leider keine davon ein Bus-Profil hat :/). Die Overpass API ist aber doch auch nicht mit dem Zweck angetreten, für alles das richtige Werkzeug zu sein?
Auch der Einwand mit dem Lot ist prinzipiell schon richtig - du würdest dann nicht das Lot auf die befahrene Strecke fällen, sondern auf die umliegenden Straßen, was natürlich mehr Kandidaten ergibt und damit etwas komplizierter, aber vermutlich doch machbar ist.
Oh, und ich persönlich bin übrigens nicht unbedingt gegen das Konzept der Stoppstellen. Ich würde es nur klar optional machen, weil in 90+ % der Fälle die Lage sowieso eindeutig ist.
Anwender überzeugen im Sinne von “das macht es für mich einfacher” wird der Vorschlag sicher nicht. Denn es läuft darauf hinaus, die OSM-Daten übersichtlicher zu machen (nicht nur für ÖPNV-Mapper, sondern auch für die, die einfach nur die von Bussen befahrenen Straßen bearbeiten wollen) und dafür Auswertern, die Fahrtverläufe zeichnen wollen, mehr Arbeit aufzubürden.
Ob das funktionieren könnte, hängt nicht zuletzt davon ab, ob zumindest einige der Auswerter darin einen Sinn sehen und zu so einem Schritt freiwillig bereit sind.
http://overpass-api.de/public_transport.html
Scheint mir doch sehr auf ÖPNV abzuzielen. Die ersten Dinge ließen sich sicher auch aus Haltestellen generieren. Aber ganz unten kann man sich auch die Linienverlauf ansehen. Das würde dann so scheitern, oder?
Weiteres Problem: andere Mapper sehen 2 benachbarte ways mit identischen Tags u identischen Relation-Zugehoerigkeiten und machen daraus einen way. Schwer, Nicht-Öffi-Mapper davon abzuhalten.
Das Konzept “Öffi-Relationen ohne Linien, nur mit Haltestellen” finde ich auch nicht schlecht, zB im Blick auf die neuen Fernbuslinien mit zig Hundert members und wechselndem Fahrtverlauf in Städten (so meine Beobachtung in CE).
In anderen Ländern kann es aber genau andersrum sein: Buslinien in Argentinien werden so gut wie immer ohne Haltestellen gemappt. Das hat den Grund, dass in den zugänglichen ÖPNV-Infos immer nur die befahrenen Straßen angegeben sind (Beispiel), die Haltestellen keine Namen haben und die Busse in so regelmäßigen Abständen halten (meist alle 4 Blocks), dass das auch ausreicht.
will sagen: das herkömmliche Mapping-Konzept muss auf jeden Fall(auch) beibehalten werden. Also 2 Konzepte parallel?!?
Ein Routingalgorithmus kann nie funktionieren, da oft nicht klar ist, welche Straßen benutzt werden vom Bus. Beispielsweise fährt der Bus bei uns eine Schleife im Ort, obwohl er auch direkt fahren könnte. Niemand von uns weiß, warum er das tut. Die Straßen würden es zulassen und manche Busfahrer tun es auch. OK, man könnte die Fahrer mal fragen…
Aber ein Routenplaner kann das definitiv nicht wissen.
Ich schließe mich den Meinungen an, dass das punktmässige Erfassen eher schlecht ist. Wenn man weiß wie ein Bus fährt, sollte man auch explizit die Route taggen und sich nicht auf irgendwelche Software verlassen, die schon irgendwie den richtigen Weg finden wird. Gerade die Anzahl der nötigen via-Punkte hängt von der verwendeten Software ab.
Zu dem eigentlichen Vorschlag schließe ich mich rayquazas Meinung an. IMO muss man nur das bestehende Schema um Segmente und Minivars erweitern. Die completeness Tags würde ich nicht verwenden. Diese Information kann man variabler in fixme=* oder note=* ablegen. Der Tag public_transport=any_platform kann auch entfallen, wenn man für die Platform auch Nodes zulässt. Wenn man mehr Informationen zu einer Haltestelle hat, kann man das mit zugehörigen Tags explizit angeben (bench=yes/no, bin=yes/no, shelter=yes/no).
Bei den Namen der Haltestelle würde ich pt2_lookup weg lassen, da eine vernünftige Suche das aus groupname extrahieren kann. Irgendwie finde ich auch die Bezeichnungen subname und groupname nicht sprechend genug. Mir fällt aber gerade nichts besseres ein
Bei der Master Relation frage ich mich, wieso mit vehicle das Fahrzeug getaggt werden soll und nicht wie vorher bus=yes, train=yes etc.
Bei den neuen Relations habe ich jetzt noch nicht wirklich verstanden, was ein minivar ist. In welchen Fällen soll man den nutzen?
Durch konsequente Anwendung der Segmente ließe sich auf jeden Fall die Anzahl der Busrouten für ein Straßenabschnitt deutlich reduzieren. Ich würde dann noch dafür plädieren die Segmente in anderen ÖPNV-Linien zu verwenden. Also wenn Bus 1 und 2 für eine gewisse Zeit dieselbe Strecke befahren, kann man für beide dasselbe Segment verwenden.
