Maxspeed bei nassen Straßen

@Tordanik: Ich stimme dir da größtenteils zu. Ich denke das sollten wir im angesprochenen Thread weiterdiskutieren. Das passt hier nichtmehr zum Thema. Ich kopiere deine Ideen mal in den alten Thread. Eventuell kann man da das Lane-Tagging mit aufnehme

So. Wir haben uns zwar (noch?) nicht wirklich geeinigt im Tag-Hierarchien-Thread, um wenigstens die sinnvollen “modifier” zu sammeln, habe ich aber trotzdem mal einen Entwurf für ein Proposal erstellt: Modifiers for access tags.

Ach du schande … meint ihr nicht, dass das etwas sehr komplex ist? Oder ist das für die Programmierer einfacherer um zu setzen weil nichtmehr jedes einzelne Tag einprogrammiert werden muss sondern nur noch die Syntax und einige wenige Tags?

Im Prinzip wär es einfacher. Man muss sich nur auf eine einheitliche Syntax einigern… (siehe Entwurf von hierachischen Tag-Strukturen) Edit: Einfacher ist vielleicht falsch ausgedrückt. Es ist natürlich einfacher jeden Tag einzeln einzugeben. Aber einzelne Tags angeben ist aufwändiger, und es wird mit sicherheit immer irgendein Tag vergessen. Wenn man einfach maxspeed bedeutet “erlaubte höchstgeschwindigkeit” und wet bedeutet “bei nässe” festlegt, dann kann man “wet” auch für andere Tags einsetzen, indem man einfach maxheight:wet=1.5 angibt… (in dem fall unlogisch, aber soll ja nur als Beispiel dienen, und wer weiß ob es sowas nicht tatsächlich irgendwo gibt. ;))

