Maxspeed bei nassen Straßen

Darauf sollte man definitiv achten, mir wäre zunächst noch nichts aufgefallen. Dafür hat man bei einem Proposal ja dann auch noch die RFC-Phase, irgendwer wird die existierenden Keys hoffentlich kennen und den Konflikt bemerken.

Und hier haben wir schon unser erstes kleineres Problem: Doppelpunkte. :roll_eyes: Da in Zeiten leider auch welche vorkommen, kann das relativ unschön werden. Man könnte die Zeiten natürlich in Anführungszeichen setzen. maxspeed:time=“Sa-Su 00:00-24:00”:hgv Oder nen anderen Trenner statt der Doppelpunkte nehmen. Kommas oder Semikolons. maxspeed:time=Sa-Su 00:00-24:00;hgv bzw. maxspeed:Sa-Su 00:00-24:00;hgv Oder beides. Kommas und Semikolons werden nämlich auch in unserem Zeit"standard" verwendet. Momentan würde ich ein wenig dazu tendieren, Semikolons zu nehmen und für nicht zusammenhängende Zeiträume (für die ja anscheinend die Semikolons in den Zeiten da sind) einfach zwei maxspeed-Tags zu erfordern. Kommt hoffentlich nicht gar zu häufig vor und ist wahrscheinlich sogar noch leserlicher als maxspeed:hgv:time=“Mo 10:00-12:00,12:30-15:00; Tu-Fr 08:00-12:00,12:30-15:00; Sa 08:00-12:00” = 90 :smiley: Na, mal schauen… vielleicht hat ja noch wer eine geniale Idee.

Einfach weglassen die Doppelpunkte. Immer vierstellig, dann ist alles geritzt. Und so kompliziert wie bei den Briefkästen kann es schon deshalb nicht sein, weil sonst die Schilder an den Straßen so groß wären, dass man sie im Vorbeifahren gar nicht mehr komplett lesen könnte :wink: Ob man nun time oder was anderes nimmt … irgendwo gab es hier vor ein paar Wochen schon eine Diskussion, in der es um Zeitbereiche ging. Beim Parken, meine ich. Sollte man also mit ins Boot holen, diese Genossen :wink: Und ich mache mich jetzt ins Bett. 0000-0618 ist nicht so wahnsinnig viel … :frowning:

maxspeed:hgv = 90 maxspeed:hgv:time = Mo 10:00-12:00,12:30-15:00; Tu-Fr 08:00-12:00,12:30-15:00; Sa 08:00-12:00 Da hol ich auch gerne wieder diesen Thread hervor: http://forum.openstreetmap.org/viewtopic.php?id=1284

Um sowas komplett zu lösen muss generell erstmal eine sinnvolle Lösung für das taggen von einzelnen Lanes, nicht Ways her. Da muss man aber direkt gleich über die API nachdenken. Die jetzige Lösung ist in den Möglichkeiten sehr beschränkt, Notlösungen über Relationen und backward / forward sehr fehleranfällig. Es reicht wenn einer den Weg dreht und der Fehler nicht sofort bermerkt wird. Schon ist die ganze Straße im Eimer, nichts stimmt mehr. Bei der Masse an Straßen ein unkalkulierbares Risiko. Es sind ja nicht nur Beschränkungen die da mit dranhängen. Eine komplett getaggte Straße hat unter anderem nicht baulich getrennte Park, Rad, Fuß, Bus oder was weiß ich noch für Streifen und Zusatzangaben. Das muss man mangels Alternative alles getrennt für beide Seiten an einen Weg hängen. Bei vielen sich abwechselnden Situationen, muss man das ganze auch noch übel zerhackstückeln. Ich müsste in einem Fall z.B. 300m Dorfstraße schon alleine wegen eines abwechselnden Fußweges in 8 Teile unterteilen, andere Angaben noch nicht mit drin. Am Ende hat man keine Wege sondern wahrlich einen Hackepeter. Hier fehlt das, was ich aus meiner Arbeit gewohnt bin. Splines für Kurven, was Arbeit und Ressourcen spart. Die Möglichkleit eine Situation zwischen zwei Stützpunkten/Nodes festzulegen, ohne diesen zerstückeln zu müssen. Und die Möglichkeit aus einer gezogenen Linie, welche den Mittelpunkt darstellt, automatisch beliebige Lanes generieren zu lassen, was gerade in diesem Fall sehr wichtig ist.

