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 
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…