Please no.
If a file is not on the OSM Wiki, it “automagically” redirected to Wikimedia Commons.
So for me, wiki:symbol tag is enough
2 Likes
Incidentally, the most common wiki:symbol value (39%; the next most common value at just 7%) refers to File:Symbol SWV Örtlicher Weg.svg - OpenStreetMap Wiki, which exists on the OSM Wiki as a duplicate of File:Symbol SWV Örtlicher Weg.svg - Wikimedia Commons on Wikimedia Commons. I wonder if it was uploaded before the wiki was set up to automatically fall back to Commons.
By default, MediaWiki rejects SVG files that contain JavaScript, HTML, or internal links. Neither the OSM Wiki nor Wikimedia Commons have overridden this default, so there is a measure of safety. However, it remains possible to craft an SVG file that exploits a security vulnerability in an SVG renderer. The wiki communities are less likely to detect this issue because we primarily rely on MediaWiki’s server-side rasterization. If this concerns you, you can mitigate the issue by asking the MediaWiki API for URLs to a PNG thumbnail at the desired width and/or height.
Note that semantic information such as network and cycle_network is in some respects more important than wiki:symbol. These image URLs are very literally tagging for the renderer, in that a different renderer might need a slightly different image, for example with a slightly different color scheme or simplified shapes that are more legible at certain sizes. At best, it’s a last resort when semantically tagging an obscure symbol is very unlikely to yield renderer support.
1 Like
Good idea, thx. We’ll look into it.
I guess it is up to the renderer to decide which information is more important between text tags and image tags. The “pure text” tag symbol is more or less useless for any purpose I know, for instance.
2 Likes
Agreed. In fact, many occurrences of symbol on route relations are actually outdated Wikimedia Commons image URLs. The U.S. community had tried to standardize around that practice many years ago, but we abandoned the idea by 2012, after we set out to build a shield renderer and realized what a logistical and security nightmare it would be. Instead, we focused on a complex hierarchy of network values.
cycle_network exists because we needed something like network on road routes, with more expressiveness than osmc:symbol and more predictability than wiki:symbol but without clashing with values like network=rcn. Naming it cycle_network turned out to be a short-sighted decision, since it does nothing for hiking routes. There may be a benefit in promoting a semantic tagging scheme that can cover any kind of route.
Slowly drifting off-topic here, but this is the first time I hear about cycle_network, after 2-3 years of active contributing on (mostly) hiking routes and (marginally) other types of outdoors route! I know a fair bit about node networks and their cycling instances, especially in Belgium and the Netherlands. Could it be a case of independent invention of a similar concept?
If yes, I’d be more than happy to discuss in another thread how the two systems could converge. In all honesty, I relate more to the idea that network points to objects rather than to the idea that it has an encoded value that tells if this is a small or a long route, more or less.
1 Like
An example from a croatian thread.
They remove osmc:symbol=red:white:red_circle and add symbol=Knafelčeva markacija but even with a good translator, I can’t understand the value 
I think this is an interesting point that should discuss in a separate thread.
Here in France we want to display the “real” symbol so everybody could see it on the field and on the map.
I understand that some (at least in the USA) use the symbol for it’s semantic aspect (i.e. this a “regional” cycling route that form a loop).
Here in France use semantic tags link network and network:type=node_network.
Is there a security benefit in hosting all symbols on the OSM wiki instead of Wikimedia commons?
Given that files on OSM Wiki are patrolled and reviewed at lower rate and effectiveness than Commons, opposite if true if any such difference exists.
Can we, however, consider that is the wikis’ responsibility to scan svg for scripts rather than that of clients?
At least osmc:symbol allows renderers and routers to vary the pixels according to their specific needs. But wiki:symbol affords no such flexibility: you either use the image verbatim, whatever it is, or ignore the tag and leave the route unmarked. It could be a grainy JPEG with an unsightly white background or an SVG that confusingly blends in with the color for waterways, but the renderer has no control over it.
What’s more, even if the developer cares enough to design a better icon for that route in the context of their map, all they can do is add a special case that overrides a particular image name on the wiki, rather than anything intrinsic to the route. If a mapper uploads a different image they like better, for example converting the JPEG to a PNG but with the same color issues, this override stops working.
That’s effectively what’s happening now because both wikis reject SVGs containing scripts. However, both wikis also accept other file types that, when viewed raw, could cause problems. For example, MediaWiki is unable to guarantee that a PDF is free of security issues. (Yes, PDF is also a vector image format. In fact, it’s the main vector image format on Apple platforms.) But even a specially crafted PNG or JPEG can exploit security issues in some viewers, which is why it’s prudent to rely on MediaWiki’s server-side thumbnails.
1 Like
Problem in Croatia was that users were changing the osmc:symbol=* tag into some strange constructs which would help in showing just the ref=* in the Waymarked Trails renderer. The osmc:symbol=* tag isn’t very useful in Croatia because 95% or more trails are marked with the same red:white:red_circle blaze (which is called Knafelčeva markacija, or Knafelc blaze in English). But on Waymarked trails, if there is a osmc:symbol=* tag on a relation, then the ref=* isn’t shown. So we decided to delete the osmc:symbol=* tag, and add just symbol=Knafelčeva markacija.
After that we agreed to replace symbol=Knafelčeva markacija to symbol=red circle with white dot in the middle because that’s the standard value i found on taginfo. We will also add wiki:symbol=Markacija.svg
If the issue on Waymarked Trails is solved, we will come back to osmc:symbol=red:white:red_circle, and will probably delete the wiki:symbol=* tag. Is there a place where the Waymarked Trails development is discussed?
We have set up an experimental instance of Waymarkedtrails, in cooperation with Sarah. Maybe we could test options together?
Currently, as stated above, I am working on wiki:symbol. But we can explore other topics.
You mean they were using the last segment of the tag value to put the reference text? That would be standard use of that field, wouldn’t it?
They started with putting numbers, but then the numbers weren’t visible enough. In the end they put osmc:symbol=red:white:red_frame:25:black, which broke rendering, and it only showed the ref=*, which is when people were happy. As I said, the rendering of the symbol is pretty much irrelevant in Croatia, because most routes have the same symbol. But if there was ref and the symbol rendered, that would be great.
To me, the short-term workaround for Waymarked Trails should raise concern that there’s an undue temptation to tag for the renderer. Presentational details like this are the proper responsibility of a stylesheet, as long as it has access to an unambiguous network identifier. Recreational routes (other than cycling routes) are in an awkward spot, because the only valid values of network are three-letter acronyms that effectively only indicate the mode of transportation and minimum zoom level, but not the network. Thus we’ve devised an image description language plus an external image mechanism that raises security questions.
We don’t have as much of a problem with road routes (other than outliers like network=motorway in a few countries). When a mapper disliked how OSM Americana marked Vermont’s state highways with an oversimplified shield, they opened a bug report and it was fixed in one spot. There was no need to coordinate changes to the tagging scheme with other renderers like Mapbox and OsmAnd, nor did each individual route relation need to be updated.
While I agree that the current set of values for network is next to useless, I don’t see what it has to do with the problem at hand. The most important visual aspects of a hiking route are ref and symbol, and both have dedicated and unambiguous tags. The problem lies with the renderers (one particular) which is unable to show them both, or at least choose one on a case-by-case basis.
That’s a symptom, not the root cause. This topic started because wiki:symbol is dangerous to implement naïvely. wiki:symbol exists because, despite our best efforts, osmc:symbol will always be incomplete. Hopefully the mitigations I suggested will be helpful, but there are a lot of other problems with the idea of loading arbitrary tagged URLs or image names. This may explain why only one renderer has previously attempted to consume wiki:symbol – the renderer that serves as the reference implementation of osmc:symbol. What other key do you know of that replaces the “Any tag you like” principle with the authority of one person?
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.
My point is that ideally the symbol would be derived from ref and a more meaningful network-like key. Consider the fact that most of the routes in Croatia have the same symbol design: is this a mere coincidence, or is it a consequence of these routes belonging to the same network? If a particular renderer is misinterpreting osmc:symbol, then by all means, the bug should be fixed. But please note that, if we keep putting effort into building out the osmc:symbol language without solving the problem more generally, then recreational route symbols will remain limited to a small club of renderers.
I started Talk:Key:osmc:symbol - OpenStreetMap Wiki (if someone wants, feel free to start discussion at forum here - just ping me, or on tagging mailing list)
In Croatia it could be said that the prevalent blaze is connected to the Croatian Mountaineering Association. Would then your solution be to put a tag like network:operator=Croatian Mountaineering Association, and then renderers would download the symbol connected to that association, from the wiki? That looks like the solution with wiki:symbol=*, or maybe I’m not understanding your solution.
I share your concern about what part of rendering should be specified in tags and what part in rendering code or stylesheets. The text field in osmc:symbol is probably very much debatable in this context. It is common practice in France to use that field to introduce all or part of the reference, but I agree that this raises lots of questions.
However I believe that we should not fall into the trap that equates semantics to text and rendering to graphics, so as to draw a deceptively simple borderline between what should be in tags and what should be in rendering styles. After all, letters are symbols too; and SVG is a text language just like the mini-language in osmc:symbol. In my view, the question is rather “what is observable in the field, and how should we represent it?”. If a sign has a name on it, I put this sign in a tag. If it has a symbol on it, why not describe this symbol in a tag? Sometimes the symbol is too complex to represent with a mini-language, and SVG is the perfect language for that.
1 Like