Echt? Ich finds ganz übersichtlich, aber ich bin auch Programmierer. :smiley: Es ist doch eigentlich ein recht “übliches” Konzept: Wir schreiben hinter den Doppelpunkt, wofür die Information gilt. So ähnlich, wie wir den Namen im Fall “deutsch” halt name:de nennen und den Namen im Fall “englisch” name:en, nennen wir die Höchstgeschwindigkeit, wenns nass ist, halt maxspeed:wet, und die Höchstgeschwindigket, wenn ich in einem LKW sitze, maxspeed:hgv. Als einziges ergänzendes Konzept gibts noch den Fall mit mehreren Bedingungen (der ist sicher selten, aber ich definiere lieber eine Situation, bevor sie zum Problem wird) – bei dem man eben in der aktuellen Fassung & verwendet. Das wars dann aber auch schon, der Rest der Vorschlag-Seite sind Beispiele, Anmerkungen usw. Wichtig finde ich aber, dass man auf diese Weise sicherstellt, dass die Tags einheitlich aufgebaut sind – ich jedenfalls kann mir ein halbwegs logisches Schema besser merken als ein paar Dutzend Einzeltags (die, wenn man nach dem “wer ein Schild findet, denkt sich 'n Tag dafür aus”-Prinzip weitermacht, auch keinem irgendwie gearteten Muster folgen dürften). Und nicht zuletzt umgeht man das Problem, dass man beim Tag-Erfinden garantiert irgendeine exotische Schilderkombi vergisst – mit den Regeln sollte sie in den allermeisten Fällen “zusammenbaubar” sein. Letzten Endes kann man natürlich für die Standardfälle eine Tabelle mit Bildern usw. auf den entsprechenden Wiki-Seiten bauen, man muss ja nicht wissen, wieso maxspeed:wet so heißt, um es anzuwenden. Mich würde aber deine Meinung interessieren, wie man das Proposal übersichtlicher darstellen machen kann – falls das überhaupt geht, und es kein unvermeidliches Problem des Konzepts ist.

Für manche Programme ist es sicher gut (besonders, wenn man sie mit Kenntnis des Schemas entwirft), für primitive regelbasierte Umsetzung in den heutigen Renderern gar nicht so sehr, weil man z.B. mit unterschiedlicher Reihenfolge bei den &-Verknüpfungen zurecht kommen muss. Das bekommt man aber m.E. nicht leichter allgemeingültig hin. Sofern irgendeine so komplexe Verkehrsregel überhaupt für die grafische Darstellung relevant sein sollte, müsste man die Software hier etwas anpassen.

Och, wir haben einen reichlichen Pool an Beschränkungen. Auf diversen Brücken gibt es Geschwindigkeitsbeschränkungen oder Fahrverbote für LKW, wenn eine bestimmte Windstärke herscht. Auf der A 71 oder der B 180 gibt es Abschnittsweise Vollsperrungen wegen Sprengungen in den angrenzenden Steinbrüchen. Für die diversen Anzeigen haben wir auch noch nix. Unser Schmücketunnel ist vollständig mit Spur- und Geschwindigkeitsanzeigen geregelt. Im Wald sind Lichtschranken für Wildwechsel, die entsprechende Geschwindigkeiten auf Anzeigen Signalisieren. Bei den möglich Situationen kratzen wir noch an der Oberfläche. Ich sehe schon Straßen die völlig zerschnitten und voll mit Tags sind. Wir haben dann zwar fast eine eigene Scriptsprache erfunden, die eigentlichen Daten sind aber nur noch Schnipsel. Man kann ja mal träumen, aber ich wünsche mir den Tag, an dem ich in JOSM folgendes eigentlich gewohnte vorfinde.

Oha, müsste man sich auch noch was ausdenken. Das überlass ich aber mal Leuten mit Ahnung von Windstärken.

Ich verstehe ehrlich nicht, was daran so schlimm ist. Man nehme mal an, es gäbe Editorunterstützung, um mit zwei Klicks Anfang und Ende eines Straßenabschnitts anzugeben und dann den ganzen so markierten Abschnitt mit Attributen versehen zu können. Wäre dann wirklich für die Praxis relevant, ob es sich intern um einen Teilabschnitt eines einzigen Ways oder mehrere hintereinanderliegende Ways handelt? Edit: defektes Quoting repariert

Nochmal mein kleines Beispiel. 300 Meter Dorfstraße mit 2 Namen und 7 wechselnden Fußwegkombinationen. Ohne anderes zu berücksichtigen, sind das schon 8 Teile. Nun stelle man sich mal eine große Straße mit mehreren Spuren, Richtungen, Beschränkungen usw. vorbildlich getaggt vor. Zumal mangels echter Lanes alles an ein Óbjekt getackert werden muss, bei dem man auch noch aufpassen muss dass es ja keiner dreht, da ansonsten alle backward/vorward/left/right Angaben für die Tonne sind. Und jeder darf editieren. Es würde mich extrem wundern, wenn das in der Form langfristig gut geht. In großen Städten mit mehreren Orstkundigen Mappern kann das mit entsprechendem Kontrollaufwand vielleicht noch gut gehen. Sämtliche Attribute verstecken jetzt hinter einer einzelnen Linie, sind aufgrund Überschneidungen oder anderer innerhalb liegender Attribute selbst zerschnitten. Jede Änderung erfordert wider neue Cuts oderr Verschmelzungen und eine Prüfung ob auch alle Teile erwischt wurden. Ist es dann nicht einfacher ein dynamisches Objekt zu haben, was direkt an eine Lane gebunden ist und bei einer Änderung entweder einfach verschoben oder entfernt werden kann, ohne dabei auf alles andere was ansonsten daran hängt achten zu müssen? Zumal die ganzen künstlichen Relationen und Richtungsangaben gleich komplett unter den Tisch fallen würden?

Es ging mir jetzt ausschließlich um Aufsplittungen aufgrund von Eigenschaften des Gesamtways, nicht aufgrund von Lanes, weil das Thema dieses Threads ja wie bereits bemerkt nichts mit Lanes zu tun hat. Insofern würde ich dich bitten, eine Antwort ggf. in einem eigenen Thread zu erstellen und darauf zu verweisen.

Warum das? Man kann mit dem jetzigen Datenmodell Lanes auch problemlos als eigene Ways oder Relationen modellieren, siehe zum Beispiel meinen Versuch im Wiki. Ich gebe gerne zu, dass es besser wäre, den Hauptway nicht zerschneiden zu müssen, wenn Lanes dazukommen oder verschwinden, aber die Tags kann man ganz ordentlich auf eigene Objekte verteilen.

Das wirkt bei wenigen “dynamischen Objekten” ja sicher noch ganz übersichtlich, aber wenn ich dann das dynamische Objekt für den Straßenbelag und das dynamische Objekt für die Höchstgeschwindigkeit und das für das Durchfahrtsverbot und das für den Namen usw. rumschiebe, sehe ich keinen wirklichen Vorteil mehr gegenüber einer Aufsplittung. Vielleicht fehlt mir ja einfach nur die Phantasie.

Und ich wollte damit zeigen das man eben wegen fehlender Lanes aber unterschieldlichen Eigenschaften herumschnippeln muss. Das Gebilde Straße besteht nunmal aus einer Kombination von Lanes. Ich muss mir also vorher darüber Gedanken machen, bevor ich alles mit Tags zuschütte.

Das ist doch auch nur die Notlösung die man beispielsweise bei Schnellstraßen und Autobahnen nutzt. Zwei händich nebeneinander gelegte Wege, mit den alten Problemen. Dafür brauche ich kein Proposal, das kann ich schon jetzt malen. Was ich meine geht viel weiter. Eine Hilfslinie welche die Straßenmitte darstellt. Daraus werden z.B. aus der Angabe der Lanes und der Breite automatisch 2 Lanes generiert. Die kennen nur noch Oneway, Links- oder Rechtsverkehr. Drehereien überflüssig. Auf Links gedrehte Straßen kann der Fixbot berichtigen, muss keiner mehr vor Ort jeden Schnipsel checken. Das ganze bleibt ansich ein Objekt nur unterteilt sich dieses innerhalb des Objektes in seine wirklichen Bestandteile, die man dann auch konkret, ohne virtuelle und Gesamtrichtungsabhängige Umschreibungen oder Relationsbasteleien, bearbeiten kann.

Wie das hier genau aussehen könnte, müsste man sich mal konkreter mit beschäftigen. Überordnete Dinge ref, Name, Belag usw. können ja im Hauptobjekt verbleiben, betreffen ja einen ganzen Abschnitt. Aber der ganze Kleinscheiss kann darüber gelegt werden, ohne den ganzen Abschnitt zerhacken zu müssen.

Eigene Ways zeichnen ist optional, und nur für den Fall gedacht, dass die Lanes nicht einfach trivial nebeneinander her laufen. Laut dem Proposal kannst du ohne weiteres auch nur zwei Lane-Relationen an den auf der Straßenmitte verlaufenden Hauptweg hängen, wobei der tatsächliche Verlauf der Spuren dann automatisch aus dem des Hauptweg, Breitenangaben usw. abgeleitet werden kann. Ich sehe nicht so ganz den Unterschied zu

Das ganze ist in dieser Form natürlich nicht nur ein einzelnes Objekt, weil das eine Api-Änderung erfordern würde, aber dieser Unterschied lässt sich m.E. vollständig wegabstrahieren.

Ich möchte aber keine nicht aus zwei unterschiedlichen von Hand gezeichneten Wegen ein Objekt mit einer Relation basteln. Genau von diesem mit der Kirche um das Dorf fahren will ich doch weg. Ich bin kein Programmier sondern kann das nur aus Anwendersicht und der Erfahrung aus anderer Editoren erklären. Das versuche ich jetzt mal. Ich zeichne also z.B. in JOSM wie gewoht eine Linie. Praktisch wenn ich dann Kurven auch noch als Splines zeichnen kann, spart wieder eine Menge Nodes. Dann markiere ich den Weg und öffne den… nenen wir ihn mal Streeteditor . Dort gebe ich 2 Lanes und eine Breite von 5m an. Intern macht er dann 5/2 und zeichnet mir automatisch und vor allem symetrisch und exakt zwei Lanes im Abstand von 2,5m links und rechts meiner gezeichneten Hilfsline. Nun kann ich dem Objekt als ganzes Attribute verpassen, einer einzelnen Lane, oder lege die Information dynamisch darüber. Am Ende brauche ich keine Relation, keine virtuellen Richtungsangaben und damit weniger tags, weniger Nodes, weniger Stückwerk.

Ja du Autofahrer, sehr schön :wink: Ich würde die Breite jeder Lane einzeln verpassen, fertig. Wenn die Messungen genauer werden oder andere Datenbasen zur Verfügung stehen, dann gibt es mit der virtuellen Hilfslinie ein Problem, dann stimmt die Mitte, ohne sie zu berechnen, nicht mehr. Die Frage ist, wie genau muss es sein und wie kann DAS PROBLEM gelöst werden. Die gezeichnete Linie als Hiflslinie zu betrachten wäre dann schon ein Anfang, ich persönlich glaube nicht, das die Karte im Durchschnitt auf eine Genauigkeit < 5m kommt. Grüße.

Wenn für die Mitte genauere Daten vorliegen dann wird wie jetzt einfach verschoben. Allerdings nur noch der Stützpunkt der Hilfslinie selbst. Die Lanes kleben ja noch immer an der Hilfsline und verschieben sich entsprechend mit. Wo ist da jetzt das Problem? Das kann doch alles kein Hexenwerk sein. Solche Dinge hat beispielsweise sogar Winzigweich in einer sonst suboptimalen Umgebung schon vor einem Jahrzehnt gepackt.

Zum Abschluss des ursprünglichen Themas ein Proposal: Scope for access tags. Umfasst erst mal nur die “Kernfeatures”. Der Rest wird für später aufgehoben.

Hallo zusammen,

soll man auf der Autobahn bei einer Geschwindigkeitsbegrenzung nur bei Nässe keine maxspeed taggen, oder lieber maxspeed=none und maxspeed:wet = 80 (ist aber offenbar erst ein Proposal Proposed features) ?

(Hintergrund: keepright meckert, wenn kein maxspeed angegeben ist)

Hat sich da mittlerweile etwas getan ?

Jan

da maxspeed=none der Default-Wert ist reicht auch maxspeed:wet = 80.

Chris

Gibt es inzwischen eine Idee wie man zusätzlich noch zeitabhänige Geschwindigkeiten erfasst?

Idee ja:

http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags

Also beispielsweise:
maxspeed = 50
maxspeed:(Mo-Fr 07:00-17:00) = 30
Der Wert in Klammern ist opening_hours-Syntax. Auch kombinierbar mit z.B. :wet, da ergeben sich dann eben noch weitere Tags.

Aber auf eine Auswertung brauchst du derzeit nicht zählen, noch nicht einmal bei einfachen Fällen. Die Software hinkt da leider den Möglichkeiten des Taggings arg hinterher.

Vielen Dank, genau sowas habe ich gesucht!

Hauptsache die Daten sind erstmal halbwegs vernünftig in der Datenbank…