Man sollte das drehen von wegen verbieten! Ansonsten muss ich dir Recht geben. Ich bin aber - wie du - auch der Meinung, dass sowas über die API geregelt werden müsste.

Das hat damit, finde ich, nichts zu tun. Es geht hier um Beschränkungen, die für das komplette Objekt gelten, das damit getaggt ist, sei das ein Highway, eine Spur … Zeiten, Verkehrsmittel, Wetter usw. sind gar nicht von Spuren betroffen. Das einzige auf den ersten Blick ähnliche ist forward/backward, und auch das ist nicht dasselbe. So kann es sein, dass sich die Höchstgeschwindigkeiten für die Spuren in eine Richtung unterscheiden. Andersherum bin ich erst gestern an einer Stelle vorbeigekommen, die anscheinend von manchen Verkehrsmitteln in beide Richtungen befahren werden darf, von anderen nur in einer – und das ist eine einspurige Fahrbahn. Die Aussage, in welche Richtung eine Beschränkung gilt, ist also etwas anderes als die Aussage, auf welcher Spur sie gilt. Da ein Beschränkungs-Tagging auch ohne weiteres auf Lanes angewendet werden kann, sofern diese einzelne Objekte sind (oder auch nur: sofern eine Lane-Lösung beliebiges Tagging erlaubt, was m. E. eine Minimalanforderung an ein solches Konzept ist), sehe ich auch kein Problem damit, die Fragestellungen unabhängig voneinander zu betrachten.

Das find ich aus dem Grund etwas unschön, dass es zwei unterschiedliche Lesarten mit gleicher Syntax sind. So etwas wie maxspeed:a:b = x kann dann eben sowohl heißen “maxspeed = x, wenn a und b erfüllt sind (und nicht irgendwo noch ein maxspeed:a:b:c steht)” als auch “maxspeed:a gilt nur wenn b=x” Der Doppelpunkt ist hier ein wenig überfrachtet. Generell finde ich es eigentlich einleuchtender, alle Bedingungen, die erfüllt sein müssen, in den Key zu schreiben. maxspeed:a&b&c=x bedeutet dann eben: maxspeed ist x, wenn a und b und c erfüllt sind, wobei “genauer passende” Regeln bevorzugt werden. Übrigens: Als Trenner bin ich jetzt spontan auf ein & gekommen – das spiegelt die Bedeutung nämlich ziemlich gut wider: logisches “und”. Wird auch m.W. noch selten für irgendwas verwendet. Den Doppelpunkt könnte man gerne auch durch was anderes ersetzen, aber so Sachen wie name:de verwenden ihn eigentlich genauso: name ist x, wenn Sprache de.

@Tordanik: Hast du dir den Thread den ich gelinkt habe durchgelesen? Da habe ich nämlich auf die gleiche Problematik hingewiesen. Die Existiert überigens auch schon bei addr:housenumber im Vergleich mit name:de. Ich denke nachwievor, dass wir für solch

Ich hatte den schon zu seiner Erstellungszeit verfolgt und jetzt vor meinem Post noch mal gelesen.

