Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#885 closed enhancement (invalid)

Allow custom symbols for Map Relations

Reported by: Dirk Stoecker Owned by: Tom Hughes
Priority: major Milestone:
Component: admin Version:
Keywords: Cc:


For example hiking ways often have these colored dot on white ground or colored stripe on white ground symbols. But there are also more complext symbols like specially drawn letters and things like that for more important ways. Relations for these ways ATM use textual description for these.

A standardized way to include such short symbols as SVG graphics should be developed. And also these should be drawn on maps later (at least in high resolution maps or special hiking/cycling maps).

One possibility would be to store such symbols in the "symbol" tag. If there is a http:// or a ftp:// link in this tag, then the file is treated as symbol display. Prefered storage space should be the SVN of openstreetmap thought.

Change History (8)

comment:1 Changed 12 years ago by Tom Hughes

Resolution: invalid
Status: newclosed

We don't use trac to discuss tagging - that happens on the wiki.

comment:2 Changed 12 years ago by Dirk Stoecker

Resolution: invalid
Status: closedreopened

Well, this is not about tagging. The symbol tag is already standard. See

What I request is an extension to the whole system to support non textual descriptions. Adding an http:// link in the symbol would be easy, but it makes no sense to do so, if the information from these is not used for map generation.

Probably symbols for relations aren't the only place where this is useful. Probably the "for Map Relations" should be removed from the ticket title.

comment:3 Changed 12 years ago by Tom Hughes

I don't understand what part of the "system" it is you want changed?

You seem to want to change the meaning of the "symbol" tag for relations from a textual description to a URL of an image? If so then that is a tagging discussion that should take place on the wiki page you mention.

If you've think you've got a genuine problem with some part of our software stack then could you please explain it a bit more clearly - what is it you've looking at, what it is doing now, and what do you think it should do?

comment:4 Changed 12 years ago by Tom Hughes

Resolution: invalid
Status: reopenedclosed

If what you're saying is that you want a symbol named by a URL in that tag to appear on the map than (a) admin is the wrong category (b) you need to get agreement on using the tag in that different way before asking for the slippy map to be changed (c) you need to indicate which rendering you are referring to and (d) there are obvious dangers in this proposal with regard to allowing injection of dodgy images onto the map.

comment:5 Changed 12 years ago by Dirk Stoecker

Resolution: invalid
Status: closedreopened

Could you at least give me some time to reply before marking it invalid again? It needs time to give long explanations and being set to invalid before I even finish writing is not fine.

At the moment we have a set of standard tags, which are then transfered in a final map image. If highway=primary we get a red line with black border, if a point has amenity=parking then it gets a symbol with a white P on blue ground. Every new symbol or design needs to be added to the different renderers to support new stuff.

Now for the cycle or hiking ways it is a bit different. Each of these (the relation and not the ways itself, as the hiking path consists of multie OSM parts beeing tracks/streets/...) can have an individual symbol. May it be an easy geometric form or more complex symbols.

Adding each and every of these individual symbols to the OSM generic mapping configurations is no good idea for multiple reasons (maintainability for example).

What I start to request with this ticket is a way to provide custom symbols for specific portions of the map: Finally this includes:

  • a way to specify these custom symbols (e.g. the symbol tag)
  • a data format for these (e.g. SVG)
  • size/type constraints, ...
  • a way to handle map generation
  • a common standard place for symbols (but it should not restrict to this)
  • Rules if and where these symbols are drawn and if/where not
  • ...

Nothing easy I know, but an extension, which is very useful in the long term.

Also this would allow an easier way to introduce new map features: If for example I start to track all places of bird nests and make a symbol for it. When the usage of this symbol spreads it may get moved to the common map building configuration and the symbol tag be removed. If not, it stays a local thing (well, I have no better example right now :-). This would give a great deal of more flexibility.

Your next comment: a) Admin is the category, which is choosen by default, thus I think it is the right category for everything not matching other categories and this is cross categories.

If there is a better place, tell it.

b) Please get away from this special tag. Actually this is what this request is - A request for that feature including all what's relavant for this, like policies, tags, programming, ...

c) See b.

