Talk:Key:osmc:symbol

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 (171821 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"

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)

Symbols were meanwhile added. --Hufkratzer (talk) 14:56, 20 November 2021 (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)

red_dot is a foreground symbol, red_round is a background symbol. A dot is smaller than a round, see osmc:symbol=red:blue_round:red_dot here:

• https://www.wanderreitkarte.de/index.php?lon=11.0450&lat=49.6234&zoom=17
• https://hiking.waymarkedtrails.org/#route?id=445999

osmc:symbol=red:red_dot is sufficient for OSMC map, waymarkedtrails requires red::red_dot (empty field for background); a route with osmc:symbol=red:red_round (without foreground symbol or text) doesn't show up in OSMC map; compare issue Wrong example? --Hufkratzer (talk) 20:06, 21 October 2021 (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 (6438529 6438529). --FrViPofm (talk) 15:13, 26 July 2016 (UTC)

This seems to be resolved meanwhile; I can see the white hiker on https://hiking.waymarkedtrails.org/#route?id=6438529. --Hufkratzer (talk) 16:37, 21 October 2021 (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)

Can you (or someone else, it is years later) give example where it is actually a one route? Mateusz Konieczny (talk) 20:12, 17 November 2021 (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)

The expression "waycolor:background[:foreground][[:foreground2]:text:textcolor]" is misleading (wrong); the examples are more reliable, at least with regard to the OSMC hiking map. It is an example without background. The wiki page says: "Subparts can be left empty or may be left out if they are unneeded. The minimum configuration is a waycolor and either a foreground or some text and a background." But waymarkedtrails doesn't accept this. To have this symbol rendered correctly in waymarkedtrails you need to write "blue:blue:shell_modern". For more details see this discussion --Hufkratzer (talk) 16:23, 21 October 2021 (UTC)

On DE_talk:Key:osmc:symbol Nop gave another expression:

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

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

This is better in line with the explanations on this page and with the actual behaviour of the OSMC map (blue:shell_modern fits the second part). I propose to use this expression on this wiki page instead of what we have now as long as nobody proposes a better one. Any objections? --Hufkratzer (talk) 18:56, 18 November 2021 (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)

Last large edit

@Alo8: You have recently removed a lot of stuff from this page in this edit. Your changeset comment says was just "no italic", but I don't see any italic text that was changed. Please explain the reason(s) for your changes. For many of them (especially the removals) I don't see any obvious reason. Thanks. --Hufkratzer (talk) 16:19, 23 October 2021 (UTC)

@Alo8: I agree with Hufkratzer. You removed a lot of valid information and damaged the contents. Please explain yourself. --Nop (talk) 18:07, 17 November 2021 (UTC)

I reverted this edit, if changes were intentional it can be easily redone as everything is preserved. https://wiki.openstreetmap.org/w/index.php?title=Key:osmc:symbol&action=history I made revert as based on edit description it was not intentional Mateusz Konieczny (talk) 20:11, 17 November 2021 (UTC)

More colours needed

I'd like to use osmc:symbol=* to tag an archaeological educational trail that is signposted with grey rhombuses. Unfortunately, the color list is very limited and doesn't list grey. --Dafadllyn (talk) 22:23, 7 January 2022 (UTC)

@Dafadllyn: You can't rely solely on the tables on this wiki page, they haven't been updated properly in ages. Better check the linked tables on external pages. That said, "grey_diamond" is already used about 50 times. --Mueschel (talk) 12:58, 15 April 2023 (UTC)

new symbol: arrow

Could we add "arrow" as a symbol, please? It is widely used in Ireland. B-unicycling (talk) 18:07, 7 June 2022 (UTC)

I don't see a reason not to have it. Somehow like this: [[4]] (just with a real symbol and not some random unicode character)? There are already 30 keys with a symbol like "blue_arrow" in the database. --Mueschel (talk) 18:27, 7 June 2022 (UTC)

They're usually on a circular background, but your example would do the trick, I think. B-unicycling (talk) 18:37, 7 June 2022 (UTC)

Not sure if this is a change, but *_left_arrow, *_right_arrow and *_arrow (like *_right_arrow) are supported by waymarkedtrails. *_arrow renders as a pointer in osmAnd. I'd like *_up_arrow (and I suppose *_down_arrow) to be added. TrekClimbing (talk) 16:25, 15 March 2023 (UTC)

Can I suggest while it's relatively new that *_arrow defaults to being an upright arrow (🡅) - as in 'ahead' - rather than right arrow. The upwards arrow, at least in England (and by the sounds of it Ireland), is widely used and would be the default (with either left or right or some angle used at a junction). TrekClimbing (talk) 09:51, 16 March 2023 (UTC)

up_arrow and down_arrow are now available in waymarkedtrails. I didn't change the default arrow direction because I think we should be explicit in tagging and not relying on defaults. In this particular case the mapper also has to make sure that the arrow is actually a symbol of the trail and not just an arrow pointing in the right direction. --Mueschel (talk) 12:52, 15 April 2023 (UTC)

Ammonit a mis-spelling on the wiki or in practice?

Is 'ammonit' a mis-spelling on the wiki ('ammonite' is the British English term), or is it how it is implemented - in fact, is it implemented anywhere? TrekClimbing (talk) 16:28, 15 March 2023 (UTC)

ATYL vs Nop

Resolved: Mateusz Konieczny (talk) 21:46, 10 February 2024 (UTC)

"If you need a frequently used symbol added, contact Nop with suggestions. Don't invent a new tag, simply use text/textcolor or refrain from using osmc:symbol altogether."

