ÖPNV Vorentwurf (zurückgezogen)

Das stimmt. Wenn es bei leicht versetzten Haltestellen mehrere stop_position-Punkte gibt, müsstest du sogar mehrmals splitten. Andererseits ist der Split eines Wegs kein Weltuntergang.
Es gäbe bei diesem Modell aber auch andere Probleme, z. B. dass man in den Relationseditoren nicht mehr auf Anhieb sieht, ob die Strecke vollständig erfasst ist; an jeder Haltestelle gibt es einen Sprung. Man müsste dann die Relationseditoren so ändern, dass sie die Haltestellenelemente quasi ignorieren bei ihrer Auswertung, ob ein lückenloser Linienzug besteht. Von Änderungen bei den Auswertungsprogrammen ganz abgesehen.

Das war auch nicht als ernsthafter Vorschlag gedacht, sondern eher als wehmütiger Rückblick. :slight_smile: Die Trennung von Haltestellen und Wegstücken in den Routenrelationen ist seit langem etabliert. Das lässt sich auf der sozialen Seite bestimmt nicht mehr ändern, selbst wenn es technisch sinnvoller wäre (was auch erst einmal zu beweisen wäre).

@MetiorErgoSum: Danke, das hatte ich irgendwie nicht ganz überrissen.

Ja. Bis zu den Tests hatte ich einfaches “include” für Minivars und Segmente. Es war aber scheußlich unübersichtlich, weil dann wegen der richtigen Reihenfolge der Haltetellen Halte und Wege wieder kreuz und quer verteilt werden müssen. Es gefällt mir auch nicht, dieselbe Relation zweimal zu erwähnen, aber es sieht dann hinterher ganz übersichtlich aus.

Weide

Gerade die Einfachheit des Vorschlags von Weide gefällt mir so außerordentlich. Das Relationengetümmel im alten Proposal ist genau das, was es dem nicht so erfahrenen Mapper schwer macht, die Übersicht zu halten. Nach dem neuen Proposal sehen die Relationsbezüge für ein funktionierendes Mapping einer Standard-Buslinie ohne Varianten so aus:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant.
Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master.

Das war es auch schon, was für ein erstes Funktionieren einer Buslinie zwingend notwendig ist. Es ist so einfach, dass dies nahezu jeder leisten kann, der eine Grundverständnis einer Relation hat. Selbst wenn es Varianten gibt, wird hier der Mapper ohne Informatikhintergrund in die Lage versetzt, zumindest eine Hauptvariante einer Buslinie anzugeben. Hat er dies erst einmal gemacht, ist dann auch ein abweichender Fahrweg als weitere Variante nicht mehr so schwer. Bei dem Modell ist es zudem nicht mehr notwendig, pro Halt eine Plattform und eine Stoppstelle zu definieren - die Plattform reicht. So kann diese von jedem Mapper verschoben werden, ohne dass dabei vergessen wird, die Stoppstelle auch zu verschieben oder umgekehrt.

Das Weide-Schema entspricht dann auch dem, was der einfache Bürger intuitiv auch als Haltestelle wahrnimmt. Im Allgemeinen wird eine Haltestelle in der Wirklichkeit durch das Schild am Mast symbolisiert. Auch wenn ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der Bus hält dann einigermaßen lotrecht dazu auf der Straße. Genau das bildet das neue Modell 1:1 ab.

Sofern eine Anwendung eine Stoppstelle benötigt, läßt sich diese leicht durch Lötfällen auf die Route automatisch ermitteln, wie der OSM Inspector zeigt:
http://tools.geofabrik.de/osmi/?view=addresses&lon=6.94298&lat=51.16239&zoom=18&opacity=1.00&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

Zudem ist die stop_area, die bisher zum Ermitteln des Haltestellennamens notwendig war, nicht mehr zwingend erforderlich. Sie kann optional beim Zusammenfassen bei Umsteigepunkten noch angewendet werden. Die Buslinie funktioniert aber jetzt auch ohne diese - eine weitere deutliche Entblähung.

Dass das Modell etwas komplizierter werden muss, wenn Varianten gemappt werden, liegt in der Natur der Sache. Aber auch hier schafft das Weide-Schema verglichen mit dem alten, mehr Möglichkeiten bei weniger Komplexität. Obendrein beseitigt es immense Redundanzen (mit entsprechenden Fehlermöglichkeiten durch Abweichen eigentlich gleichzulautender Einträge) und ist konsistenter sowie eindeutiger.

Dass ich mich bei dieser Beurteilung zunächst auf Buslinien beschränke, hat seinen Grund. Denn sie sind es, die bis in den letzten Winkel der Republik fahren und daher von möglichst jedem Mapper mit Relationskenntnissen verstanden werden sollten. Für die Bahnen, die meist nur in größeren Städten oder überregional verkehren, sollten zumindest in den deutschsprachigen Ländern genug Mapper mit fortgeschrittenen Mappingkenntnissen existieren. Aber auch diese werden nach dem Modell von Weide einfacher. Zudem ändern sich Gleisverläufe nicht so einfach wie Busrouten.

Dennoch ein Wort zu den Straßenbahnen. Dort gibt es zumeist etablierte Bedarfsumleitungen. Diese lassen sich - einmal anläßlich einer solchen Nutzung gemappt - aus, ein- und umgliedern.

Je weiter ich mich in das Weide-Schema vertiefe, um so mehr tritt die Genialität zu Tage - verglichen mit allem Anderen, was wir bisher auf OSM im ÖPNV Bereich hatten.

Hi, bei der ganzen ÖPVN-Geschichte hat mich eines seit Jahren am meisten gestört:

Warum müssen die Haltestellen eigentlich in aufsteigender Reihenfolge in der Relation aufgeführt werden?

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen. Das sollte für die Haltestellen genau so möglich sein - schließlich liegen sie neben (oder auf?) der Strecke und diese ist “sortiert”.

Das nervt mich aus drei Gründen:

  • ich muß bei Änderungen der Haltestellen - ab und an kommt schon mal eine hinzu - pingelig drauf achten, diese an der richtigen Stelle einzufügen.

  • Ein Sortieren der Member in Josm ist nicht so einfach möglich. Man muß erst den Abschnitt mit den Strecke selektieren und äußerst vorsichtig dabei sein. Hat man erst einmal die Haltestellen “versortet” ist der Mist nicht mehr zu retten. (es sei denn man cancelt)
    Daß das Sortieren der Member einer Route durchaus “Lebensqualität” bringt, sollte wohl klar sein.

  • aus Prinzip, da sowas in einen System mit Geometrie-Bezug nicht notwendig sein sollte.

Meine Konsequenzen daraus: Ich mappe seit 2011 (?) keine Buslinien mehr.

Ansonsten finde ich diese Aktion aber als höchst positiv, da dadurch viele -aber nicht alle- Hindernisse aus dem Weg geräumt werden.

Gruß
Walter

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
  • keine einfache Überprüfung der Korrektheit

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. :wink:

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.