Etwas in der Art maxspeed:hgv&time=Sa 00:00-18:00 = 70 wobei es mir jetzt nicht um das exakte Zeitformat geht. Und um das Beispiel “maxspeed bei Gewicht über 3.5 t” aus dem verlinkten Thread noch mal aufzugreifen: maxspeed = <Geschwindigkeit in km/h> maxspeed:weight>3.5 = <Geschwindigkeit in km/h> __DEPENDED oder so ist unnötig, da die spezifischste Angabe gültig ist, das ist m.E. mapperfreundlicher. Den Wertebereich für “3.5” (die implizierten Tonnen) hab ich jetzt mal von maxweight übernommen, das könnte man ganz ähnlich auch für length, width, height, axleload etc. machen. Die beiden unterschiedlichen Trenner : und & halte ich deshalb für ok, weil die “Bedingungen” etwas anderes sind als eine hierarchische Struktur. Insbesondere ist dort nämlich die Reihenfolge untereinander egal – anders als bei addr:housenumber oder auch der Trennung zwischen maxspeed und den Bedingungen in meinem Beispiel. Die Verwendung des Doppelpunkts nach maxspeed erfolgt – um mal wieder auf den alten Thread Bezug zu nehmen – im Sinne der Semantik c) “Parametrisierung”. Der Parameter ist eben, wenn man so will, ein sehr reduzierter boolescher Ausdruck, den man für eine bestimmte Situation auf “trifft zu” oder “trifft nicht zu” auswerten kann. Deshalb darf der m.E. auch Vergleichsoperatoren enthalten, ohne die Trennung zwischen Schlüssel und Wert zu verletzen, der Post von MADetter überzeugt mich da nicht. (Nebenbei: Ich hätte auch nichts dagegen, für “Parametrisierung” eine eigene Syntax zu verwenden (Klammern z.B.), aber da verlässt man wieder die ausgetretenen Pfade von name:de und Konsorten. Ist vermutlich auch nicht nötig.)

Eine normale Straße besteht aus zwei Spuren, eine Schnellstraße oder Autobahn aus zwei Richtungsfahrbahnen, die auch so gezeichnet werden, aber dennoch jeweils aus zwei oder oder mehr Spuren besteht. Oft sind Situationen an eine Spur und nicht an ein ganzes Objekt gebunden. Klar gilt z.B. ein Tempo 70 auch auf der Gegenfahrbahn einer normalen Straße und gilt somit für das ganze Objekt. Das ist aber z.B. nicht der Fall, wenn gleichzeitig ein Überholverbot per Zeichen oder per durchgezogener Linie besteht. Dann ist die Gegenrichtung für mich gesperrt. Zudem beginnt und endet die Beschränkung auch nicht immer auf gleicher Höhe. Solche Situationen finden sich bei 90% aller scharfen Kurfen, bei überqueren von Bergen oder Kreuzungen bzw. Abzweigungen oder vor Kreisverkehren. Das kann ich nur virteuell beschreiben, da ich real keine zwei Spuren, sondern nur einen Weg als ganzes habe. Es ist bisher eben nicht möglich die Situation direkt physisch auf die betroffene Spur anzuwenden. Wir haben nur die Notlösung etwas virtuell in Stückwerk zu beschreiben, was allerdings sehr fehleranfällig ist. Ich habe hier viele Situtionen für die es entweder noch garkeine Lösung gibt, oder wo es aufgrund fehlender physischer Spuren nur kompliziert mit der virtuellen Notlösung geht. Ich habe das bisher größtenteils gelassen. Das wird zu einem unüberschaubaren Chaos, wo einzig der Ortskundige anhand seiner Unterlagen den Überblick behalten kann. Das zu kontrollieren ist eine Lebensaufgabe. Das mag in Orten mit vielen Mappern vielleicht noch gehen. Doch in der Fläche ist man so ziemlich Einzellkämpfer. Das wird sich auch nicht großartig ändern. Der mögliche Nachwuchs zieht entweder früh weg, der kleine Rest hat kaum Interesse. Einzig nicht Ortskundige schauen ab und an mal vorbei und doktern per Ferdiagnose herum, oftmals leider auch fehlerhaft. Wenn ich mir über Beschränkungen bzw. generell Situationen eines Objektes Gedanken mache, muss dafür erstmal eine geeignete Basis her. Da sind wir ehrlich gasagt noch garnicht angelangt. Wenn wir da angelangt sind, wird das tagging der jeweiligen Situationen auch um einiges einfacher. Denn die ganzen virtuellen Hilfen und dutzende Relationen sind hinfällig. Siehe z.B. Richtungsspuren mit Richtungsvorgaben. Das wird bisher entweder ganz unterschlagen oder über Verbiegungen zusammengeklöppelt. Wie schnell und einfach das doch ginge, wenn man aus der RiFa an der Stelle einfach 3 Spuren generiert und die Richtungen direkt in jeder Spur angeben kann. Einfach, schnell, unkompliziert, wenig Fehleranfälligkeit und extrem Überschaubar für den Gelegenheitsmpper, der bisher aufrgrund solch komplizierter Konstrukte die Finger von gelassen hat…

@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.