Talk:Key:osmc:symbol

From OpenStreetMap Wiki
Jump to navigation Jump to search

problems with the standard

I apologize, but I thinkg that the syntax of the standard is not very good. Three optional parts are very illogical or the syntax is written in a wrong way. If taken literally than the syntax

  osmc:symbol=waycolor:background[:foreground][[:foreground2]:text:textcolor]

means for example that

  1. You can not have two foreground symbols if you do not have the text label. (which is strange)
  2. There is noway to specify the symbol without background
  3. There is no easy way for the script to find out weather the text label was used or not and where is it located.
  4. According to syntax these things are very different, but hard to tell apart for a computer
  osmc:symbol=red:white:red_bar:x:blue  # red bar on white background with blue x on top of it
  osmc:symbol=red:white:red_bar:blue    # white background with blue text "red_bar" on top of it


Solutions

I do not have a solution which is both beautiful and backwards compatible (to some extend at least), but two directions come to my mind

Solution 1. Making the empty value possible (both for background and foreground) and changing the syntax

 osmc:symbol=waycolor:background[:foreground[:foreground2[:text:textcolor]]]

this way you would have to write things like

 osmc:symbol=red:white
 osmc:symbol=red:white:red_bar::x:blue
 osmc:symbol=red:white:::x:blue

and the label would be aways 5th part

Solution 2. Redefining the standard and making the label part same syntax as the other foregrounds, like

 osmc:symbol=waycolor:background{:foreground}

which means that the last part can be repeated as many times as you wish. The text label would have syntax like

 text_red_Labeltext 

so for example

 osmc:symbol=<whatever>::text_red_A # just red A with no background
 osmc:symbol=<whatever>:blue:text_black_A # red A  on blue background 
 osmc:symbol=<whatever>:blue:yellow_circle:text_red_A # red A in yellow circle on blue background

Please let me know what you think about this. If we are able to formulate the weak points of syntax, this might be first step to find good solutions.

--Jakubt (talk) 11:07, 20 November 2016 (UTC)

Czech hiking trails - new symbols

Hello,

for purposes of Czech hiking trails we need to add some new symbols. See Editing_Standards_and_Conventions#Doporu.C4.8Den.C3.A9_typy_cest - we need symbols for "interesting_object", "ruin" and "spring" to be added to OSMC.--Petr Dlouhý 21:15, 6 January 2010 (UTC)

I had a look at the system. The extension defintely makes sense. I would expect you also need the diagonally split signs? --Nop 22:21, 6 January 2010 (UTC)
Yes. I forgot that.--Petr Dlouhý 23:51, 6 January 2010 (UTC)
Hello, all of those symbols can be in all colors used in Czech rep. (blue, green, yellow, red), now there is only one color for each one. Can you add it, please? --V0174 20:52, 3 April 2010 (UTC)
Complete set should be available now. --Nop 10:06, 3 September 2010 (BST)

Hi, please add support for other missing symbols from WikiProject_Slovakia/Hiking_routes. Also for bicycle routes we use colored "C" symbol on a white background.

Ideally, the symbol could be described by URI to SVG file stored on this wiki and another attribute for color of the path to draw. Otherwise it is impossible to describe new symbols just be words so that renderer would render them correctly without user's intervention. --*Martin* 20:36, 26 July 2011 (BST)

symbol list, and star symbol

Hi,

Where is now the symbol list ? http://topo.openstreetmap.de/symbols_en.html returns a 404 error.

It's on http://www.wanderreitkarte.de/symbols_en.html --Kaitu 23:31, 31 August 2010 (BST)

