In den meisten Fällen ist die Verbindung zweier Haltestellen eindeutig. In den mehrdeutigen Fällen kann der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell muss er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt (kann man den offiziell einsehen und übernehmen?) oder wenn die Strecke von der Verkehrslage oder dem Fahrzeug (Gelenkbus, Kleinbus, Taxi) abhängt.
Etwa einen via-Punkt pro unbekannter Haltestelle auf der Strecke setzen.
Der umgekehrte Falll ist häufiger. Man liest im Fahrplan den Ort der Haltestelle, weiß aber nicht, ob der Bus den kürzeren Weg über die Nebenstraße oder den längeren über die Hauptstraße nimmt.
Ich finde, diese Diskussion geht am Kernpunkt vorbei:
Das bisherige Datenmodell erfordert sehr viel Arbeit beim Erstellen der Relationen und (schlimmer) die Kontrolle und Anpassung aller Relationen bei Änderung der Straßentopologie. Straßen mit vielen Relationen sind dadurch kaum noch editierbar.
Weides Modell ist recht elegant, aber verlangt von jedem Mapper, der die Topologie einer Straße mit Buslinie verändert, das Verständnis der dreifach verschachtelten Relationen (Linie, Variante, Segment).
Ein wegloses Modell einfacher zu erzeugen und erlaubt Änderungen der Straßen ohne Berücksichtigung der Busrelationen. Dafür ist der Aufwand zum Erstellen von Linienkarten deutlich größer.
In den Innenstädten liegen die Haltestellen so dicht, dass es kaum zu Mehrdeutigkeiten kommt.
Bitte mache einen Test mit einem OSM-Router und lege nur die Haltestellen als Start-, Via- und Zielpunkt fest.
Bei meinem Test mittels OpenRouteService.org an der nächstgelegenen Linie ergab sich keine Abweichung im gesamten Verlauf.
Also ein Gegenvorschlag von mir: type=segment einführen (wie type=route, aber nur ein Teil davon), Vererbung durchziehen (falls nicht schon gegeben) und falls nötig die Definition des Rests an die tatsächliche Nutzung anpassen.
Neue kryptische Bezeichnungen für Dinge, die wir schon haben sind unnötig und die anderen 80% dieses Thread geht’s ja um was anderes (was genauso auf Wanderrouten anwendbar und dort genauso sinnvoll ist)…
Es ist und bleibt ein Unterschied ob es erlaubt (access), möglich oder praktikabel ist. Die Möglichkeiten lassen sich vielleicht noch aus den Tags für Breite usw. ablesen. die praktikabilität aber nicht. Gleiches gilt für Abbieger. Wenn eine Kreuzug hinreichend klein ist, wird dort wohl kein Gelenkbus mehr abbiegen können. Aber es wird dort von Behördenseite kein Verbotsschild aufgestellt. Vielmehr sind diese Sachen Bestandteil der Liniengenehmigung. Diese liegen uns jedoch nicht vor, so dass wir stattdessen die gefahrenen Wege erfassen.
Der Linienweg für Busse ist Besatndteil der Liniengenehmigung. Diese Unterlagen liegen bei der jeweiligen Genehmigungsbehörde vor. Ob diese Unterlagen für jedermann einsehbar sind weiß ich nicht, aber übernehmen darfst du diese mit großer Sicherheit nicht.
Das klingt fast nach einer guten Lösung. Hat aber einen bis zwei kleine Haken. Zum einen werden die Relationen nicht einfacher. Das ist aber im Gegensatz zum Vorschlag nur HST zu verwenden immer noch um Welten besser. Das zweite Problem von Weide finde ich jedoch gewichtiger. Heute werden alle Schemata mit type=route bezechnet. Wie aber kann man die teils grundlegend verschiedenen Varianten in der Auswertung unterscheiden?
Interressant wird doch die Sache an zwei Punkten. Erstens wenn die Haltestelle auf einem Stichweg liegt. Sprich wie verhält sich der Router wenn es günstiger ist, auf der Stelle zu wenden um zur nächsten Haltestelle zu kommen, aber dies nicht möglich ist. Und zweitens lassen sich Viapunkte viel einfacher/unauffälliger löschen als ganze Wege. Zum Beispiel beim vereinfachen von Weggeometrien können Zwischenpunkte automatisch entfernt werden.
Reizvoll wäre das Thema aber auch jeden Fall, da ja keine Wege mehr gesplitet werden müssen.
Nein, den kann man nicht einsehen, ist aber das, was normalerweise genutzt wird. Also ganz klassisch “wie früher” durch Beobachtung erfassbar. Ausserdem gibt es dank der Rückbauten der DB Netz unter Beachtung von Fahrstrassenausschlüssen, Richtlinien u.Ä. (also Dingen, die Software nicht wissen kann, weil wir sie nicht erfassen (und btw wäre es aufwändiger und bräuchte mehr Relationen)) oft nur einen sinnvollen Fahrweg.
Das alte Schema (alles in einer Relation) einerseits und Oxomoa / das akzeptierte Public Transport Proposal andererseits lassen sich gut unterscheiden.
Nach dem alten Schema erfasste Relationen haben keine Eltern-Relation. Sie haben auch keine Rollen platform und stop für Haltestellen, stattdessen gibt es die Rollen stop_## mit fortlaufenden Nummern ggfs. ergänzt um forward_ / backward_.
Relationen nach dem Oxomoa-Schema und Public Transport Proposal wären im Prinzip am Typ der Eltern-Relationen und den verwendeten Rollen zu unterscheiden. Was jedoch vorkommt, sind unvollständig auf das Public Transport Proposal umgestellte Relationen. Letzteres erschwert das algorythmische Erkennen erheblich.
(Ich hatte seinerzeit vorgeschlagen, die Art des Schema als Tagg zu erfassen. Das erhielt jedoch keine Zustimmung.)
ich möchte nur noch mal daran erinnern, dass es auch mindestens eine Anwendung gibt, bei der die Reihenfolge der Haltestellen alleine nicht ausreicht, sondern auch die (feste!) Route inkl. Varianten erfasst sein muss:
Es gibt Buslinien, die - meist abends ab einer bestimmten Uhrzeit - auf Anfrage an jedem Punkt der Route anhalten, sofern das von den Verkehrsregeln her möglich ist. Wenn ich also auf einer solchen Linie aussteigen will, muss ich sehr genau wissen, was ich dem Fahrer als Haltepunkt mitteilen muss. Anders ausgedrückt: Ich muss die Strecken zwischen den Haltestellen genau kennen. Nur dann kann ich dem Fahrer mitteilen: “Lassen Sie mich bitte an der Abc-Straße, Hausnr. 123 aussteigen”.
Dafür reicht es meiner Meinung nach nicht, eine ungefähre Route mittels via-Punkten ermitteln zu lassen. Hauptsächlich deshalb, weil Änderungen in der Umgebung der Strecke Auswirkungen haben können. Die Eröffnung einer neuen Straße z.B., die die Verbindung zwischen zwei via-Punkten verkürzt, die der Bus aber trotzdem nicht entlang fährt: Eine automatische Routenberechnung würde das nicht bemerken. Und was noch wichtiger ist: Die Mapper, die die neue Straße einpflegen und die Mapper, die sich um die via-Punkte kümmern, würden in der Regel voneinander gar nichts mitbekommen. Der Mapper der neuen Straße merkt nicht, dass er eine Abkürzung zu einer ÖPNV-Route geschaffen hat, wenn die neue Straße nicht zufällig einen via-Punkt berührt.
Es kommt selten vor, dass eine neue Straße die Wege zwischen zwei Haltestellen verkürzt. Wahrscheinlich wird dann die Linienführung geändert oder es werden Haltestellen verlegt. Eine Kontrolle der Buslinien ist immer ratsam. Falls der geschilderte Fall tatsächlich irgendwo vorkommt, würde es im weglosen Modell genügen während der Bauphase der neuen Straße einen via-Punkt auf die alte Strecke zu legen.
Wir diskutieren hier seltsame, pathologische Fälle, aber nicht, woran die Erfassung der Linien bislang gescheitert ist.
Warum erfassen bislang so wenige Mapper Buslinien? Ist der Nutzen unklar, das Datenschema unverständlich, die Editorunterstützung zu schlecht oder die Arbeit beim Erstellen zu viel?
Kann ein durchschnittlicher Mapper eine Straße editieren (z.B. eine Fahrbahnteilung einfügen) ohne die Buslinie zu beschädigen?
Was wollen und was können wir realistisch erreichen und pflegen? Die Hauptvariante jeder Linie, einige Nebenvarianten oder alle Varianten? Nur die Strecken, auch Betriebszeiten und Fahrthäufigkeit oder sogar Abfahrtszeiten?
Wie können zukünftig verfügbare, freie Fahrplandaten in OSM integriert oder verknüpft werden?
Ein Datenschema, dass alle denkbaren Fälle abdeckt, aber von der Mehrheit der Mapper nicht umsetzbar ist, nützt niemandem. Keep it simple!
Zum ersten Punkt:
Den Routingalgorithmus wird man so einstellen, dass er das Wenden nicht erlaubt oder sehr teuer macht.
Um sicher zu sein, kann der Mapper einen via-Punkt in die Wendeschleife setzen.
Im schlimmsten Fall wäre die Wendeschleife in der ÖPNV-Karte nicht angemalt und die berechnete Linienlänge um diese Strecke zu kurz.
Zum zweiten Punkt:
Der Einwand trifft auf alle Punktobjekte in OSM zu. Bei einer Relation ist zumindest die Historie einsehbar, ein gelöschter POI ist praktisch unauffindbar.
Ich hoffe aber, kein Editor optimiert Punkte weg, die Teil einer Relation sind.
Das Modell wäre vor allem reizvoll, weil es weniger (stupide) Arbeit für den Mapper bedeutet und damit hoffentlich mehr Linien erfasst werden.
Die Tags network=, ref=, from=* und to=* sowie via=* sollten für eine Verknüpfung in fast allen Fällen ausreichen. Für die anderen Fälle kann man eine Sonderlösung finden wenn es soweit ist.
Eine Integration der Fahrplandaten in OSM halte ich für nicht sinnvoll, solange es keine speziellen Datentypen dafür gibt und dies nicht von den VU genutzt und entsprechend gepflegt wird (was dann btw auch z.B. Leerfahrten umfassen würde).
Kommt drauf an, was ein “durchschnittlicher Mapper” ist. Es ist auf jeden Fall genauso z.B. für Rad- und Wanderrouten gültig.
Wenn ich mir hier das Verhältnis erfasste Buslinien/erfasste Hausnummern/Hydranten/maxspeed/Neubaugebiete/whatever ansehe: Wir brauchen allgemein mehr Mapper. Die Buslinien sind bei der Liste übrigens hier das vollständigste (was nicht nur an mir liegt).
Warum erfassen so wenige Mapper Buslinien? Das ist eine gute Frage. Aber wahrscheinlich ist es einfach anders als die Straße abfahren und dann eintragen. man müsste wahrscheinlich sogar mit dem Bus fahren um zu wissen wo lang dieser fährt.
Jeder Josmbenutzer kann Straßen teilen ohne dabei irgendwelche Relationen zu beschädigen. Der Editor ist inzwischen so schlau auch die Rollen forward Backward an die drehung der Wegrichtung anzupassen.
Einzig gegen das verinigen von Wegen ist man damit nicht gewappnet. Also auch diese Ausrede mag ich nicht gelten lassen.
Aber was unterscheidet eine Straße Hausnummer oder Hydrant von einer Buslinien? Eine Straße ist ein kurzes Stück Weg eine Hausnummer oder ähnliche POI sind Punkte oder räumlich eng begrenzte Objekte.
Buslinien hingegen können durch den ganze Ort oder gar Landkreise führen. Hierfür sind nicht nur einzelne Punkte(Haltestellen) notwendig sondern eine ganze Menge. Auch wenn ich ÖPNV interessiert bin, so kenne ich nach einem Jahr noch nicht alle Buslinien die hier im Umkreis von einem Kilometer fahren, geschweige denn das ich deren Verlauf kennen würde um sie in OSM eintragen zu können. Mit Fernwanderouten und -radwegen ist das wahrscheinlich ähnlich. Und was bringen Teile von Routen?
Wie oft hast du bereits ein Routing für Buslinien durchgeführt? Du schreibst das du es einmal für deine Buslinie gemacht hast! Ich mache das etwa alle drei Monate, aber dann für ganze Landkreise. Und ich kann dir sagen, dass es immer wieder zu Abweichungen und Ungreiomtheiten kommt. Das liegt zum einen daran, dass die Accessregeln eben nur gesetzt werden wenn es explizit untersagt ist(ist ja auch richtig so) und zum anderen das uns eben nur die Haltestellen vorliegen und nicht der kürzeste Weg der richtige Weg ist. Insbesondere in ländlichen Räumen.
Was ist denn die stupide Arbeit beim erfassen von ÖPNV Routen? Das man hier außer Punkten auch noch Wege in die Relation aufnehmen soll? Macht es das wirklich stupider?
ja, das stimmt schon, wenigstens bei städtischen Linien (nicht Fernbusse). JOSM unterstützt die richtige Reihenfolge der ways auch sehr gut.
Ich hab letztens die Stadtbahnlinien in H auf das neue Schema umgestellt. Da fand ich die richtige Reihenfolge der stop_posotions und platforms extrem ätzend herzustellen (vgl wambachers post #18). Und das, wo die stop_positions auf der route ja aufgereiht sind wie eine Perlenkette.
Ich kann hier (wie jeder) nur für mich sprechen:
Der Nutzen ist teilweise klar, aber in diesem Umfang?
Ich denke die meisten von Euch habe eines von diesen Smartphones - die ÖffiApp (ein Kollege hat sie mir gezeigt - übrigens der einzige Grund mir so ein Smartdingens zuzulegen) kennen und nutzen alle?
Datenschema? OSM ist nur ein Teil meines Lebens…
Daher kümmere ich mich daher auch nicht um Editorunterstützungen (fehlende Einarbeitungsfreizeit)…
Ich hoffe, dass ich bisher nicht unabsichtlich Schaden angerichtet habe. Wenn, habe ich es nicht überschaut und nicht gewollt!
Ähh, was ist mit der Farbe der Abfahrtstafel…
Wenn überhaupt, bitte verknüpfen.
Je mehr Details wir anfangen zu erfassen (aus was für Gründen (ich unterstelle hier teilweise narzisstische) auch immer), desto instabiler wird OSM.
Stoße ich als “durchschnittlicher” Mapper auf komplexe Strukturen, mit denen ich mich befassen will (begrenzte Freizeit), werde ich aus Rücksicht auf den evtl. Nutzen diese und die damit verknüpften Fehler bestehen lassen und mich kopfschüttelnd abwenden.
Die Welt ist aber nicht simpel! Man muss also entweder abstriche an der einen oder anderen Seite machen. Die Frage zu wievielen Kompromissen man bereit ist kann jeder bei OSM selber treffen.
Siehe Gebäude. Manche wollen nur die Dachfläche. Die nächsten wolen die Hausnummern und wieder andere wollen neben Höhe auch noch Farbe und Dachform. Eine Karte sieht bereits schön aus wenn man die Fläche erfasst. navigieren kann man nur mit Hausnummern. Richtig schick sieht es aber erst in 3D aus oder?
Beim ÖPNV ist es ähnlich. Manche erfassen die Haltestellen weil sie daran vorbei kommen. Andere Erfassen alle Wege die von einer Linie befahren werden. Dann sehen sie schick aus auf einer Karte. Richtig auswerten kann man sie aber est wenn die Reihenfolge stimmt und die Haltestellen enthalten sind.
Das war sie vorher auch nicht. Im Public Transport Proposal steht m.E., dass name der Haltestellenname ist und ref sich ebenfalls darauf bezieht. Nur deshalb steht da, dass man sie weglassen darf, wenn es eine stop_area gibt und das stop_areas optional sind. Irgendwie ist aber ins Wiki geraten, dass name den Bahnsteig enthalten soll und ref die Bahnsteignummer und man eine stop area haben muss. Ich halte das für Unfug, den man aber jetzt ohne Edit-Wars aum noch korrigieren kann.
Die Bedeutung von Rollen und Reihenfolgen einer Relation kann man nur festlegen, wenn man einen neuen Typ definiert. Bei type=route gibt es auch unsortierte Relationen, die mit “forward” und “backward” eine monodirektionale Nutzung angeben und mit der leeren Rolle eine bidirektionale Nutzung. Mit dem Public Transport Proposal haben wir jetzt eine Relationsart, die ebenfalls type=route hat, aber mit der leeren Rolle ganz im Gegensatz zum bisherigen eine monodirektionale Nutzung des Weges angibt, “forward” und “backward” nicht kennt, bei der das alte “stop” in “stop” und “platform” unterteilt wurde, so dass ein klassisch richtiges “stop” bei PTP ein falsches “stop” sein kann.
Ich wollte in dem Vorschlag nicht viel mehr erreichen als in den PTP-Relationen auch drin steckte. Aber es steckte in den PTP-Relationen so drin, dass zusammen mit den nach wie vor sinnvollen klassischen Routen eine ziemliche Verwirrung über de Interpretation ausbrach, weil nur wenige die beiden Routenarten überhaupt als verschieden wahrgenommen haben.
Ich sags mal so: Ich bin ein Anhänger der PTP-Routen; man konnte sehr klar schreiben. Nur wurde beim Lesen vieles unklar, weil zuviele Leute die klassischen und die PTP-Routen nicht unterscheiden konnten
Die stop_area wurde in meinem Vorschlag nicht ersetzt oder gestrichen. Sie existiert völlig unverändert nach wie vor. Man ist nur nicht mehr auf sie angewiesen, um z.B. eine Haltestellenliste zu bekommen. Sie war im PTP optional und daran sollte sich nichts ändern. Bei größeren Haltestellen finde ich sie durchaus sinnvoll.
Am Prinzip “Eine Relation je Linienvariante” ändert sich durch die Segmente absolut nichts.
Die dort genannten Daten werden einfach included (Halte zu Halten, Fahrwege zu Fahrwegen). Segmente müssen nicht interpretiert werden, da sie (außer den Vollständigkeitsangaben) gar keine Eigenschaften haben. Alles passiert nach dem Einfügen. Das ist technisch extrem einfach.
Ich habe allerdings auch etwas Bedenken, das manche das Segmentieren zum Selbstzweck machen und nicht auf die Fälle beschränken, wo Segmente zur Übersichtlichkeit beitragen…
Abgelöst werden nur route- und route_master-Relationen. Und es soll keine schlagartige Ablösung geben.
Hinzugefügt werden Tags, die mit “pt2_” anfangen.
public_transport wird ergänzt um den neuen Wert “any_platform”. Der ist fast völlig identisch mit dem vorhandenen Wert “platform”. Der Wert “platform” besagt bei einem Node leider, dass da in der Realität nichts ist – da ist die Bedeutung leider anders als bei Linien oder Flächen. Der neue Wert “any_platform” sagt einfach nichts über die Ausführung der platform und kann deshalb auch benutzt werden, wenn man nur die Info “da ist ne Haltestelle” hat.
stop_position gibt es nach wie vor – sie werden nur nicht mehr in den neuen Routen erwähnt.
Der Normalfall ist aber die halbfertige Route. Da sieht man jetzt die Löcher in der Fahrstrecke und kann sich ausmalen, ob da auf irgendeinem langen Stück nicht noch Halte fehlen oder ob die erfasste Route nicht Hinweise auf fehlende Haltestellen liefert.
Abends und Nachts ist es darüber hinaus bei immer mehr Verkehrsbetrieben inzwischen auch offiziell möglich, den Fahrer um einen außerplanmäßigen Halt (nur auf der planmäßigen Fahrstrecke) zu bitten.