d) Sure there are dangers. But I can also make little ways or areas and draw symbols on the map that way. This is no argument against the feature at all. Should I write my name at my home place? No problem at all, you know?

In the policies for such feature could be a decision to only draw symbols from the SVN or something like that.

There are many different methods to implement such thing as requested.

comment:6 Changed 12 years ago by Tom Hughes

Resolution: invalid
Status: reopenedclosed

Lots of the things you are asking for are just never going to happen.

We do not a central rule making body that dictates how renderers should render maps - the developers of each renderer make their own decision about what tags to pay attention to and which to ignore, and on the basis of that how to render each object in the database or, indeed, whether to render it at all.

So there is nobody who can dictate what formats might be permissible, or what size/type constraints might be applied as that would be up to the developers of each of the rendering engines and their associated stylesheets. Likewise nobody can make a rule requiring these things to be rendered.

At least one of the t@h developers has already objected to the idea of rendering user supplied symbols when I discussed it with him on IRC and I doubt the manpik people will be much happier.

If you really want to progress this then please take it to the wiki and at least get consensus on what tag should be used and what sort of formats people would like to see accepted.

I still doubt that you'll have much luck persuading either of the main rendering teams to consider this, but if you do want to pursue then please enter separate tickets under slippy_map (for mapnik) and osmarender (for osmarender/t@h).

comment:7 Changed 12 years ago by Sebastian@…

Thanks for submitting this request. However, it is not going to be implemented and that is why it's right to close this as invalid. We are quite decentralized yes, but being able to have arbitrary images shown on roads will never be possible (at least for osmarender, can't speak for mapnik). The map is crowded enough as it is, and if anybody can show the symbol they would like to see, it would become an incoherent chaos. If people started popping up their photo on their houses, ...

Does this mean, we want to ignore your suggestion? No. It would be useful to have better markers on hiking trails. There are two ways to get these: 1) You talk about customized hiking maps. Anybody can add any symbols already now on these custom maps. Look at the cycle maps that exist for example, you can have whatever shapes you want already now. Just not on the "main" maps. 2) You talk to the mapnik or osmarender style sheet guys and ask them whether they would think that having a red-white-red stripe on any way that is of type route=German_national_hiking_trail or signage=red-white-red or whatever. If they agree, they will implement it on the main map. There are two renderers mapnik and osmarender which have nothing in common, so it's not clear yet where you would want this to appear.

comment:8 Changed 12 years ago by Dirk Stoecker

Only to state the not-so-obvious: I'm pretty aware of the data flow in OSM in general, the different renders, special maps and so on.

Well, you should differentiate between two things: a) the general layout and possibility in the base data and b) the actually implementation in the renderers

My request actually includes both, but implementations must seperate for sure.

I'm not 100% sure, but I think the renderers have no general infrastructure for custom images based on the data files itself. Or is there anything like that? Currently all must bes specified in the renderer configuration. I care for the openSUSE mapnik RPM package, but I agree, that I never had a real deep look into it :-) So there is a software issue here to make it possible in general before even starting to discuss what tags, what formats, .... If the renderers can't do it at all, there is no need for tag definitions.

Your point 2 does not hit the problem: The trails have e.g. white-red-white, white-blue-white, white-yellow-white, white-red-dot, white-blue-dot and so on (like B1, B2, B3, B12, B10, S12, S100, S23 for street references). So a general hiking rule would not be very helpful I think. It would hit nearly all the larger tracks and thus bring no additional information, but more chaos only.

Mainly I talk about your point 1: "Anybody can add any symbols already now on these custom maps". Yes. What I want is a generic interface for such things.

Or taking it to a higher level even: How to implement non-textual data into OSM tags.

The idea of OSM is to allow everything in the tags and display everything commonly agreed in the maps. Now at the moment this only applies to text.

Let me give you another example, which may be needed in the future. E.g. if we want to make city information systems based on OSM and tag an audio file to each tourism attraction (and I think this will come one day). The same problem applies - lots of standardisation would be required to make this usable outside of a specific group.

Adding custom symbols is easy compared to that. And I ask that now before we have dozens of different solutions for different areas using special maps and later on the standisation may conflict with anything else.

Note: See TracTickets for help on using tickets.