While contacting User:Nop may be a good idea, it is also fine to simply start using a new value. At most it will not be supported by Nop's renderer. I see no good reason for such strong rule here.

Mateusz Konieczny (talk) 08:52, 25 August 2023 (UTC)

I agree, as a fellow renderer developer, it's a bit off-putting to see a key have a "bus factor" of one, as this article seems to imply. I don't have any reason to distrust Nop, but sometimes life gets in the way, so we shouldn't risk letting a key get into a state of limbo as a result. As I pointed out in the forum, a less presentational way to indicate the route's network would avoid this kind of tight coupling. – Minh Nguyễn ^💬 09:02, 25 August 2023 (UTC)

I agree. It would be more useful to give a table of symbols that are rendered correctly on different renderers as a rough guide. Maybe put a link to a github repo or user that manages each renderer, to give a link to where you can ask for a new symbol to be rendered. Janko (talk) 12:52, 25 August 2023 (UTC)

I agree it's time to document the current support by various tools. Looking at waymarkedtrails and myself, we don't need these two-dimensional tables, because every shape is supported in every color. This gives space for columns with checkmarks for the available support. I can easily supply a bunch of SVG images for this table. It seems that a good starting point is the table from waymarkedtrails plus a few shapes only available on Wanderreitkarte. --Mueschel (talk) 13:02, 25 August 2023 (UTC)

But Nop's map doesn't support every shape in every color because it is also available for Garmin, see [5]; so a 3-dimensional table would be needed (shape, color and map). Maybe something like:

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

shape	OSMC	Waym. Trails	OsmAnd	...
arrow	-	_ _ _ _ _ _ _ _ _ _
bar	_ _ _ _ _ _ _ _ _	_ _ _ _ _ _ _ _ _ _
hexagon	_	_ _ _ _ _ _ _ _ _ _
hiker	_ _ _ _ _ _	_ _ _ _ _ _ _ _ _ _
horse	_ _	-
triangle	_ _ _ _ _ _ _	_ _ _ _ _ _ _ _ _ _

--Hufkratzer (talk) 10:57, 10 September 2023 (UTC)

Now Nop is still mentioned but far less prominently Mateusz Konieczny (talk) 05:51, 8 September 2023 (UTC)

More colors

The list of available colors is more limited than what reality requires. For example  pink  should be added to the documentation. There is also some usage: https://taginfo.openstreetmap.org/tags/osmc%3Asymbol=pink%3A%3Apink_stripe --Dieterdreist (talk)

@Dieterdreist: if such trails exist in wild I would suggest uploading example images to Wikimedia Commons, asking data consumers to support it and listing it as a valid value on colour list Mateusz Konieczny (talk) 15:48, 10 February 2024 (UTC)

Valid on Ways?

This page says osmc:symbol=* is ony valid on relations (see "use on these elements") but trailblazed=symbols implies otherwise: "trailblazed=symbols can be used only if there is no waymarked route tagged with a osmc:symbol=* symbol=* wiki:symbol=* or colour=*. If this condition is met trailblazed=symbols can be used and additional tag can be added osmc:symbol=* symbol=* or wiki:symbol=*"

I'd prefer using osmc:symbol=* on ways for short hiking paths where it seems silly to make a route relation for each. Is there a reason not to? Can we update osmc:symbol=* to say it's valid on ways when combined with trailblazed=symbols? Or should we update trailblazed=* and I should just be making many tiny hiking route relations? I'm looking for options to color short paths better than name=red which seems to be how it's usually handled.

Blackboxlogic (talk) 15:23, 10 February 2024 (UTC)

@Blackboxlogic: It sounds like general question "is hiking route and path the same object or distinct one"? With bonus question: how it works for names? When path is named the same as way? When path us unnamed and carrying named trail(s)? As I understand, approach to that differs in USA and Europe. Mateusz Konieczny (talk) 15:50, 10 February 2024 (UTC)

@Mateusz Konieczny: I think we all agree that a road can have a name, and I don't see why a path would be different than a road, and I don't see why a symbol would be different than a name. Yes, things get complicated when routes contain many roads. But many cases aren't complicated, and I'm suggesting we treat the simple cases simply. Blackboxlogic (talk) 16:01, 10 February 2024 (UTC)

@Blackboxlogic: it is not about whether path can have name (obviously it can have). It is rather about when route name is also name of path. I have seen people claiming that path never has the same name as route, I have seen people claiming that path always has name inherited from route, both are wrong - though it is not entirely obvious when you have named route on unnamed path. In general it is question whether route is separate object from path where it is going Mateusz Konieczny (talk) 21:46, 10 February 2024 (UTC)

"It is rather about when route..." I'm asking if we can carve out the simple case where there is no route, and no need for a route, there is just a path (like, just a road)? And it sounds like your response is "but in complicated cases where there's a route...". Sounds like you're talking about the Appalachian trail, and I'm talking about https://static1.squarespace.com/static/5ab534a8697a985af70b73ca/t/5ae709612b6a28c108427b34/1525090659707/LittleRiverTrailMap.jpg Do you see any problems in the simple case? The limited simple case is defined in the text quoted from trailblazed=symbols. I'm focusing on the simple case because it is the most common case in map data I edit and consume. Blackboxlogic (talk) 22:08, 10 February 2024 (UTC)

I guess if you have single unnamed signed route (or where across entire length footways, roads and tracks have always the same name as trail) and you can be sure that there is no second signed trail sharing any of ways... And neither will change in future. Then tagging on ways, without using relations, can work. @Blackboxlogic: Mateusz Konieczny (talk) 12:08, 17 June 2024 (UTC)