Zusatzschilder

Gibt es eigentlich für die, garnicht so selten vorkommenden, Zusatzschilder “Keine Wendemöglichkeit für LKW” und “Kein Winterdienst” schon reguläre Tags oder müßte man sich dabei mit ‘note=*’ weiterhelfen ?

mfG Michael

Laut Google hat z.B. das Zusatzschild für den LKW die StVO-Nr 2425 (http://www.absperr-schilder-technik.de/Verkehrszeichen-StVO-Fuer-Lkw-keine-Wendemoeglichkeit-Nr-2425.htm )

Meinst Du so etwas?

http://wiki.openstreetmap.org/wiki/DE:Road_signs_in_Germany

Bernd

Ja,o.k., die genaue Bezeichnung laut StVO lautet wohl “Zusatzzeichen”.

Im Einzelnen sieht’s so aus:

http://farm6.static.flickr.com/5202/5372245792_1473ac3cd5.jpg

http://img.fotocommunity.com/photos/11131232.jpg

winter_service=no scheint laut taginfo “recht” gebräuchlich zu sein, ist aber im wiki nicht dokumentiert.

Obwohl die Zusammenstellung etwas seltsam ist, Reiter/n verboten wenn Winter und/oder wenn nicht geräumt ist? :wink:

Bei dem anderen Schild würde ich ‘noexit=yes’ mit ‘traffic_sign=DE:2425’ nehmen

Kaufen kann man es hier :wink:
http://tinyurl.com/czsze6g

Bernd

noexit=yes passt aber nur, wenn es auch wirklich eine Sackgasse ist. Ansonsten würde ich mich hier wohl für ein noexit=hgv entscheiden.

Sackgasse für LKW wäre ‘traffic_sign=DE:357’ mit ‘traffic_sign=DE:1048-12’ bis ‘traffic_sign=DE:1048-16’

Diese Kombinationen habe ich aber noch nie gesehen

mehr dazu:
http://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_Deutschland

Bernd

Ist nicht mit dem Zusatz “keine Wendemöglichkeit” gemeint, daß die Sackgasse am Ende so eng ist, daß man da nur rückwärts heraus kommt?
noexit=yes wäre dann ja gegeben, aber die Problematik für den LKW nicht angezeigt.
In diesem Fall benötigt man ein für LKW-Karten speziell auswertbares Tag.

Die Kombination von Reitverbot und der Hinweis auf “kein Winterdienst” sieht gut aus. :smiley:
Das Reitverbot, ist zu befürchten, gilt aber wohl das ganze Jahr über. Schade.

Gruß
tippeltappel

Eine ebenso unpassende, aber gern genommene, Kombination ist Zeichen 240 (Fuß/Radweg)
mit Zeichen 1020-30 (Anlieger frei), mit letzterem wird die höherwertige Schutzfunktion des
ersten ad adsurdum geführt.

Bernd

Also fassen wir mal zusammen um nicht das Ganze wieder in’s Uferlose verlaufen zu lassen.:
Für Zusatzzeichen wie “Keine Wendemöglichkeit für LKW” und “Kein Winterdienst” gibt es derzeit keine Tags.
Das Sinnvollste erscheint also dies mit ‘note=*’ zu ergänzen.

mfG Michael

Das ist nicht ganz richtig, da winter_service=no ja bereits verwendet wird.
Das läßt sich doch gut auswerten.

Für Wendemöglichkeit spuckt LEO “turning option” aus.
Daraus kann man machen:
turning_option:hgv=no

Das entspricht der Syntax anderer Eigenschaftstags.

Gruß
tippeltappel

+1

Bernd

Das ist wohl richtig gesehen 100%ig richtig, denn ob’s verwendet wird oder ob es sich um einen regulären Tag aus dem Wiki handelt sind zwei paar Schuhe.
Ich kann mir auch dutzende von Tags ausdenken und irgendwo unterbringen, aber wem nutzt das was?
Wir wollen uns doch möglichst an Regeln halten und nicht noch Wasser auf die Saat der Anarchie gießen.

Was oder Wer ist eigentlich “LEO” ?
Wahrscheinlich ist’s wohl genau so wenig offiziell?!

Nein, nein, mit ‘note=*’ bin ich auf der sicheren Seite und kann nichts falsch machen.

mfG

Das ist leo:
http://dict.leo.org/

Natürlich bist du mit note auf der sicheren Seite. Aber du kannst es auch genau so gut weglassen. Weil ein Routingprogramm wird sich nicht um deine Notiz scherren. Höchstens ein anderer Mapper, der zufällig in der Region über deine Notiz stolpert kann damit etwas anfangen, wenn er der Sprache mächtig ist in der du die Notiz verfasst hast.
Es bleibt deine freie Entscheidung was du tust. Aber wundere dich nicht wenn diese Information ungehört/ungelsen in der Datenbank stehen bleibt.

Am sinnvollsten ist vollkommen unabhängig von der konkreten Situation das Tag traffic_sign=…, weil man hiermit die exakte Lage abbildet, die nur mit Informationsverlust von den abstahierenden aber gängigen Tagging-Schemen abgebildet wird.

Außerdem könnte man - sofern mal ein Tag für deinen Problemfall gefunden wurde - dies direkt auf alle Fälle mit dem betreffenden traffic_sign übertragen. Bei note ist das definitiv nicht möglich!

Viele Grüße,
Malte

Das wäre auf jeden Fall das Sinnvollste, aber neben solchen katalogisierten Zusatzzeichen wie z.B. “Anlieger frei” gibt es auch jede Menge freier Zeichen wie die um jenes es hier im Thema ging und diese alle zu erfassen würde wohl etwas den Rahmen sprengen.
Bedenkt man nun auch noch die verschiedensten Zusatzzeichen die es international gibt, so bräuchte man wohl schon fast einen eigenen Server nur für diese. :wink:

Die Argumentation, dass ‘note=*’ nicht ausgewertet wird verstehe ich zwar, sehe es aber eher als Manko.
Wie viele Tags werden denn überhaupt ausgewertet? - ich glaube kaum 20%.
Da wäre es doch sinnvoller einen Universaltag auszuwerten, aber was versteht nun wiederum unter Auswertung?
Ich stelle mir unter einer sinnvollen Auswertung z.B. ein Popup-Menü vor welches auf einer Karte erscheint, sobald man mit dem Cursor über das Objekt fährt (nur mal als Beispiel) in welchem dann alle zusätzlichen Infos angezeigt werden.
Ich weiß jetzt nicht ob das in OSM noch “Zukunftsmusik” ist oder ob es irgendwo schon Ähnliches gibt, aber man kennt es von professionellen Applikationen.

O.k., wie gesagt ich bleibe erstmal bei ‘note=*’ und wenn sich Jemand eventuell darüber nochmal konkrete Gedanken machen würde, fände ich dies begrüßenswert.

mfG Michael

Dieses Popup existiert in Garmin-Karten längst. Zumindest dann, wenn man die Karten im PC mit GarminMapSource oder auf einem GPS-Gerät wie das etrexVistaHCx anzeigen läßt.
Je nach dem, ob das Kartenobjekt einen Namen hat oder nicht, zeigt das Popup die Objektbezeichnung aus der Objektliste der Renderregeln oder den Objektnamen an.
Es ist möglich, in den Renderregeln festzulegen, daß keys ausgewählter Tags mit der Namensangabe kombiniert werden. Wenn man z.B. alle Seilbahnentypen mit einer schwarz gepunkteten Linie darstellen möchte, die in meiner Objektliste beispielsweise mit der Bezeichnung “Lift, Kabel, Stromleitung, Zaun” hinterlegt ist, dann kann man in den Renderregeln festlegen, daß im Popup ein z.B. aus dem Tag/Key aerialway=* eine bestimmte Bezeichnung für den arialway-Typ generiert und vor dem für die Strecke eventuel hinterlegten Namen angezeigt wird. Oder ich erzeuge eine Renderregel, die aus barrier=fence z.B. Begrenzung=Zaun macht, schleife dieses Ergebnis zum Namen durch und lese dann im Popup auf der Karte “Zaun”.

Das Tag “note=*” hat für das Rendern einer Karte geringe bis keine Bedeutung. Es sei denn, man schleift dessen Inhalt in die Namensanzeige durch oder nutzt einen anderen mir nicht bekannten Weg, ihn in die info-Anzeige im Eigenschaftsfenster (etrexVHCx) durchzuschleifen. Das ist aber nur bei der Verwendung bestimmter Garmin-IDs möglich. Da das Note-Tag für die unterschiedlichsten Informationen genutzt wird und sehr umfangreich sein kann, macht das Durchschleifen in die Namensanzeige nicht viel Sinn. Zum Generieren von Kartenobjekten ist das note-Tag untauglich.
Das von mir vorgeschlagene Tag ist dagegen eine sinnvolle Ergänzung des vorhandenen Tag-Schemas und kann daher problemlos von Renderern aufgegriffen und im Wiki ergänzt werden. Hängt die Eigenschaft turning_option:hgv=no an einer Straße, würde ich für eine Garmin-Karte bei gegebenem Interesse (z.B. in einer Lastwagen-Karte) entweder aus turning_option:hgv=no das Ersatz-Tag Hinweis=Keine Wendemöglichkeit für LKW generieren, um diesen Hinweis in die Namensanzeige der Straße durchzuschleifen oder aus dem englischen Tag eine POI-Anzeige mit geeignetem Symbol generieren, das in der Objektliste mit der Bezeichnung “Keine Wendemöglichkeit” hinterlegt ist. Man könnte statt des Symbols auch ein Linienoverlay generieren, das die gesamte Wegstrecke beispielsweise mit kurzen Querbalken in einer bestimmten Farbe markiert. Wenn dieses Overlay in der Objektliste des Renderprogramms mit der Objektbezeichnung “keine Wendemöglichkeit” hinterlegt ist, kann man diese Objektbezeichnung mit dem Mauszeiger abrufen.

Möchte man nicht für jedes denkbare Hinweisschild ein eigenes Symbol hinterlegen, wählt man ein für diesen Zweck geeignes Universal-Symbol aus und unterdrückt die im Renderprogramm hinterlegte Objektbezeichnung in der Karte, indem man den Key des Ersatz-Tags Hinweis=* als Name rendert. Das Symbol wird bei dieser Vorgehensweise irgendwo auf der Straße angezeigt und wenn man es mit dem Mauszeiger berührt ploppt der “Name” “Keine Wendemöglichkeit” auf. Da es sinnvoller sein kann, das Symbol für das Hinweis-Schild auf der Karte dort anzuzeigen, wo das Schild steht, müßte man auch an den entsprechenden node der Linie das Tag hinterlegen. Dann wird das Schildsymbol exakt an dieser Stelle angezeigt.
Mit dieser Methode läßt sich im Prinzip jedes Schild sichtbar machen.

Um die Anzeige generell aller Zusatzschilder zu ermöglichen, sollte man vielleicht besser zwischen der Eigenschaft der Straße (kein Winterdienst, keine Wendemöglichkeit), die man mit einem Linienoverlay sichtbar machen kann und der Anzeige eines Schildstandortes (node) unterscheiden. Hierfür gibt es das bereits erwähnte traffic_sign-Schema. Allerdings würde ich es für die Zusatzschilder ein wenig modifizieren:

 traffic_sign=addition
 addition:de= deutscher Text (wie er auf dem Schild steht)
 addition=englische Übersetzung (als zusätzliche Option)

Nun kann man in den Renderregeln bestimmen, daß ein Universal-Symbol für “addition”/“Zusatzschild” angezeigt wird und der Text des Schildes als “Name” aufploppt. In Karten ohne Popup muß man per Renderregel dafür sorgen, daß aus addition:de ein “Name” generiert wird, der am Schild angezeigt wird.

Wenn man weiß, wie es geht, ist das einmal etwas Arbeit und dann hat man alle denkbaren Varianten von Zusatzschildern erfaßt - vorausgesetzt, man macht vorgeschlagenes Tagging-Schema auf der wiki-Seite publik und alle halten sich daran. :wink:

Gruß
tippeltappel

Es ist immer eine Frage dessen was du erreichen möchtest. Wenn du nur die Information in einem Popup für ein Objekt verstecken möchtest, dann ist das technisch heute schon relativ problemlos möglich. Siehe openlinkmap oder auch die Hundekottütenspender wo die Möglichkeiten des Vectorlayers diskutiert wurden.
Allerdings setzt das vorraus, dass du mit der Maus die geplante Route vorher abfährst und dann zufällig auf diese Objekte stößt. Sie sind ja noch nichtmal zu sehen im normalen Anzeigemodus.
Wenn du hingegen ein automatisches Routing durchführst, dann erwartest du dass die gefunde Route deinen Ansprüchen genügt. Und dann ist es eben schlecht wenn dort kein Winterdienst ist im Winter. Da das aber im note=* steht ist es für die Routingsoftware nicht zu finden.
Außerdem ist note=* ein sogenanntes Freitextfeld. Für ein Computer ist es eben ein Unterschied ob da steht: kein Winterdienst oder no winterservice oder in welcher Sprache auch immer die Notiz sein möge. Selbst du als Mensch wirst dich schwer damit tun, wenn es jetzt in russischer Sprache oder hebräisch sein würde. Daher gibt es ja diese Tags, welche automatisch auswertbar sein sollen.
Wenn man sich mal den Standard Mapnik style anschaut sieht man aber schnell wie komplex die Dinge werden können. Wann zeichnet man was. Während es für einen Menschen leicht verständlich ist, dass Flächen mit layer=1 auch über Linien ohne Layer angaben liegen sollten, wird es in der XML Sprache alles andere als leicht all diese Sachen umzusetzen. Vor allem weil man alle möglichen Varianten berücksichtigen sollte. und nicht nur die Fläche mit Layer=1 denn auch die Fläche mit Layer=2 etc.