Hallo,
in meiner Gegend gibt es neuerdings vermehrt tageszeitabhängige Geschwindigkeitslimits innerhalb von Ortschaften. Tagsüber 6-22 Uhr sind die üblichen 50 km/h erlaubt; nachts 22 - 6 Uhr sind nur 30 km/h.
Wie sollte man das mappen?
Gleiche Frage für die installierte speed_camera.
Gruß
Rainer
Die Frage wird etwa einmal in der Woche gestellt, zuletzt hier und hier. Eine klare Antwort gibt es dabei üblicherweise nicht da die möglichen Tag Kombinationen umstritten sind.
Nach http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags wäre das dann
maxspeed:(Mo-Su 06:00-22:00) = 50
maxspeed:(Mo-Su 22:00-06:00) = 50
Ähnlicher Diskussionsstoff:
http://forum.openstreetmap.org/viewtopic.php?id=12100
http://forum.openstreetmap.org/viewtopic.php?pid=108927
Dieses Proposal ist mit Pauken und Trompeten durchgefallen - abgelehnt worden. Man hat nur “vergessen”, das deutlich reinzuschreiben.
Gruss
walter
Tja, wer nur akzeptierte Proposals verwenden will, hat bei dem Thema nur eine Wahl: Gar nicht taggen und einen note für die Zeit setzen, wenn wir das Thema endlich alle satt haben und einfach dem nächstbesten Proposal zustimmen - oder auf die Idee kommen, dass eine 50%-Mehrheit bei mehr als 2 Alternativen ein Problem sein kann. 
Bei mir ist dieser Punkt nach über drei Jahren allmählich erreicht.
Ich habe mich entschlossen, die Sache mit den Proposals auch relativ locker zu sehen. Relevant für mich ist, was sich “so oder so” bei der Gemeinde durchsetzt (taginfo), was in Editoren eingebaut wurde (presets) und was auch wirklich ausgewertet wird.
Nur wenn man sich dann auf ein abgelehntes Proposal bezieht, dieses fast nirgendwo verwendet wird und die anderen Randbedingungen auch nicht zutreffen, werd ich schon mal ein wenig kiebig.
Es kann halt nicht immer so klappen, wie bei den Öffnungszeiten - Nochmals Danke, Wolf.
Gruss
walter
Moin,
Eine nach einem Proposal wohldefinierte Form, die nicht mit vorherigen Tags kollidiert und einfach nicht weiter ausgewertet wird, ist doch nichts anderes als eine note=* - und auch nicht schädlicher.
Sie hat aber den Vorteil, dass sie zukünftig deutlich einfacher automatisch in eine neu-definierte Form überführt werden kann als eine note=*.
Edit:
Und das mit Taginfo kann sich dann ganz schnell erledigen - was oft auch zur nächsten erfüllten Randbedingung führt. 
Und selbst wenn es zwei oder wenige mehrere verschiedene, aber eindeutige Formen sind, lassen sie sich immer noch zukünftig besser vereinheitlichen.
Insofern ist die Info dort vorerst gut aufgehoben - besser als gar nicht und auch besser als auf’m Schmierzettel (note).
Gruß
Georg
Etwas Offtopic: Bei Taginfo & co immer vorsichtig sein. Das kann auch einfach nur ein großer Import gewesen sein und schon hat ein undokumentierter, unabgestimmter Tag eine große Anzahl an Einträgen in der DB, aber verwendet wird er von den Mappern trotzdem nicht.
ich würde maxspeed=30 + maxspeed:(Mo-Su 06:00-22:00)=50 mappen. So ist wenigstens eine Information in einem etablierten Tag
Thomas, würde ich genau andersrum eintragen. Der Verkehr rollt primär zwischen 6 und 22 Uhr. Diese Geschwindigkeit dürfte also mehr Leute interessieren und daher sinnvoller in dem allgemeinen Tag aufgehoben sein.
Klar, die Infos, die da drin stehen mit allem Pro und Contra, sind durchaus für weitere Schritte wichtig.
Nur wurde dieses “abgelehnte” Proposal ganz locker in einer Tagging-Diskussion verwendet “Nach http://wiki.openstreetmap.org/wiki/Prop … ccess_tags wäre das dann” - und ich gehe mal davon aus, dass der Zitierende das noch nicht einmal gemerkt hat.
Gruss
walter
@thomas: jo, besser so als der Original-Vorschlag.
gibt für beides Argumente und ich würde sowas auch nicht korrigieren, wenn ich es irgendwo sehen würde. Ich dachte mir, was schlimmer wäre. 30 statt 50 zu fahren oder 50 statt 30.
1+
Wie man´s macht, macht man´s verkehrt … 
Da ist wenigstens Verlaß drauf. 
Fröhliche Vor-Wochenend-Grüße
Georg
Für die Freunde dieses kaputten Proposals: Bitte denkt euch wenigstens ein Tag-Format aus, wo die erweiteren Infos wie die “opening_hours” mit im Wert stehen und der Key max. einen (variablen) Subkey hat, weil dann könnte es vielleicht irgendwann mal ausgewertet werden, wenn jemand das Value-Feld parsen möchte. Der Vorschlag aus dem Proposal hat keinen Nutzen, in Hinblick auf die Auswertung durch Rechner, außer den Speicherbedarf der Datenbank zu erhöhen.
Ich nutze Netzwolfs Angaben (Öffnungs-, Leerungs- Servicezeiten) die auch hier zu finden sind.
Auswerteroutinen hat Netzwolf auch vorgeschlagen, es müsste nur umgesetzt werden. In seinen Auswertungen gibt es schon gute Beispiele.
Eigentlich habe ich ja inzwischen verstanden, dass eine Lösung, die den Großteil der Komplexität in den Wert packt, besser zum üblichen Tagging passt. Und ja, wenn ich noch mal die Motivation und den Anlass haben sollte, mich mit dem Thema zu beschäftigen, wird das im Rahmen einer Lösung sein, die Zeitintervalle u.ä. in den Wert packt.
Trotzdem finde ich solche unnötigen und inhaltlich irreführenden Kommentare einfach nur nervig. Die Fähigkeiten von “Rechnern” enden nicht am Tellerrand deiner eigenen Toolchain. Wenn du ernsthaft versuchen würdest, solche Information auszuwerten, würdest du vielleicht merken, dass das Ablegen eines Wertes mit allen möglichen Bedingungen ohne Filtern oder Vorverarbeitung während des Datenbank-Imports auch nicht so ganz das Optimum ist und sich die Lösungen daher gar nicht so viel geben. Und dass der Großteil des Zeitaufwandes, z.B. zeitabhängiges Routing zu entwickeln, ganz woanders liegt - nämlich bei der eigentlichen algorithmischen Umsetzung. Ob da ein bisschen Konvertierung und Verarbeitung beim Aufbau der Datenbank erfolgt, fällt dem gegenüber praktisch nicht mehr ins Gewicht.
Also, für die Kritiker dieses Proposals: Bitte beschränkt euch bei eurer Kritik auf sachliche Aussagen wie “es ist umständlicher bei der Auswertung, weil es nicht zu gängigen Datenbankschemata passt”, statt mit Übertreibungen wie “hat keinen Nutzen, in Hinblick auf die Auswertung durch Rechner” zu arbeiten.
Was ist denn mit den “Restrictions”?
http://wiki.openstreetmap.org/wiki/Relation:restriction#Time_Based_Speed_Limits
Ich bekomme da zwar nur Fehlermeldungen, aber das sieht doch irgendwie offiziel aus.
Herzlich willkommen im Forum
Der erste Satz der englischen Fassung sagt es in aller Deutlichkeit:
This is a proposal for a set of tags and members making a Relation to represent a restriction …
Dumm nur, dass der Satz in anderen Sprachversionen zum Teil nicht enthalten ist.
Insgesamt erweckt der Artikel (un)beabsichtigt den Eindruck, ein normaler Artikel zu sein und kein Vorschlag. Das ist natürlich problematisch, insbesondere wo ein Teil (Abbiege-Beschränkungen) in der Tat etabliert ist, die Erweiterungen (Zeit, Maxspeed, …) jedoch nicht.
Edbert (EvanE)
Danke für das Willkommen und die Info. Hatte ich so in der Tat nicht wahrgenommen.