http://osmtools.de/traffic_signs/
Ich habe hier Beschilderung:
maxweight=3.5 und Anlieger frei.
Tool spuckt nur aus:
maxweight=3.5
traffic_sign=DE:262:5.5;DE:1020-30
Fliesst das “Anlieger frei” nicht mit destination irgendwo mit in das tagging?
access=destination
Das kommt, wenn man z.B. Das Blaue Fahrradschild und das Rote Autoschild nimmt und dann Anliefer-Frei hinzufügt.
ich würde hgv=destination taggen. access=destination, was das Tool irgendwie zu mögen scheint, schließt vom Fussgänger bis zum Schneemobil alles ein.
@dennis
Nö, dann wuerde die Anliegerbeschraenkung fuer alle gelten.
Ich taGGE ALSO
maxweight=3.5
hgv=destination
traffic_sign=DE:262:5.5;DE:1020-30
(Theoretisch wäre ja maxweight=3.5;destination garnicht schlecht…)
Die Bedeutung der Kombination ist ja: Maximales Gewicht ist 5,5t, wobei Anlieger schwerer sein dürfen.
Mit einer allgemeinen Zugangsbeschränkung (hgv=destination) hat das überhaupt nichts zu tun. Von daher dies nicht nutzen. Ich würde eher etwas wie maxwight=5.5 maxwight:destination=no nutzen.
er hatte oben 3,5t geschrieben. Daher meine Idee, die auszuschliessen, die mehr als 3,5t wiegen. Da gehört eigentlich psv noch dazu, also hsv=destination, psv=destination ohne maxweight, was man als note ergänzen könnte. Habe gerade mal geschaut, der Hummer H1 wiegt 3559kg, würde also durchs Raster fallen. maxweight:destination wird ja vermutlich nicht ausgewertet. Da es laut MoTaBi aber bei seiner Straße um 12t geht, funktioniert das so nicht.
Generell finde ich es blöd, dass es keinen Standard für Einschränkungen von Beschränkungen gibt. Die Frage kommt ja regelmäßig
Hgv=destination passt in erster Näherung. Laut wiki sind damit Güterfahrzeuge ab 3.5 t gemeint waehrend das Schild sich auf alle Fahrzeuge ab 3.5t bezieht.
Jett fahren 3 verschiedene Zahlen rum.
Es geht um eine Ortsdurchfahrt,
maxw.= 3.5 Tonnen und ANlieger frei 
Aktuell ist es gerade auf
maxweight=3.5
maxweight:destination=no
Ich bin nach dem gegangen, was er in traffic_sign geschrieben hatte.
maxwight hat doch nichts mit dem eigentlichen access=* zutun. Von daher würde ich das auch raus halten. Zum anderen hebt für mich ein hgv=destination ein maxwight nicht auf.
Das Proposal von Tordanik deckt sich ja ungefähr mit meinem Vorschlag und halte ich im allgemeinen für zielführender, als sich irgendwelche Lösungen zu basteln, die bei einer kleinen Änderung eines wiki-Textes dann dahin sind.
Daher schrieb ich auch oben, dass das OHNE maxweight zu setzen wäre.
Tordaniks Proposal unterscheidet sich schon in der Struktur von Deinem Vorschlag access:weight>5.5 = destination versus maxweight:destination=no. Du tust doch auch nichts anderes als eine Lösung zu basteln, die morgen schon wieder ganz anders aussehen könnte, so nicht dokumentiert ist und in der Praxis nicht funktionieren wird. Tordaniks Proposal sagt ja etwas ganz anderes.
Die Struktur Deines Vorschlags gefällt mir allerdings besser als Tordaniks Proposal. Vielleicht no durch none ersetzen (analog zu maxspeed)…
Logisch muss sowas dann auch dokumentiert werden und klar ist alles eine Bastelei 
Etwas fertiges gibt es nicht.
Bei Tordanik gefällt mir recht gut, dass man mehrere Bedingungen verwenden kann. Allerdings ist es manchmal nicht ganz konsequent.
access:weight>5.5 = destination würde ich nach seinem Schema :<condition_1>:…:<condition_n>=* eher als maxwight:destination=* taggen. maxwight ist der basekey und destination die condition. (Evtl. gab es 2009 noch kein maxwight=* ?)
wie wäre sowas? Oben eine nicht vollständige Auswahl der möglichen Tags und unten ein paar Beispiele. Abwärtskompatibel mit bestehenden Beschränkungen wäre es auch und Dein Vorschlag ist enthalten.
Das läuft doch auch auf :<condition_1>:…:<condition_n>=value hinaus, oder?
Wobei ich die Zeit eher als Bedingung ansehen würde. Da würde ich dann keine Ausnahme machen. Das könnte verwirren.
yep, es ist ja nun keine bahnbrechende Erfindung. Es sollte nur mal einheitlich dokumentiert werden.
Ich finde Zeit ist ein Value, wie bspw bei Opening_Hours. Key/Conditions sind in der Anzahl recht beschränkt. Die Zeit kann in Kombination mit Wochentagen doch recht unterschiedlich sein also für mich eher ein Wert als ein Key. In bisherigen Vorschlägen stand sie immer im Value
http://forum.openstreetmap.org/viewtopic.php?id=10362
http://forum.openstreetmap.org/viewtopic.php?id=14589
http://forum.openstreetmap.org/viewtopic.php?id=8152
auch im Wiki stehts bei zeitlichen Beschränkungen so
http://wiki.openstreetmap.org/wiki/DE:Key:access#Zeitlich_begrenzte_Beschr.C3.A4nkungen
hmm. Also wenn man zwei Values hat, bspw zeitlich beschränkte Geschwindigkeitsbegrenzung, hat man zwei Möglichkeiten
maxspeed:30=07:00-18:00
oder
maxspeed:07:00-18:00=30
bei beiden Möglichkeiten schiebt man einen Wert, der anderswo im Value steht, in den Tag.
Genau…und ich finde das Zweitere eingängiger. Ist aber nur meine Meinung und eine Frage der Gewöhnung.
das Problem ist nicht nur auf die Zeit begrenzt auch bei Geschwindigkeitsbegrenzungen ab einem Gewicht verschwimmen die Key/Value Grenzen. Hilfreich ist dabei zu überlegen, was Bedingung (bspw Zeit) und was Beschränkung (Geschwindigkeit) ist. Ich habe die Tabelle mal umgestellt…auch wenn mir persönlich eine Zeit im Key nicht gefällt
Wobei ich jetzt ja eigentlich recht nah bei Tordaniks Proposal bin und es etwas erweitert habe.
