In dem Text wird nicht erwähnt, was mit den ‘highway=bus_stop’-Nodes passiert. Werden auch in die Relation aufgenommen oder ist dieser Tag veraltet?
Erhalten die Relations-Member, die den eigentlichen Weg darstellen, eine besondere Rolle? Ansonsten die der platform? Wie kann man ansonsten unterscheiden, welches der Weg und welches der Bussteig ist?
Ist ‘highway=platform’ veraltet und soll nun durch ‘public_transport=platform’ ersetzt werden?
Oft gibt es ja Haltestellen, bei denen keine separate Haltebucht, geschweige den einen speziellen Bussteig gibt. Der Bus hält einfach am Straßenrand. Soll man jetzt eine ‘public_transport=platform’ künstlich anlegen? Node oder Way?
es ist verwirrend weil es Plattform kann ein richtiger Steig aber auch eine stinknormale Haltestelle sein. Den Highway node kannste einfach drin lassen, müsste niht weiter stören.
Ich habe bis jetzt keine besonderen Rollen dem Member zugewiesen.
Highway=bus_stop wird ersetzt durch public_transport=stop_position oder public_transport=platform, je nachdem wo der Node lag.
Meines Wissens sind keine Rollen für die Relationsmitglieder vorgesehen, die Strecke lässt sich von Haltestellen durch die Tags unterscheiden, außerdem sollen ja die Wege, die die Strecke bilden, in geordneter Reihenfolge in der Relation enthalten sein.
Highway=platform ist offensichtlich veraltet und sollte ersetzt werden, wenn eine Route nach neuem Schema eingetragen wird.
Würde ich so machen, dass es der Realität am Nähesten kommt: Wenn der Bus wirklich nur am Straßenrand hält, dann ein Node, der das Bushaltestellenschild repräsentiert. Gibt es einen erkennbaren Ansatz einer Platform (z.B. einen erhöhten Bordstein), kann man auch einen Way verwenden.
Die Halte bleiben wie sie sind. Ich habe irgendwo eine Stelle gefunden, nach der dies als Übergang vorgesehen ist. Sie erhalten die Rolle “forward_platform” (neben der Straße) oder “forward_stop” (auf der Straße). Wenn beides vorhanden ist, dann kommt beides rein. Das “forward_” ist deshalb mit drin, weil die Relation zwar nur eine Variante einer Richtung angibt, man dies aber nicht so ohne Weiteres an den Tags erkennen kann – es könnte ja auch eine klassisch getagte Buslinie sein. Bezüglich dieser Variante sind natürlich alle Stops “forward”.
Aus demselben Grunde bekommen die Straßenabschnitte die Role “forward” bzw. “backward”, je nachdem, ob sie in OSM-Richtung oder gegen OSM-Richtung befahren werden. Das gibt dann im Grunde genommen nur die im JOSM sichtbaren Pfeilrichtungen wieder und wäre überflüssig, wenn man der Relation die Absicht des Mappers ansehen könnte. Alle Relationen der Buslinie werden dann in einer Superrelation zusammengefasst. Alle Einzelrelationen erhalten ein Tag der Art"note:relations=part of bus line 111 (Relation 11111)". Da fiel mir nichts Besseres ein, aber irgendwie muss man ja deutlich machen, dass dies nur ein Teil der gesamten Buslinie ist und aus den Tags kann man es ja wie gesagt nicht schließen.
Alle Buslinien, die ich in Dortmund getroffen habe, sind als Relationen
nach dem neuen ÖPNV-Schema erfasst. Da steht keine einzige Rolle drin.
Es ist ja eines der Ziele dieses Schemas je Relation nur eine Richtung
zusammenzufassen. Von daher sind alle Wege und alle Haltestellen immer
in Fahrtrichtung.
Die Richtung eines Weges hat in einer Relation meiner Meinung nach
nichts verloren, da die Wegrichtung geändert werden kann, ohne dass
diese Änderung in der Rolle entsprechend angepasst würde.
Edit:
In die Fahrtrichtungs-Relation kommt nur die stop_position rein.
Die Haltestelle (=Zugang zum Bus) liegt ja ausserhalb der Fahrtroute.
Übrigens gibt es einen schweren Fehler in der Definition der Haltestellen-
und Richtungs-Relationen. Es wurde kein Reationstyp dafür definiert.
Lediglich für die zusammenfassende Relation ist type=route festgeschrieben.
type=* ist aber ein für Relationen zwingend vorgeschriebene Parameter.
Also sollte das ‘neue’ ÖPNV-Schema (zumindest bezüglich Relationstyp)
mal dringend überarbeitet werden.
Die Sache mit den einzelnen Relationen je Fahrtrichtung und Alternative
hat noch eine andere unangenehme Auswirkung: Kreisverkehre müssen
leider in mehre Stücke aufgedrösselt werden, da die Rückrichtung ja in
einer anderen Relation erfasst wird.
Ja. Alle diese von mir benutzten Rollen sind redundant und überflüssig, sobald man davon ausgeht, dass es das neue ÖPNV-Schema ist. Um davon ausgehen zu können, müsste man aber eine eindeutige Typ-Kennzeichnung haben(s.u.). Als OSM-Objekt ist die Linienvariante des neuen Schemas eine Buslinie des alten Schemas. Das ist ein Konstruktionsfehler des neuen Schemas. Da man nun kompatibel mit dem alten Schema taggen muss, bedeutet eine leere Role, dass ein Stück Weges in beiden Richtungen benutzt wird und das ist in der Linienvariante praktisch nie der Fall. Also braucht man dort aufgrund des Konstruktionsfehlers praktisch überall Roles.
Das muss der Editor hinbekommen. Genauso muss er auch beim Splitten eines Weges diesen richtig in die Relation einbauen.
In http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema steht:
"Für Hin- und Rückweg einer Linie wird jeweils eine eigene Relation verwendet: Dabei werden alle Haltepositionen, Zugangsstellen und Verkehrswege als Mitglieder aufgenommen. Deren Reihenfolge in der geordneten Mitgliederliste gibt dabei genau die reale Verbindung zwischen Quell- und Zielort wieder.
Zugangsstellen werden aus den folgenden beiden Gründen mitaufgenommen: Zum einen ermöglicht dies Routinganwendungen FußgängerInnen direkt auf die richtigen Zugangsstellen zu verweisen. Zum anderen sichert dies die Abwärtskompatibilität des Modells, da somit auch all jene Map Features nach wie vor gültige Relationsmitglieder sind, die als Halte getaggt sind, sich aber neben Verkehrswegen befinden und nicht auf solchen."
Das Wort “type” kommt im gesamten Oxomoa-Dokument nicht vor. Warum daraus im Wiki “type=route” für die Metarelation geworden ist, ist mir unklar.
Wie ich dazu gekommen bin, fällt mir nicht mehr ein, aber ich habe es mir definitiv nicht ausgedacht, dass ich die Metarelation mit “type=line” tagge.
Ja! Und nicht nur das neue ÖPNV-Schema. Hätte man der neuen Art von Multipolygonen von Anfang an einen anderen Typ verpasst (“type=area”), dann wären uns massenweise Probleme erspart worden. Und hätte die Linienvariante einen eigenen Typ statt des gewohnten “type=route”,“route=bus”, dann wären alle Roles überflüssig, da sie sich dann klar aus dem Kontext ergeben würden.(s.o.)
Ja, das sollte man vielleicht tun – andererseits sollte man auch den Kreisverkehr als ganzes reinnehmen können, ohne dass Programme die Wegabfolge dann als nicht mehr zusammenhängend kennzeichnen … JOSM macht das z.B. richtig.
Könnte man so sehen, halte ich aber für unnötig und wird (zumindest in
Dortmund) nicht so gehandhabt.
Was die mehrdeutige Klassifizierung mit type=route angeht muss ich dir
allerdings zustimmen: Das ist ein Mangel des neuen Schemas.
Das mit dem Splitten (und auch Joinen) klappt bei JOSM.
Ob die Rolle forward/backward eines Relationsmitgliedes allerdings
automatisch mitgedreht wird, da habe ich meine Zweifel.
(forward/backword als Tagg an einen Weg funktioniert in JOSM)
Sorry, du hast Recht.
Ich hatte das nicht sorgfältig genug kontrolliert.
(Wird in Dortmund wie von dir zitiert angewendet.)
Ich wollte wie ajoessen “Starkstrom-Freileitungs-Relation” einwerfen.
Aber wenn type=line für die Sammel-Relation in Ordnung ist, werde ich diese
entsprechend anpassen. Bleibt nur die Frage welchen Typ die Richtungs-Relationen
bekommen sollen. type=route fände ich durchaus passend aber führt zu
Fehlinterpretationen altes/neues ÖPNV-Schema.
Da kann ich dir nur zustimmen.
type=area statt type=multipolygon hätte uns viele hitzige Diskussionen erspart.
Für die Linienvarianten ginge eigentlich type=route. Es ist ja im Grunde eine Route.
Nur die Member-Rollen wären im alten/neuen ÖPNV-Schema leider unterschiedlich.
Zusammenlassen natürlich. Sonst hätte man sich den Konstrukt roundabout ja gleich sparen können. Fürs Routing muss der Kreisverkehr eben wie ein Knoten (bzw der “kleine Kreisverkehr”) behandelt werden:
“Nehmen sie die dritte Ausfahrt” funktioniert nicht mehr, wenn alles zerstückelt ist.
Die Kreisverkehre dafür wieder mit Relationen zusammenbauen zu müssen, ist mir irgendwie zu blöd.
Ja, das muss ich einschränken: Beim Splitten und Umdrehen hatte ich schon mal Probleme. Seit ich da aber vorher das Gebiet um die zu ändernden Objekte explizit lade, geht es. Ob es wichtig ist, die Relation vorher komplett geladen zu haben, kann ich nicht sagen, denn das mache ich sowieso immer.
Danke für die Informationen.
Dann habe ich es ja weitgehend sinnvoll gemacht.
Bleibt noch die Frage der Haltestellen-Relationen:
Bisher habe ich mangels besserer Alternativen type=site dafür verwendet.
Im Aachener Dokument wird dafür type=public_transport +
public_transport=stop_area vorgeschlagen.
Das habe ich so auch schon mehrfach in Dortmund gesehen.
(Das habe ich dann natürlich nicht geändert.)
Ist das gängige Praxis, so dass ich das in Zukunft verwenden kann?
wir sind in dieser Diskussion auf ein paar Probleme mit Datenstrukturen in OSM gestoßen, die sich auch an ganz anderen Stellen in OSM zeigen. Ich habe da die Idee, dass man mit Hilfe von Normen Dinge klarer machen kann, ohne die Freiheit der Mapper irgendwie einzuschränken. Ich mache dazu mal einen getrennten Thread “Normdiskussion” auf.
Es könnte woanders andere gleich gute oder bessere Lösungen geben.
Daher frage ich lieber nach.
Wenn keine Einwände mehr kommen, werde ich die Verwendung von
type=line (Sammelrelation),
type=route (eine Richtung) und
type=public_transport (Haltestellen)
für das neue ÖPNV-Schema durch ausgiebige Anwendung pushen.
Das sollte noch auf den entsprechenden Seiten ergänzt werden.
Wir (bzw. Martin ganz alleine) haben das in Dortmund durchgeführt, als das ÖPNV-Schema noch ganz neu war.
Es mag also durchaus sein, dass es in anderen Kommunen Probleme gibt, über die sich hier niemand Gedanken machen musste.
Notfalls mal beim öpnvkarten.de-Macher anfragen, der wird vermutlich die Beste Übersicht haben
Konkret ging es natürlich um die Situation in Dortmund.
Von daher reicht mir das erst mal aus.
Genau wie in Dortmund werde ich mir in anderen Städten erst einmal
ansehen wie die Dinge vor Ort gehandhabt werden und nur die Dinge
ändern, in denen ich eine Verbesserung oder Fehlerbehebung sehe.
Doch, es bestehen Einwaende.
Lt. zwei native speakern ist line im englischen keine Entsprechung der deutschen Linie (Sammlung von Routen). Kam vielleicht daher, dass beim damaligen workshop nur vertreter mit muttersprache Deutsch anwesend waren?
Warum man jetzt die bushaltestellen wieder in einer extra relation verpackt, versteh’ich auch nicht.
Den groessten Gewinn haette man, wenn mensch Abfahrtszeiten haette. …
(ohne den Fahrplan abzutippen {was bei unseren fraenkischen VGN sogar erlaubt waere})
