Unterschiedliche Geschwindigkeiten, Straßenschilder je Straßenseite

Halte ich nix von. Das ganze ist mit den derzeitig vorhandenen Werkzeugen nicht vernünftig zu handeln.

Und auch für die Zukunft halte ich da wenig von. Die selben Nodes nehmen geht schonmal nicht weil es sind ja 2 unterschieldliche Wege die aneinader grenzen. Im prinzip hast du hier das gleiche Problem wie bei den Strassenbgleiteden Radwegen.

Ich würde hier eher in Richtung realtionen Arbeiten. Mit 3 Membern (node from, node to, eigentlicher weg) ist das ausreichend beschrieben.

mpeter89 wrote:

gibt es eine Möglichkeit für jede Straßenseite (Fahrtrichtung) einer Straße unterschiedliche Maximalgeschwindigkeiten, Straßenschilder (z.B. STOP) etc. einzutragen?

forward/:backward-Anhängsel␣an␣den␣Tags?␣Spart␣einen␣Way␣und␣eine␣Relation␣gegenüber␣deinem␣Vorschlag.␣Die␣meisten␣Eigenschaften␣werden␣sowieso␣für␣beide␣Richtungen␣gelten.

- Bei Kreuzungen kann man einfach klar machen, ob das Abbiegen nach rechts/ links für diese Fahrtrichtung ist
- Beschreibung von Vorfahrtsregeln
[...]
- möglich wäre so die Beschreibung von Straßenstücken, auf denen das Überholen erlaubt/ verboten (durchgezogene Mittellinie) ist.

Welche Möglichkeit, diese Dinge auszudrücken, gewinnt man denn jeweils durch die Zerlegung in zwei Ways? Ich sehe hier keine Erleichterung, aber vielleicht übersehe ich ja etwas.

- Hausnummern der Straßenseite zuordnen

Das (Relationsmitgliedschaften) ist wohl das einzige, was durch Fahrtrichtungs-Ways erleichtert würde. Allerdings erschließt sich mir der Zweck einer solchen Zuordung von Hausnummern nicht ganz; schließlich ist sie implizit auch bereits durch die Lage des Hauses gegeben.

- allgemein wäre das Routing einfacher und man könnte besser Verkehrsregeln abbilden

Ich sehe keine Vereinfachung des Routings. Dass man manche Way-Segmente in zwei gerichtete Kanten zerlegen muss, ist definitiv kein Problem für jemanden, der mit Turn Restrictions, Spurabbildungen und sonstigen Herausforderungen des OSM-Datenmodells zurechtkommen würde.

Islanit wrote:

Halte ich nix von. Das ganze ist mit den derzeitig vorhandenen Werkzeugen nicht vernünftig zu handeln.

Aber daran sollte die Weiterentwicklung eines Modelles nicht scheitern. Das OSM-Modell entwickelt sich auch weiter und wird verfeinert.
Wenn mehrere Mapper so anfangen würden zu mappen, würden vermutlich auch zeitnah die Editoren angepasst werden.

Islanit wrote:

Die selben Nodes nehmen geht schonmal nicht weil es sind ja 2 unterschieldliche Wege die aneinader grenzen.

Warum nicht. Wenn die Ways auf den selben Nodes liegen, dann nimmt man an, dass die Wege direkt aneinander grenzen. Ansonsten würde man sowieso 2 verschiedene Ways einzeichnen.
Die Ways würde man dann in einer Relation/ in die Straßenrelation zusammenfassen. Dort könnte ggf. man vermerken, wie die Grenze aussieht.

Islanit wrote:

Im prinzip hast du hier das gleiche Problem wie bei den Strassenbgleiteden Radwegen.

Stimmt schon. Aber wenn man ehrlich ist: So richtig zufriedenstellend ist die Lösung nicht!? Manchmal entfernt sich der Radweg um einige Meter von der eigentlichen Fahrbahn und es kommt auch vor, dass Rad- und Fußwege mal sich langsam ganz von der Straße entfernen.
Sowohl für die Darstellung als auch für das Routing macht das große Probleme.
Elegant wäre es, auch für die Rad- und Fußwege eigene Ways einzuzeichnen, die dann u.U. auch auf den Straßennodes verlaufen können. So könnte man auch pro Straßenseite Fuß- und Gehweg separat darstellen.
Allerdings würde ich dieses Problem erstmal vielen anderen unterordnen.
Für Straßen sehe ich aus eigenen Erfahrungen durchaus einen Bedarf für separate Ways.

Tordanik wrote:

forward/:backward-Anhängsel␣an␣den␣Tags?␣Spart␣einen␣Way␣und␣eine␣Relation␣gegenüber␣deinem␣Vorschlag.␣Die␣meisten␣Eigenschaften␣werden␣sowieso␣für␣beide␣Richtungen␣gelten.

Wäre eine Notlösung. Gefällt mir aber nicht wirklich. Was ist, wenn jemand ausversehen (denkt sich nichts dabei) die Way-Richtung umkehrt? Dann wären alle Angaben falsch.

Tordanik wrote:

mpeter89 wrote:

- Bei Kreuzungen kann man einfach klar machen, ob das Abbiegen nach rechts/ links für diese Fahrtrichtung ist
- Beschreibung von Vorfahrtsregeln
[...]
- möglich wäre so die Beschreibung von Straßenstücken, auf denen das Überholen erlaubt/ verboten (durchgezogene Mittellinie) ist.

Welche Möglichkeit, diese Dinge auszudrücken, gewinnt man denn jeweils durch die Zerlegung in zwei Ways? Ich sehe hier keine Erleichterung, aber vielleicht übersehe ich ja etwas.

Man könnte z.B. das Vorfahrtsstraßenschild auf diesen Way setzten und es der Relation der Kreuzung zuordnen. Hiermit würde man viele Fliegen mit eine klappe Schlagen: Stopschilder, Vorfahrtsschilder, aber auch Ortseingangsschilder.
Somit könnte man das Schild selber mit Position darstellen, den Inhalt eindeutig deuten und das pro Fahrtrichtung.

Wenn man 2 Ways hat, es aber nur von einer Fahrtrichtung in der Realität erlaubt ist, rechts abzubiegen, dann würde man nur diesen Way damit verknüpfen. Routing-Services hätten es so auch einfacher.

Zum Thema überholen:
Da könnte ich einen Way einen Tag zuordnen: Überholen=yes/no - unabhängig von der anderen Fahrtrichtung.

Tordanik wrote:

