From OpenStreetMap Wiki
Jump to: navigation, 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


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


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


this way you would have to write things like


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


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


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


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


Where is now the symbol list ? returns a 404 error.

It's on --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 ) but could be something like ★4 or could the U2605 character be rendered ? Ok I will try it.. Let us see tomorrow...

--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: . Would be nice to have it as an official option. --Mueschel (talk) 19:38, 21 April 2017 (UTC)

It is kindly supported by Waymarkedtrails {]. 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)


Hi, It seems that the white_hiker symbol (found on is not rendered. See!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)