Is it possible ot have a star for European long-distance paths. The official marks for those ways are too complex to be rendered on maps (see http://www.era-ewv-ferp.com/upl_files/european_long_distance_4130410.jpg ) but could be something like ★4 or could the U2605 character be rendered ? Ok I will try it.. Let us see tomorrow...

http://osm.lonvia.de/hiking.html?lat=44.46231&lon=4.8333&zoom=11&layers=FFBT

--FrViPofm 16:29, 31 August 2010 (BST)

So it looks that unicode chars are not rendered on Lonvia ([1]) nor on Wanderkarte ([2]). Is the syntax good (relation 171821) ? Is it a bug in mapnik ? Does it need a font with unicode chars ? Are there other renderers that use the osmc:symbol=* ? --FrViPofm 13:21, 2 September 2010 (BST)
The osmc:symbol does not support special character "magic". OSMC filters out such characters as the rendering result is undefined. We could add a special "Europe" background icon (with your single star or with the circle of stars), like there is for the Jacobus pilgrimages, if there was a wider agreement to use it. Currently I have seen European stuff marked with yellow text on blue background. --Nop 10:05, 3 September 2010 (BST)

U.S. shields

In the U.S., most long-distance trails are either marked with blazes shields. Blazes can easily use the existing osmc:symbol syntax, but shields tend to be much more complex. Most shields are unique to a single trail, but a systematic design is gradually taking over for state and national routes. Any chance that these designs – or at least the green oval design for state routes – could be supported by the osmc:symbol renderers? – Minh Nguyễn (talk, contribs) 18:31, 7 May 2012 (BST)

"_right" should accompany "_lower"

Kilo flag.svg

On Crete horizontal divided squares are popular to mark paths. They could be generated by introducing a "_right" shape that would be a "_lower" turned 90° to the left. Any chance? --GerdHH (talk) 08:29, 10 November 2015 (UTC)

Here is an example where this is needed: https://www.openstreetmap.org/relation/1201589 . Would be nice to have it as an official option. --Mueschel (talk) 19:38, 21 April 2017 (UTC)

It is kindly supported by Waymarkedtrails {https://hiking.waymarkedtrails.org/help/rendering/osmc_legende]. Also OpenAndroMaps refers to that specification [3] --GerdHH (talk) 10:19, 20 September 2017 (UTC)

No background

What osmc:symbol should be used if no background is provided? There are only red dots directly painted on the tree. Could it be red::red_dot? --*Martin* (talk) 04:49, 25 May 2016 (UTC)

It is enough to tag osmc:symbol=red:red_dot --Nop (talk) 19:13, 26 May 2016 (UTC)

Actually it should be osmc:symbol=red:red_round :-) --*Martin* (talk) 15:07, 9 June 2016 (UTC)

white_hiker

Hi, It seems that the white_hiker symbol (found on http://www.wanderreitkarte.de/symbols_en.html) is not rendered. See http://hiking.waymarkedtrails.org/#?map=12!46.1025!6.1431 (relation 6438529). --FrViPofm (talk) 15:13, 26 July 2016 (UTC)

What to do if a route changes color mid way?

Some routes change color mid-way. How should one deal with that? It appears some people just split the route into two relations with seperate osmc:symbol tags, but this is not elegant. -- SwiftFast (talk) 06:25, 4 May 2017 (UTC)

Wrong example?

Hi, I don't get how the example blue:shell_modern is according to the syntax waycolor:background[:foreground][[:foreground2]:text:textcolor]. Is that an error or shell_modern is really the background here? Or do I understand the syntax wrong? --V0174 (talk) 08:14, 11 January 2020 (UTC)

unicode symbol

It says " Use simple ASCII letters only, exotic ANSI/UTF-8 glyphs are not supported. This and textcolor may be omitted when not needed."

I don't see why such a limitation should exist, if there is a unicode symbol, thin it should be allowed to be used as the text. --Aharvey (talk) 12:16, 15 August 2020 (UTC)

What specific Unicode codepoints you want to use, which are reasonably to use but blocked by such rule? Unicode symbols include really exotic stuff that may make tags uneditable for a typical user Mateusz Konieczny (talk) 15:58, 15 August 2020 (UTC)
It could be anything as used on the signpost, but for the one I'm looking at it's ≈ which is used as the symbol on all the signage as shown at https://www.flickr.com/photos/136319147@N08/50228121003/in/datetaken-public/ for https://www.openstreetmap.org/relation/10179677. At the moment the symbol=* key can describe it, but ideally it could be encoded so that data consumers can render the symbol correctly. Perhaps osmc:symbol=lightblue:≈. Though in this case it's just the text and colour so not sure how to ignore the background colour field, but that's another matter. --Aharvey (talk)
And this would make extremely hard to enter it. In such case making mapping easier should come before eliminating trivial work of data consumers (and yes, it is trivial - the only requirement for such transformation is a lookup table) Mateusz Konieczny (talk) 07:22, 16 August 2020 (UTC)
Not sure I get that reasoning, after all I'm a mapper here looking to find an easier way to map the route/track symbol used. I'm not a data consumer of this (at least not yet). If anything entering the unicode symbol would be much easier as there are many websites and applications out there to search unicode you just find the right symbol and enter it. Compared with currently you have to lookup some table on the wiki of text descriptions of symbols find out which ones are supported and hope there's no ambiguity in the way it's described and how it's interpreted by data consumers. Makes sense to use unicode here. --Aharvey (talk) 07:37, 16 August 2020 (UTC)
For start, Unicode has many wave characters that will look drastically different in various fonts - what is correct as Unicode is not describing how character looks like. So while in some fonts may look like expected symbol, in other it may look different or be simply missing. And specifically your example "≈" is not a wave. It is U+2248, "almost equal to" character. And for trails using wave symbol (rather than almost equal sign) it is also simply incorrect. Mateusz Konieczny (talk) 08:25, 16 August 2020 (UTC)