Wandersymbol wird nicht so angezeigt wie gewünscht

Moin,
und zwar hätte ich gerne “StSp” in weiss auf rotem Grund.

Wird in waymarked trails so dargestellt:

Was ist an dem osmc:symbol falsch?

Ein Doppelpunkt “zuviel”.
Mit red:red::StSp:white erscheint der Text. Scheinbar ist Vordergrund2 ein Problem?
Hier kannst du es testen (ganz unten):
https://hiking.waymarkedtrails.org/osmc_symbols.html

Laut Online Preview auf OSMC Symbols sind drei Doppelpunkte richtig so

Mag sein das der Text zu breit ist und deshalb nicht gerendert wird …

Mal schauen was meine lokake Waymarked-Instaz meint …

“text zu breit” war Unsinn, beim X13 und BuPa gehts ja auch (letzerer allerdings ohne osmc:symbol).

Aber der X13 hat auch nur zwei Doppelpunkte, nicht drei

black:black::X2:white

PS: und ja, bei mir bekomme ich auch nur ein rotes Quadrat:

waymarkedtrails kennt foreground2 nicht.

The map only supports a subset of what is described on the Wiki page. In order to be rendered on the map, the tag must have the following format:

osmc:symbol=waycolor:background:foreground:text:textcolor
1 Like

OK, und wenn ich einen Doppelpunkt weglasse wird es in anderen Anwendungen hoffentlich noch korrekt dargestellt…

Da Wegsymbole heutzutage kaum noch gesprüht, sondern als Schild geklebt werden ist die Gestaltung bei neuen Wegen oft deutlich “kreativer” als sich mit osmc:symbol abbilden lässt.

Das ganze Konzept der Symbolbeschreibung hat sich somit eigentlich eh überlebt (und war schon von Anfang an nicht wirklich schön).

Aber da etwas neues zu implementieren und allgemein durchzusetzen, das würde auch ein Krampf werden. SVG zB. würde sich zwar für die Symbole anbieten, sprent aber das was man direkt in einem OSM-Tag unterbringen kann, es müste also eine externe Storage-Lösung dafür her die man referenzieren kann.

Und last not least lauert da auch wieder die Lizenzfalle: darf man ein Wegsymbol überhaupt kopieren? Bei den klassischen Sprühsymbolen war da keine “gestalterische Erfindungshöhe” auf die man sich urheberrechtlich berufen könnte, bei einigen neuen Wegsybolen dagegen durchaus …

Es bleibt schwiering … :frowning:

(und ich hab auch keine Lust mich da weiter reinzudenken und -knien)

Wahrscheinlich nicht…

Die momentane Syntax ist kaputt. Ein Intepreter kann nicht wissen, welchen optionalen Teil der Ersteller weggelassen hat [Diskussion_eng, Diskussion_deu]
Und die Beschreibungen in deutschem und englischem Wiki weichen auch voneinander ab.

Eigentlich ist nur die vollständige Beschreibung (wie du sie ursprüglich hattest) eindeutig. Setzen nur offenbar nicht alle Renderer um.

1 Like

Ich warte mal ab wie es in Osmand gerendert wird.

EDIT: hab jetzt einen Doppelpunkt entfernt.

Richtig… Andererseits ist die Syntax eindeutig genug um sie in allen zu erwartenden Fällen richtig interpretieren zu können. Die einzige Ausnahme ist, wenn keine zwei Vordergründe angegeben ist und der Text auf einem Schild genau einem möglichen Vordergrund entspricht. Das würde ich aber ausschließen wollen, dass so etwas tatsächlich in der Realität existiert.

@lonvia Wäre es eventuell möglich bei Waymarked-Trails den zweiten Vordergrund, falls angegeben zu ignorieren? Damit wäre das Problem oben umgangen. Dann würden Schilder mit leerem 2. Vordergrund korrekt angezeigt werden - nur solche mit einem 2. Vordergrund würden nicht ganz korrekt dargestellt.

Haben wir schon: Key:wiki:symbol - OpenStreetMap Wiki.

Solange die im Wiki notierte Syntax so wage bleibt, macht es nicht viel Sinn, etwas am Code in waymarkedtrails zu ändern. Egal wie man das interpretiert, jemand wir es immer so mappen, dass es nicht passt. Da ist es besser wenn waymarkedtrails in seiner Interpretation konsistent bleibt.

Wenn jemand sich aber mal die Arbeit macht und die Syntax überarbeitet (inklusive der ganzen Community-Diskussion, die das braucht), dann bin ich gerne bereit den Code dem neuen Konsens anzupassen.

Was mir als Datennutzer wichtig ist: man muss die Unterteile ihrer Funktion zuordnen können ohne das man den Wert genau kennt. Sprich sowas wie “red_triangle … das kann ja wegen dem triangle nur ein Vordergrund sein” ist keine gute Idee, denn dann lassen sich die Werte in der Zukunft schlecht erweitern.

Ausserdem macht es Sinn mal Richtung Amerika zu schauen, Da gibt es den Wunsch nach rechteckigen Grundformen. Ich fände, da könnte man die Interpretation von Backgraund mal überdenken. Im Augenblick ist ja nicht definiert, was die Grundform ist. Nop macht da ein Rechteck, waymarkedtrails ein Quadrat. Die Schweizer und die Schwarzwälder könnten davon auch profitieren mit ihren rhombischen Grundformen.

Ich bin mir nicht sicher - die notwendige Regel wäre “wenn 3 oder 5 Doppelpunkte vorhanden sind, wird der Dritte inklusive dem Text direkt dahinter verworfen”.
Das wäre dann auch so, wie es schon dokumentiert ist - “Ein zweiter Vordergrund wird nicht unterstützt.” Das ist etwas anderes als die jetztige Implementierung “Ein zweiter Vordergrund darf nicht vorhanden sein (auch nicht leer)”.

Es gibt laut Wiki 6 Möglichkeiten:

waycolor:background
waycolor:background:foreground
waycolor:background:foreground:foreground2
waycolor:background:foreground:text:textcolor
waycolor:background:foreground:foreground2:text:textcolor

Diese 5 würden problemlos unterstützt, abgesehen vom zweiten Vordergrund. Nur die 6. Variante würde Probleme machen:
waycolor:background:text:textcolor
Das kommt in der Datenbank aber auch nur in einem einzigen Value 15 Mal vor:
yellow:yellow:PR:black. Man könnte problemlos im Wiki in Form einer Empfehlung dokumentieren, hier einen leeren Vordergrund hinzuzufügen. Dafür bräuchte es keine größere Taggingdiskussion.

Also wäre die Syntax:

waycolor:background[:[foreground[:foreground]][:text:textcolor]]

Das wäre machbar.

Das hat waymarkedtrails zumindest ohnehin nicht unterstützt. Der Code hat gerade eine fixe Zuordnung von Position auf Funktion. Das heisst allerdings, dass auch das hier geht:

waycolor:background:foreground:text

Da waymarkedtrails das kann, ist es durchaus möglich, dass das in Benutztung ist, auch wenn eigentlich nicht so vorgesehen in der Spec.

Sieht hässlich aus, sollte aber eindeutig auswertbar sein und ist nur eine minimale Änderung gegenüber dem status quo.

Nach diesem Schema gibt es genau 2 Values:

yellow:brown:yellow_bar:CSA 39x
red:red:white_stripe:CdC 18x

Ich habe diesen Vorschlag im Wiki auf der Diskussionsseite eingefügt:
Talk:Key:osmc:symbol - OpenStreetMap Wiki