[Allerdings erschließt sich mir der Zweck einer solchen Zuordung von Hausnummern nicht ganz; schließlich ist sie implizit auch bereits durch die Lage des Hauses gegeben.

Wenn Hausenummern noch nicht richtig eingetragen sind, sondern nur auf die Straße interpoliert werden, dann würde es schon Sinn machen.
So könnte man rechte und linke Seite separat interpolieren und das Navi wüsste dann auch, ob rechts oder links das gewünschte Ziel wäre.

Tordanik wrote:

Ich sehe keine Vereinfachung des Routings. Dass man manche Way-Segmente in zwei gerichtete Kanten zerlegen muss, ist definitiv kein Problem für jemanden, der mit Turn Restrictions, Spurabbildungen und sonstigen Herausforderungen des OSM-Datenmodells zurechtkommen würde.

Hier kann ich dir leider nicht ganz folgen.

Ich frage mich immer, wie professionelle Kartensysteme die Realität abbilden. Ich denke, dass man dort ebenfalls für jede Fahrtrichtung einen separaten Way anlegt. Denn ich kann mir keine elegante Lösung denken, um die verschiedenen Eigenschaften der unterschiedlichen Fahrtrichtungen realitätsnah abzubilden und die Daten für Routing-Programme einfach aufzubereiten.

Abbiegeverbote können bereits jetzt für jede Richtung angegeben werden. from, via, to in einer Restriction-Relation ist die Lösung. Ähnlich wäre es auch möglich, die Vorfahrt zu kennzeichnen.

Das Problem, welches sich aus 2 direkt übereinanderliegenden Wegen ergibt, ist, dass man beim editieren nur einen Weg auswählt und sich so etwaige Änderungen nicht auf beide Wege auswirken können.
Außerdem würden alle Renderer Probleme bekommen. oneway=yes sollte man auch nur für richtige Einbahnstraßen nutzen. Einbahnstraße bedeutet u.a. auch, dass es keinen Gegenverkehr gibt und das ist auf diesen Wegen definitiv falsch, es sei denn, die Fahrbahnen sind baulich getrennt.

mpeter89 wrote:

Tordanik wrote:

forward/:backward-Anhängsel␣an␣den␣Tags?␣Spart␣einen␣Way␣und␣eine␣Relation␣gegenüber␣deinem␣Vorschlag.␣Die␣meisten␣Eigenschaften␣werden␣sowieso␣für␣beide␣Richtungen␣gelten.

Wäre eine Notlösung. Gefällt mir aber nicht wirklich. Was ist, wenn jemand ausversehen (denkt sich nichts dabei) die Way-Richtung umkehrt? Dann wären alle Angaben falsch.

Was ist, wenn jemand den "überflüssigen" zweiten Way löscht? Halte ich jetzt nicht gerade für unwahrscheinlicher.

Brauchbare Editoren (= JOSM 😉 ) warnen übrigens beim Umdrehen von Wegen mit :forward/:backward schon heute, also kann ich die Angst vor dem Umdrehen von Wegen inzwischen noch weniger verstehen als bisher. Die Lösung ist m.E. absolut brauchbar.

Wenn man 2 Ways hat, es aber nur von einer Fahrtrichtung in der Realität erlaubt ist, rechts abzubiegen, dann würde man nur diesen Way damit verknüpfen.

Das ist in einem traditionell arbeitenden Editor nicht mehr handhabbar. Eine Kreuzung, an der mehrere Nodes direkt übereinander liegen, und mehrere übereinander liegende einlaufende Ways, die jeweils nur mit bestimmten Kreuzungsnodes verbunden sind? Beschreibt wohl so ziemlich meine Horrorvorstellung, was Wartung und Fehlersuche angeht.

Routing-Services hätten es so auch einfacher.

Was du hier anscheinend (vermutlich unbewusst?) versuchst, ist: Die Routing-Datenstruktur, wie sie in einem Navigationssystem normalerweise erzeugt aus den OSM-Daten erzeugt würde, von Hand zu bauen. Du mappst also letztlich nicht mehr Straßen, sondern Verkehrsflüsse.

Ich halte aber den momentan vorwiegend verwendeten Ansatz für weit anschaulicher und damit geeigneter: Wir mappen mit Ways das physische Straßennetzwerk - also sind Straßen verbunden, wo sie sich kreuzen (egal, ob ich abbiegen darf), und sind nur dann getrennt, wenn sie in der Realität baulich separiert sind. Darauf legen wir mit Attributen und Relationen dann die Informationen zu Beschränkungen etc. - Grundlage bleibt aber die leicht optisch visualisierbare physische Netzstruktur.

Das ist gerade für Rendering gut geeignet und erfordert nur machbare Konvertierung für das Routing. Es ist unabhängig vom Verkehrsmittel (würde ich in deinem Beispiel die Ways auch dann nicht verknüpfen, wenn ich zwar mit dem Auto nur aus einer Fahrtrichtung in eine Straße komme, aber mit dem Rad oder zu Fuß aus beiden? Was ist mit zeitabhängigen Abbiegeverboten oder ähnlichen Scheußlichkeiten?) Insbesondere ist es aber deutlich weniger abstrakt als das direkte Kartografieren eines Verkehrsflussgraphen.

Zum Thema überholen: Da könnte ich einen Way einen Tag zuordnen: Überholen=yes/no - unabhängig von der anderen Fahrtrichtung.

Ok, also wieder nur insofern anders, als man sich das :forward am Überholen:forward=no spart.

Wenn Hausenummern noch nicht richtig eingetragen sind, sondern nur auf die Straße interpoliert werden, dann würde es schon Sinn machen.
So könnte man rechte und linke Seite separat interpolieren und das Navi wüsste dann auch, ob rechts oder links das gewünschte Ziel wäre.

Normalerweise interpolieren per explizitem Interpolationsway, und das ist sicher nicht schwieriger als das Anlegen von Straßenseitenrelationen. Ob das Ziel links des Weges liegt, kann man geometrisch durch Vergleich der Lage mit der Straße rausfinden.

Für die Maximalgeschwindigkeiten schlage ich vor eine Relation wie folgt anzulegen:
type=enforcement
enforcement=maxspeed
maxspeed=70 (als Beispiel)

Die Relation bekommt dann 2 Mitglieder: Den Startpunkt der Beschränkung in der Rolle from, sowie den Endpunkt der Beschränkung in der Rolle to.

Dies ähnelt dem Vorschlag (http://wiki.openstreetmap.org/wiki/Prop … nforcement).

Tordanik wrote:

mpeter89 wrote:

Tordanik wrote:

forward/:backward-Anhängsel␣an␣den␣Tags?␣Spart␣einen␣Way␣und␣eine␣Relation␣gegenüber␣deinem␣Vorschlag.␣Die␣meisten␣Eigenschaften␣werden␣sowieso␣für␣beide␣Richtungen␣gelten.

Wäre eine Notlösung. Gefällt mir aber nicht wirklich. Was ist, wenn jemand ausversehen (denkt sich nichts dabei) die Way-Richtung umkehrt? Dann wären alle Angaben falsch.

Was ist, wenn jemand den "überflüssigen" zweiten Way löscht? Halte ich jetzt nicht gerade für unwahrscheinlicher.

Brauchbare Editoren (= JOSM 😉 ) warnen übrigens beim Umdrehen von Wegen mit :forward/:backward schon heute, also kann ich die Angst vor dem Umdrehen von Wegen inzwischen noch weniger verstehen als bisher. Die Lösung ist m.E. absolut brauchbar.
...

Wenn ich mir die Diskussion so überlege, muss ich Tordanik Recht geben. Sorry, @mpeter89, aber Deine Vorschläge sind bzgl. Fehlersuche etc. IMHO einfach zu 'umständlich'. Schließlich müssen wir bei neuen features immer daran denken, dass der zusätzliche Aufwand für das Mapping in Grenzen gehalten werden sollte. Ausserdem ist zu beachten, dass manche Mapper vor Begriffen wie 'Relationen-Editor' zurückschrecken und einfach nur einige Objekte mappen, die sie interessieren.

Entscheidend ist aber, was Tordanik hier schreibt:

Wir mappen mit Ways das physische Straßennetzwerk - also sind Straßen verbunden, wo sie sich kreuzen (egal, ob ich abbiegen darf), und sind nur dann getrennt, wenn sie in der Realität baulich separiert sind. Darauf legen wir mit Attributen und Relationen dann die Informationen zu Beschränkungen etc. - Grundlage bleibt aber die leicht optisch visualisierbare physische Netzstruktur.

Genau das ist der Kern von OSM - und daran sollte man nicht rütteln.

:forward/:backward-Anhängsel an den Tag halte ich für extrem sinnvoll, nicht nur für maxspeed oder bei Überholverboten.

Alles, was mit unterschiedlichem access zu tun hat, lässt sich damit abfangen: in ländlichen Regionen gibt es Wege / Gebiete, für die aus einer Richtung kommend access=agricultural gilt, aus einer anderen Richtung aber motor_vehicle=agricultural oder access=no oder gar keine Beschränkung - einfach deshalb, weil die Behörden (zum Teil aus verschiedenen Landkreisen) Verkehrsschilder nicht konsistent plazieren.

Mit Tag-Anhängsel gäbe es dann z.B. Wege wie folgt (ich plädiere übrigens wg. besserer Verständlichkeit für :forward_only bzw. :backward_only oder :reverse_only):

highway=track
tracktype=grade1
access:forward_only=agricultural
motor_vehicle:backward_only=agricultural

Natürlich müsste in Potlach, JOSM, Mercatoor etc. eine Warnung erscheinen, wenn eine Wegrichtung umgedreht wird. Da so ein Konzept flexibel ist (generell auf alle wegbezogenen keys anwendbar), erscheint mir dies aber als die beste Lösung.

Gruß, mtb

Augustus Kling wrote:

Für die Maximalgeschwindigkeiten schlage ich vor eine Relation wie folgt anzulegen:
type=enforcement
enforcement=maxspeed
maxspeed=70 (als Beispiel)

Die Relation bekommt dann 2 Mitglieder: Den Startpunkt der Beschränkung in der Rolle from, sowie den Endpunkt der Beschränkung in der Rolle to.

Dies ähnelt dem Vorschlag (http://wiki.openstreetmap.org/wiki/Prop … nforcement).

Dann kommt man ja aus dem Relationserstelle nie mehr raus. Man benötigt pro Straßenabschnitt 2 Relationen...

Lieber 2 Relationen mit 800 Membern als 800 ways mit diversen tags für die jeweilige richtung....

ich denke mal eine Umsetzung einer Filtefunktion für den type einer Relation ist in den Editoren ist einfacher und sinnvoller umzusetzen als wenn man Filter für Namesräume auf Tag ebene erstellt.

Moin,

Islanit wrote:

Lieber 2 Relationen mit 800 Membern....

also ich komme da eher auf (800 * 2) Relationen mit 2 Membern ...

Gruß
Georg

Nehmen wir mal an vor einer Ortschaft wird die Geschwindigkeit auf 70km/h reduziert. Die Einschränkung soll natürlich nur beim Einfahren in die Ortschaft gelten und nicht beim Ausfahren.

Dafür braucht man dann genau 1 Relation, die 2 Member hat. 1 Member (Rolle from) ist der Knoten auf der Straße an dem die Einschränkung beginnt (also auf Höhe des Schildes), der andere Member (Rolle to) ist das Ortschild (denn ab dort gilt ja 50km/h statt 70km/h).
Die Relation müsst wie oben vorgeschlagen beschrieben werden:
type=enforcement
enforcement=maxspeed
maxspeed=70

Die Vorteile dieser Beschreibung sind:
- Ähnelt enforment-Relation mit Status Approved
- Wenn im Editor der Weg umgedreht wird, stimmen die Daten immer noch (unabhängig vom Editor)
- Die Lösung ist nicht sehr abstrakt und Einsteiger können Wege als physikalisch vorhanden betrachten. Der Einsteig in OSM muss schließlich einfach bleiben.
- Das Wegenetz ist unabhängig von den Einschränkungen, die darauf gelten.

Stell dir mal in deinem Ort zwei Stellen vor, an der mehr als 2 Wege beginnen/enden. Woher soll nun das Auswertungsprogramm erkennen, auf welchen Wegen die 50 gilt.

Relationen sind alles, aber nicht einsteigerfreundlich ;-)

Bsp:
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
#50#-------------|-----------------|-------------------#50#
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|

@GeorgFausB
Dann lies dir meinen Vorschlag nochmal durch.

Ich wollte den kompletten Weg mit in die Relation packen.

Sprich wenn von Hamburg nach Hannover Tempo 120 ist und in die Gegenrichtung 100 dann Gäbe es genau 2 Relationen.

Wenn du alle Wege in eine Relation packen möchtest, wie willst du dann kennzeichnen, wo es losgeht? Wie regelst du die Reihenfolge der Wege, die zwischen Anfang und Ende liegen?
Und mal ehrlichbei einem Großteil der Straßen (innerhalb der Städte) kommt man meist eh nicht über 3 Blöcke hinweg, bis sich die Geschwindigkeit wieder ändert und auch außerhalb ist es nicht viel anders.

Btw: vom Datenmüll her ist ein maxspeed an jedem Weg geringer als die Relation.

Ich frag mich auch, warum man denn Relationen verwenden soll, anstatt einfach maxspeed:forward/backward?
Was hat das für einen Vorteil?
Es schreckt doch Einsteiger schnell ab, und übersichtlich ist es auch keineswegs.
Wenn man an jedem Weg einen Tag hinzufügt, braucht man nur auf den Weg klicken und editieren.
Von der Datenmenge ist das doch genauso viel wie mit einer Relation.
Warum nicht gleich alle motorway, primary, secondary, residential, ... von ganz Deutschland in eine jeweilige Relation packen?
Was soll das für einen Nutzen haben alle maxspeeds von Hamburg nach Hannover in eine Relation zu packen?
Da muss man sich ja wiederum die ganze Relation herunterladen!

Also ich bin sehr für das forward/backward-Schema.
Dann könnte man ja das mit nasser Fahrbahn oder Fahrzeugtypen noch dazu mit reinpacken.
Beispiele: maxspeed:forward.wet=80, maxspeed:backward.hgv=60.

Wenn Relationen verwendet werden, spart man sich das Auftrennen der Wege an den Stellen wo die Geschwindigkeitsbeschränkung wechselt. Damit sinkt das Risiko bei Änderungen anderer Tags das Ändern von Teilstücken zu vergessen. Das Problem gibt es ja schon mit Brücken, die anders klassifiziert sind als der andere Teil der Straße weil sie einfach übersehen wurden. Dann wären da noch die Richtungsänderungen der Wege, die die Bedeutung der forward/backward Eigenschaften verdrehen (oder kommen inzwischen alle Editoren damit klar?).
Dies sind die Punkte, die für mich gegen ein forward/backward-Anhängsel sprechen.

Die Menge der Daten die anfallen sollten für alle diskutierten Vorschläge auf das selbe hinaus laufen. Es zielen schließlich alle darauf ab die selbe Information festzuhalten.
Nach dem Teilen der Wege in Teilstücke (falls forward/backward) dürften hier etwas mehr Daten (im Bezug auf Speicherplatz) anfallen als bei Relationen – jedoch muss man sich um diesen Unterschied keine Sorgen machen.

Betreffs „alle maxspeeds in eine Relation“: Soweit ich die Kommentare verstanden habe, hat keiner vorgeschlagen alle Geschwindigkeitsbeschränkungen in eine Relation zu packen. Vorgeschlagen wurde pro Einschränkung eine Relation anzulegen – vergleichbar dem, dass pro maxspeed:forward/backward ein Weg angelegt werden muss.

Um noch kurz auf Kommentar #13 einzugehen: Beginn und Ende einer Beschränkung liegen sinnigerweise auf dem selben Weg. Sobald abgebogen wird, muss angenommen werden, dass die Beschränkung aufgehoben ist. So wie normale Verkehrschilder eben auch nur solange gelten bis abgebogen wird.

Mein Kommentar weiter oben mit dem leichten Einsteig bezieht sich auf den ursprünglichen Vorschlag mehrere Oneway-Wege übereinander zu legen und damit Fahrspuren anstatt das Wegenetz abzubilden. Zweifellos wäre es für Routing und die Abbildung von Verkehsregeln/des Verkehrsflusses besser die Wege und Eingenschaften separat zu halten. Allerdings ist damit das Wegenetz sehr abstrakt beschrieben und kaum mehr für Neueinsteiger zu bearbeiten. Für OSM ist so etwas undenkbar da OSM von dem einfachen Datenmodell lebt.

Im Wiki wird ein Doppelpunkt verwendet um die Eigenschaften abzutrennen, beispielsweise maxspeed:hgv=70. Bereits hier in der Diskussion ist davon abweichend ein Punkt zu finden. Warum maxspeed:backward.hgv=* anstatt maxspeed:backward:hgv? Das ändert zwar die Bedeutung nicht, erschwert aber die Auswertung. Wenn man forward/backward verwenden möchte, sollte man zuerst die Eigenschaft (hier maxspeed) notieren, dann in beliebiger Reihenfolge die Einschränkungen. Also beispielsweise maxspeed:hgv:wet=* oder maxspeed:wet:hgv:hazmat:backward=*.

Es bleibt die Entscheidung zwischen:
- forward/backward + Aufteilen der Wege: Einfachste Eingabe, Risiko bei Änderungen Teilstücke zu übersehen, Risiko die Bedeutung umzukehren (bei Drehen der Wege)
- Relationen: Etwas komplizierter, aber ohne obige Risiken

Augustus Kling wrote:

Wenn Relationen verwendet werden, spart man sich das Auftrennen der Wege an den Stellen wo die Geschwindigkeitsbeschränkung wechselt. Damit sinkt das Risiko bei Änderungen anderer Tags das Ändern von Teilstücken zu vergessen. Das Problem gibt es ja schon mit Brücken, die anders klassifiziert sind als der andere Teil der Straße weil sie einfach übersehen wurden.

Inwiefern ist das auf :forward/:backward beschränkt? Bei einem normalen maxspeed muss man ebenso Wege auftrennen, wo die Geschwindigkeitsbeschänkung wechselt, und man kann man ebenso Teilstücke für Änderungen übersehen.

Das wäre höchstens ein Argument, Beschänkungen generell in Relationen auslagern zu können. Was übrigens an sich keine schlechte Idee wäre - man könnte einiges, etwa auch zeit- oder verkehrsmittelabhängige Beschänkungen eleganter darstellen und hätte eben das genannte Teilstückproblem nicht mehr. Aber das bräuchte eindeutig Editorunterstützung.

Und es hat eben nicht speziell etwas mit richtungsabhängigen Eigenschaften zu tun...

Beginn und Ende einer Beschränkung liegen sinnigerweise auf dem selben Weg.

Dann muss aber auch klar sein, dass dadurch eine Relation für jedes Wegstück angelegt werden müsste, wenn sich eine Beschränkung über mehrere Ways erstreckt. Damit meine ich nicht mal unbedingt Abbiegen, sondern eben z.B. den Fall des wegen einer Brücke unterbrochenen Ways. Und es darf natürlich bei Änderungen auch nicht die Relation für ein einzelnes Teilstück vergessen werden.

Relationen: Etwas komplizierter, aber ohne obige Risiken

Ja, Relationen sind "etwas" komplizierter. Es dürfte leider deutlich einfacher sein, den Editoren das Umdrehen von Tags beizubringen (was ja auch für andere Tags als :forward/:backward von Interesse ist, etwa :left/:right-Tags oder incline), als eine einfach bedienbare Handhabung von Relationen zu implementieren.

Ich habe mal beide Vorschläge umgesetzt:
Einmal als Relation

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣generator='JOSM'>
<node␣id='-1'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0847543551107324'␣lon='-3.5473980677308212'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-2'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0848718452435815'␣lon='-3.5478187578085967'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-3'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.084975236556715'␣lon='-3.5480960842285834'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-4'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0852407642310715'␣lon='-3.5487729487112607'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-5'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0854169994002962'␣lon='-3.549527370582579'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-6'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0854263986090333'␣lon='-3.5500044660339114'>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='name'␣v='start'␣/>
</node>
<node␣id='-7'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0844359935434515'␣lon='-3.5454419837248095'>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='name'␣v='Ziel'␣/>
</node>
<node␣id='-8'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0845231932610353'␣lon='-3.5459744563267424'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-9'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'␣lat='1.0846204163537199'␣lon='-3.5466530467550954'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<way␣id='-10'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-6'␣/>
<nd␣ref='-5'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-11'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-4'␣/>
<nd␣ref='-5'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-12'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-4'␣/>
<nd␣ref='-3'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-13'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-1'␣/>
<nd␣ref='-2'␣/>
<nd␣ref='-3'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-14'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-8'␣/>
<nd␣ref='-9'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-15'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-1'␣/>
<nd␣ref='-9'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<way␣id='-16'␣action='modify'␣timestamp='2010-02-19T07:54:54Z'␣visible='true'>
<nd␣ref='-7'␣/>
<nd␣ref='-8'␣/>
<tag␣k='highway'␣v='motorway'␣/>
</way>
<relation␣id='-17'␣action='modify'␣visible='true'>
<member␣type='way'␣ref='-10'␣role=''␣/>
<member␣type='node'␣ref='-6'␣role='from'␣/>
<member␣type='node'␣ref='-7'␣role='to'␣/>
<member␣type='way'␣ref='-11'␣role=''␣/>
<member␣type='way'␣ref='-12'␣role=''␣/>
<member␣type='way'␣ref='-13'␣role=''␣/>
<member␣type='way'␣ref='-14'␣role=''␣/>
<member␣type='way'␣ref='-15'␣role=''␣/>
<member␣type='way'␣ref='-16'␣role=''␣/>
<tag␣k='type'␣v='restriction'␣/>
<tag␣k='maxspeed'␣v='50'␣/>
</relation>
<relation␣id='-18'␣visible='true'>
<member␣type='node'␣ref='-6'␣role='to'␣/>
<member␣type='node'␣ref='-7'␣role='from'␣/>
<member␣type='way'␣ref='-10'␣role=''␣/>
<member␣type='way'␣ref='-11'␣role=''␣/>
<member␣type='way'␣ref='-12'␣role=''␣/>
<member␣type='way'␣ref='-13'␣role=''␣/>
<member␣type='way'␣ref='-14'␣role=''␣/>
<member␣type='way'␣ref='-15'␣role=''␣/>
<member␣type='way'␣ref='-16'␣role=''␣/>
<tag␣k='type'␣v='restriction'␣/>
<tag␣k='maxspeed'␣v='40'␣/>
</relation>
</osm>

und einmal mit forward backward:

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣generator='JOSM'>
<node␣id='-1'␣action='modify'␣visible='true'␣lat='1.0854263986090333'␣lon='-3.5500044660339114'>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='name'␣v='start'␣/>
</node>
<node␣id='-2'␣action='modify'␣visible='true'␣lat='1.0854169994002962'␣lon='-3.549527370582579'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-3'␣action='modify'␣visible='true'␣lat='1.0852407642310715'␣lon='-3.5487729487112607'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-4'␣action='modify'␣visible='true'␣lat='1.084975236556715'␣lon='-3.5480960842285834'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-5'␣action='modify'␣visible='true'␣lat='1.0848718452435815'␣lon='-3.5478187578085967'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-6'␣action='modify'␣visible='true'␣lat='1.0847543551107324'␣lon='-3.5473980677308212'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-7'␣action='modify'␣visible='true'␣lat='1.0846204163537199'␣lon='-3.5466530467550954'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-8'␣action='modify'␣visible='true'␣lat='1.0845231932610353'␣lon='-3.5459744563267424'>
<tag␣k='highway'␣v='motorway'␣/>
</node>
<node␣id='-9'␣action='modify'␣visible='true'␣lat='1.0844359935434515'␣lon='-3.5454419837248095'>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='name'␣v='Ziel'␣/>
</node>
<way␣id='-10'␣action='modify'␣visible='true'>
<nd␣ref='-1'␣/>
<nd␣ref='-2'␣/>
<tag␣k='maxspeed:backward'␣v='40'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='50'␣/>
</way>
<way␣id='-11'␣action='modify'␣visible='true'>
<nd␣ref='-3'␣/>
<nd␣ref='-2'␣/>
<tag␣k='maxspeed:backward'␣v='50'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='40'␣/>
</way>
<way␣id='-12'␣action='modify'␣visible='true'>
<nd␣ref='-3'␣/>
<nd␣ref='-4'␣/>
<tag␣k='maxspeed:backward'␣v='40'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='50'␣/>
</way>
<way␣id='-13'␣action='modify'␣visible='true'>
<nd␣ref='-6'␣/>
<nd␣ref='-5'␣/>
<nd␣ref='-4'␣/>
<tag␣k='maxspeed:backward'␣v='50'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='40'␣/>
</way>
<way␣id='-14'␣action='modify'␣visible='true'>
<nd␣ref='-8'␣/>
<nd␣ref='-7'␣/>
<tag␣k='maxspeed:backward'␣v='50'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='40'␣/>
</way>
<way␣id='-15'␣action='modify'␣visible='true'>
<nd␣ref='-6'␣/>
<nd␣ref='-7'␣/>
<tag␣k='maxspeed:backward'␣v='40'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='50'␣/>
</way>
<way␣id='-16'␣action='modify'␣visible='true'>
<nd␣ref='-9'␣/>
<nd␣ref='-8'␣/>
<tag␣k='maxspeed:backward'␣v='40'␣/>
<tag␣k='highway'␣v='motorway'␣/>
<tag␣k='maxspeed:forward'␣v='50'␣/>
</way>
</osm>

Meine derzeitige Meinung
Relation:
+Vorteile beim ändern einer Grossflächigen Anpassung
- Nachteile beim Aufteilen (50% der Relation bekommt maxspeed 30)
+Unabhängig von der Richtung des Weges
+Ohne Anpassung in den Editoren umsetzbar
- Aufwendiger im Anlegen
Way:

+Vorteil beim Anpassen von kurzen Stücken
+Schnell anzulegen
- Nachteile beim Grossflächigen ändern mit verschiedenen Richtungen des Weges
+ohne anpassen der Editoren möglich (aber empfholen)
- Abhängig von der Richtung des Weges

Danke für die Zusammenfassung.
Habt ihr eigentlich schon mal daran gedacht, dass wir noch andere wegrichtungsabhängige keys haben?
Beispiele sind oneway oder footway=left|right|none.
Was ist daran so schlimm? Es macht doch weniger aus, wenn mal jemand einen Weg mit maxspeed verdreht,
als wenn versehentlich eine ganze Relation gelöscht wird!
Man muss beim editieren eben einfach darauf aufpassen, dass man keine Wege verdreht ohne die vorhandenen Attribute anzusehen
oder diese eben anzupassen!

Ich findes es einfach nur recht Unglücklich das Tags aufgrund der RIchtung des Weges eine Bedeutung haben.
Klar hatten wir soetwas in der Vergangenheit auch und es funktioniert auch.. siehe die Oneways.
Ich mag aber auuch an die Zeiten erinnern als Flächen noch im Uhrzeigersinn ausgerichtet seinen mussten damit sie angezeigt werden.

Bisher sind wir auch weitesgehend ohne Richtungsbasierte Tags ausgekommen. Wenn wir die Benutzung von diesen Massiv ausweiten wollen dann sollte das Konzept stimmig sein. Und schlussendlich sollte es auch eine Gewisse Einsteigerfreundlichkeit bleiben....

Betrachten wir mal eine Sinple Bundestraße aus den Augen eines Einsteiger:
Die besteht aus namen,ref,highway und villeicht noch maxspeed. Das ist für jemaden der grade frisch eingestiegen ist sehr gut zu verstehen und er kann das einordnen. Je komplizierter wir es ihm machen sei es durch relationen oder tags desto schwieriger wird er es haben.

Nach meinen Glauben (und ich habe nicht die weisheit mit dem löffel gefressen) ist es für jemanden deutlich leichter 3-4 Relationen zu ignorieren wenn er seine oben angeführten Basistags wiederfindet. Dann kann er sich sagen so den Schmarn mit den Relationen versteh ich nicht aber immerhin weis ich warum die Straße auf der Karte diesen namen trägt und so angezeigt wird.
Ich persönlich sehe das deutlich schwieriger von den Einsteiger zu durchschauen wenn seine "Basistags" in einer Wolke von Tags verschwunden ist und er sich diese erst raussuchen muss. Bestes beispiel sind dafür die place tags. Da wird auf der Karte ein name angezeigt und hinter der node stehen 15 verschiedene Tags. Klar die werden alle benötigt und sind sinnvoll ... schrecken aber in meinen augen auch erstmal ab...

KaChing_Cacher wrote:

Danke für die Zusammenfassung.
Habt ihr eigentlich schon mal daran gedacht, dass wir noch andere wegrichtungsabhängige keys haben?
Beispiele sind oneway oder footway=left|right|none.
Was ist daran so schlimm? Es macht doch weniger aus, wenn mal jemand einen Weg mit maxspeed verdreht,
als wenn versehentlich eine ganze Relation gelöscht wird!
Man muss beim editieren eben einfach darauf aufpassen, dass man keine Wege verdreht ohne die vorhandenen Attribute anzusehen
oder diese eben anzupassen!

Der EDITOR müßte beim Drehen von Wegen die Tags einfach mitdrehen (also left zu right für Fußwege, forward vs. backward und was es sonst so gibt). Dann passiert da nichts mehr, auch wenn man mal nicht aufpaßt.

Mit diesen Satz hast du mich überzeugt:

Tordanik wrote:

Wir mappen mit Ways das physische Straßennetzwerk - also sind Straßen verbunden, wo sie sich kreuzen (egal, ob ich abbiegen darf), und sind nur dann getrennt, wenn sie in der Realität baulich separiert sind. Darauf legen wir mit Attributen und Relationen dann die Informationen zu Beschränkungen etc. - Grundlage bleibt aber die leicht optisch visualisierbare physische Netzstruktur.

Dennoch finde ich beide Wege: Relationen oder forward/backward nicht wirklich gelungen und beide haben - wie schon erwähnt - bei der Bearbeitung große Probleme.

Eine Lösungsidee ist mir aber in den Kopf gekommen:

Trennung von Ways und speziellen Eigenschaften/ Zuordnungen mit sogenannten Layers.
So stelle ich mir das vor (klar es ist nicht schnell umsetzbar, aber dennoch eine "Vision"):

- Straßennetz (physische Wege) werden angelegt
- zu dieser Basisebene gehören dann Eigenschaften wie die Bodenbeschaffenheit oder andere physische Eigenschaften
- in einer weiteren Ebene kann man dann Städte einzeichnen
- in weiteren: Postleitzahlen, Stadtteile, Stadtgebiete (Wohngebiet, Geschäftsgebiert, Industriegebiet...)

- darauf baut ein zusätzliche Layer auf: z.B. Layer: Straßenverkehrsordnung
- dieser enthält dann die Beschreibung von Maxspeed-Angaben, Vorfahrtsregeln, Straßenschilder, Angaben wie: Maximale Höhe, Breite, Gewicht, Straßenname (denn ein Straßenname kann sich während eines physikalischen zusammenhängenden Weges ändern) ....
- weiter wird in dieser Ebene ggf. mehrere Tracks (2 getrennte Spuren, ggf. seperate Fuß- und Radwege) zusammengefasst

In Editoren könnte ich mir das so vorstellen:
- Man wählt die Ebenen aus, die man bearbeiten möchte.
- zuerst legt man die Wege an
- ein anderer kann dann die Straßen-Ebene vornehmen und dort die Verkehrsregeln und Schilder eintragen
- wobei alle Änderungen vom Editor relativ von der Basisebene (relativ zu den Nodes) gespeichert werden
- wird in der Basisebene ein Node verschoben, bleibt dennoch der Maxspeed-Abschnitt konstant

Solch ein Modell spiegelt meiner Meinung nach die Wirklichkeit besser wieder. Denn man unterscheidet zwischen den verschiedenen Ebenen, die oft auch gar nichts miteinander zu tuen haben (z.B: PLZ mit Landschaft).
Weitere Vorteile dieses Konzepts:
- einfach in der Bearbeitung -> verschiedene unabhängige Ebenen
- übersichtlicher und intuitiver zu bedienen (es sind keine 20 Tags auf ein Track und der Track wird nicht von 2-5 Relationen umfasst)
- im Editor wird nur das für mich Wesentliche angezeigt -> auch weniger Ladezeit, Traffic

Ich bin mir bewusst, dass das nicht so einfach umzustellen ist, aber ich denke, dass OSM vielleicht irgendwann darauf hinauslaufen wird, weil es sonst einfach viel zu Komplex wird.
In manchen Städten stürzt mein Browser fast ab, weil bei geringeren Zoomstufen so viele Elemente existieren.

jOSM fragt ja beim drehen nach, ob die Tags gedreht werden sollen. Ein Automatismus ist nicht gut, da nicht bei jedem Drehvorgang mit richtungsabhängigen Tags ein wechsel gewünscht ist.