Meine Begründung ist das einerseits eine Gefahr besteht, dass für Beschränkungen die bereits ein dediziertes Tag für die Nutzung besteht ein traffic_sign Wert verwendet wird (maxspeed, maxweight etc), und anderseits, dass das so oder so keiner in der Produktion auswertet.
Jetzt ist es natürlich so, dass durch die Einschränkung niemand daran gehindert wird ein traffic_sign Wert auf einer Strasse einzutragen. Einerseits kann man sich in Vespucci und JOSM einfach eine entsprechende Vorlage installieren, oder das ganze händisch einzutragen (in iD aktuell die einzige Möglichkeit).
Mir scheint, dass das aktuell gerade die Grenze zu sein zwischen Sachen die vernünftigerweise in eine Standardvorlage gehören und Tagging das in eine themaspezifischen Vorlage gehört.
Ich würde mich aber für eure Meinungen dazu interessieren.
traffic_sign wird in Deutschland intensiv dazu genutzt die Quelle für irgenwelche Beschränkungen auf Wege einzutragen.
an Rad- und Fußwegen um nachvollziehbar zu machen ob foot und bicycle auf korrekterweise auf yes oder designated sind und ist die einzige Möglichkeit am Radweg nachzuvollziehen ob er benutzungspflichtig ist oder nicht. (siehe DE:Bicycle/Radverkehrsanlagen kartieren - OpenStreetMap Wiki)
an Straßen und Tracks um die access-Tags nachvollziehbar zu machen (siehe z.B. Verkehrszeichen Tool - OpenStreetMap)
(auch für Fußgängerzonen, Verkehrsberuhigte Bereiche, Fahrradstraßen).
Natürlich könnte man zur Dokumentation auch die einzelnen Zeichen erfassen, aber das ist aufwendiger und ich tue das nur wenn die Beschilderung fehler- oder lückenhaft ist.
Die Erfassung von Maxspeed-Zeichen an Straßen finde ich persönlich sinnlos das lässt sich genug über maxspeed:type etc abbilden.
Ich tagge inzwischen auch traffic_sign an ways um die access Regeln zu begründen bzw. zu ergänzen. Einige Regeln, die wir nicht taggen (können), können vom VZ abgeleitet werden. Z.B. wird kaum horse=no bei Zeichen 237/239/240/241 getaggt oder maxspeed=walk bei Zeichen 239 + Rad frei.
ich denke es ist am besten, diesen tag für Verkehrszeichen zu nutzen, für die Auswirkungen auf die Straße bzw. Strecke haben wir bereits andere tags, und der Sinn den ich im Verkehrszeichenmapping sehe, nämlich direkte Beobachtungen (an dieser Stelle steht so ein Zeichen und zeigt in diese Richtung), und die daraus abgeleitete (interpretierte) Bedeutung (wo das gelten soll und was es bedeutet im Zusammenhang mit dem Kontext), zu trennen, würde entfallen wenn man das vermischt.
Es stimmt aber wohl dass es einige Mapper gibt, die den tag eher als repetitive Bestätigung etablierter tags an die Straße machen, mutmaßlich weil sie den Standardtags nicht trauen.
kommt wohl auch auf die Jurisdiktion an, in Italien gelten maxspeed Zeichen z.B. nur bis zur nächsten Kreuzung, wenn das Verbot dort nicht wiederholt wird ist es automatisch aufgehoben
Wenn die Frage ob es sinnvoll ist so zu taggen auch interessant ist, eigentlich hab ich danach gefragt ob so was in eine Standardvorlage gehört (mal abgesehen davon von den praktischen Schwierigkeiten die es verursachen würde).
traffic_sign=DE:295 wäre an einem Weg durchaus korrekt.
Ansonsten ist die Verwendung von typischerweise Punktobjekten an Wegen … hmm … zweifelhaft, spätestens dann, wenn sich Beschilderungen an beiden Enden widersprechen oder, wie hier schon oft diskutiert, gar nicht klar ist, ob das am Anfang des einen Feldweg aufgestellte Schild auch an allen anderen Zufahrten zu dieser Feldflur aufgestellt ist und die Verbote damit lückenlos gelten …
Ein access:type=DE:260 oder source:access=DE:250 oder so wäre meistens eher das, was gemeint ist … Oder note=Hier steht 'n x-Schild …
Ich würde das auch nicht auf Wegen hinterlassen. Wenn du ein Schild tagst dann steht das Schild ja an einer spezifischen Stelle und nicht auf einem Weg.
Das Schild hat dann möglicherweise ein Rechtswirkung auf eine Strecke - Also Strecken ver- bzw gebot. Das wird mitunter ja aber auch ganz anders getagged.
Deshalb würde ich das immer trennen.
Ich mappe Straßenschilder eigentlich eher als hilfe um dinge einzutragen. Also erst alle maxspeed signs, dann weiss man wie asymmetrisch das alles so ist, dann trage ich die maxspeeds auf der Straße ein.
Ich verstehe jetzt ehrlich gesagt Deine Frage nicht ganz. Du hast Vorlagen erstellt, die traffic_sign nur auf Punkten anbietet und nicht auf Ways, weil Du selbst darin keinen Mehrwert siehst und jetzt willst Du wissen, ob wir der Meinung sind, dass die Vorlage(n?) auch auf Wegen angeboten werden sollen?
Ja sicher doch[1]! Aber wenn Du keine Lust hast, dafür Zeit aufzuwenden, weil sich der oder die Person im Ton vergriffen hat, sollte sie einfach einen PR erstellen und gut. Ich kenne die Beschwerde im Detail nicht, aber wenn man für das Bereitstellen einer kostenlosen Sache auch noch angepflaumt wird, hab ich auch wenig Lust, da etwas für jemanden extra zu machen. Der Ton macht die Musik und da schalte ich selbst auch mal gerne auf taub.
Ich bin großer Nutzer von traffic_sign:*=* an Wegen zur späteren Nachvollziehbarkeit gerade bei widersprüchlicher Beschilderung ↩︎
Die Frage war etwas anders: weder JOSM noch iD noch ich unterstützen in den Standardvorlagen (das was du angeboten bekommst wenn du nicht spezielles machst) traffic_sign auf Wegen und Flächen. Aber wenn man das trotzdem so eintragen will, kann man es natürlich, entweder händisch oder mit einer geeigneten Vorlage.
Die Frage war nun: ist der Zustand OK, oder sollte man in den Standardvorlagen das auch in irgendeiner Form unterstützen, sprich schlussendlich solches Tagging fördern. Der Aufwand dafür ist irgendwo zwischen null und sehr gross abhängig davon wie viele Schilder und.Länder man unterstützen will.
Ich würde das Unterstützen von traffic_signs an Wegen gutheißen. Es ist erlaubt und je nach Schild-Typ ist das Tagging an Wegen sogar häufiger als das an Nodes (z.B. bei 240 und 241). Außer bei maxspeed und city_limit (die eigentlich nur an Nodes getaggt werden) ist die Verteilung grundsätzlich fast 50:50. Von daher: sehr gerne, auch wenn mir klar ist, dass es viel Aufwand bedeuten kann.
Auch wenn ich selber traffic_sign=* an Wegen verwende und gut heiße, befürchte ich, dass es erstens viel Aufwand ist und die Standardvorlagen, wie z.B. “Fahrradweg”, damit doch sehr aufgebläht werden. Ein Problem sehe ich darin, dass es ja für jedes Land dann eine eigene Zeile für das Zeichen braucht.
Somit finde ich es OK, dass nur die Zeichen mit in Sprache übersetzte Schlüsselwerte als Standard angeboten werden und der Rest in Erweiterungen ausgelagert wird.
Welche Datei muss ich denn in Vespucci einbinden, damit das funktioniert? Ich sehe zwar neue Vorlagen, die setzen aber nur komische, unvollständige Tags.
Ich habe das hier eingebunden:
… beta_preset_josm-master/beta_preset_josm-master/DE/Presets_Traffic_signs-preset_DE.xml
Das Problem mit den Vorlagen ist, dass wenn man sie anwendet sie gar keine Werte setzen, sondern nur den Schlüssel, was dazu führt, dass Vespucci sie nicht von einander unterscheiden kann (und deshalb dann der Eintrag für “DE:” genommen wird).
tl;dr Ich werde wohl ein Fork davon machen nicht zuletzt da sie auch noch andere Merkwürdigkeiten haben, ich bitte also um ein bisschen Geduld.
Nerdiger Hintergrund: wenn du eine Vorlage in Vespucci anwendest werden den Elementen entsprechende Tags gesetzt, dann wird der “Matching” Algorithmus durchlaufen der die am besten passende Vorlage und alle anderen nochmals bestimmt.
Beispiel: du hast ein Polygon auf dem du building=yes, name=Test gesetzt hast, jetzt wendest du die Supermarkt Vorlage an, da wird shop=supermarket und viele andere Tags gesetzt. Dann wird bestimmt welche Vorlage jetzt tatsächlich am besten passt, dass wird in dem Fall tatsächlich Supermarkt sein. Alle Tags die nicht in der Supermarkt Vorlage vorkommen werden dann genommen und das ganze nochmals durchlaufen. Das ganze läuft bis es entweder keine nicht zugeordnete Tags mehr hat, oder keine Vorlagen mehr passen. In der Realität ist es noch ein Tick komplizierter da Tags von verlinkten Vorlagen, Adresstags, und Sprachvarianten von “namen-ähnlichen” Tags speziell behandelt werden.
Arrgh, ich hatte persönlich die Vorlage noch nicht getestet und benutze auch nur JOSM. Von daher:
war das wohl nicht richtig und in JOSM funktionieren zwar die Vorlagen, aber wirklich damit zu arbeiten scheint mir recht mühselig und Preset-Links in der “Tags/Memberships”-Liste werden auch in JOSM nicht erzeugt.
Sorry, da hatte ich gedacht, dass ich eine Lösung präsentieren kann, bin mit dem Ergebnis aber auch unzufrieden.
