Maxspeed bei nassen Straßen

Es gibt ja immer wieder auf Autobahnen, sowie gelegentlich auch auf Landstraßen ein Geschwindkeitsbegrenzungsschild mit Zusatzschild “bei Nässe”. Kann man das irgendwie taggen?

Hallo, für diese Einschränkung gibt es (noch) keine Tags. Wenn du Lust hast kannst du ja einen entsprechenden Vorschlag machen. http://wiki.openstreetmap.org/wiki/Creating_a_proposal

Auch wenn ich niemanden davon abhalten will, hier eine Insellösung zu schaffen, fände ich es doch erstrebenswert, wenn man gleich noch ähnliche Probleme mit löst (oder zumindest eine damit kompatible Lösung schafft), etwa fahrzeugtyp- und richtungsabhängigen maxspeed. (Edit:) Und um einen Vorschlag nicht schuldig zu bleiben, wie wärs damit, einfach sämtliche Bedingungen, die für einen Maxspeed gelten, mit Doppelpunkten getrennt hinter maxspeed in den Key zu schreiben? Also maxspeed:wet=80 für Höchstgeschwindigkeit bei Nässe maxspeed:hgv=100 für Höchstgeschwindigkeit für hgv (LKW) maxspeed:hgv:wet=70 für Höchstgeschwindigkeit für hgv bei Nässe maxspeed:hgv=100 für Höchstgeschwindigkeit für hgv (LKW) maxspeed:hgv:backward=75 für Höchstgeschwindigket für hgv entgegen der Wegrichtung u.ä.?

Find ich gut!

Grundsätzlich vernünftig - das gleiche gibt’s ja anderswo auch, z.B. bei name und künftig hoffentlich auch bei collection_times. Man sollte nur darauf achten, dass man vorher schaut, ob es die Kürzel schon bei anderen Keys gibt, damit man die gleichen verwendet. Sonst haben wir nachher unterschiedliche Bezeichnungen für den gleichen Sachverhalt, auch wenn es einmal um Straßen und einmal um Häuser geht oder was auch immer. Und man muss die Skalierbarkeit im Auge behalten. In diesem Falle wurde z.B. noch nicht erwähnt, dass es auch (uhr)zeitlich begrenzte Geschwindigkeits-Vorgaben gibt. Auch die müssen sich mit dem gleichen Schema erschlagen lassen, und dabei (Absatz oben) sollte möglichst nach der bestehenden Syntax für Zeiten verfahren werden, wie sie z.B. bei collection_times zur Anwendung kommt, weil es bei opening_hours auch so gemacht wird. Dies nur als mehr allgemeiner Gedanke zum Thema :wink: Edit: Typo

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.