Author: tom[at]compton.nu
[Added to the original trac issue at 8.38am, Monday, 23rd March 2009]

This not something mapnik is capable of doing. It's also completely and utterly bogus to be attaching a URL to every single road like that...

Author: elyk
[Added to the original trac issue at 5.58am, Tuesday, 24th March 2009]

I figured mapnik wasn't this capable yet. Is there any chance that such a route relation could use a normal shield with ' ' as the shield text?

Author: elyk
[Added to the original trac issue at 6.10am, Tuesday, 24th March 2009]

Replying to [comment:1 tom[at]compton.nu]:

It's also completely and utterly bogus to be attaching a URL to every single road like that...

The URL is on the relation, not on every way that makes up the relation. That way the URL only appears in one spot for the entire road.

I see adding the URL no differently than adding a wikipedia link to some object. It might be useful to some application or some other renderer, but not necessarily useful to mapnik.

Author: JohnSmith
[Added to the original trac issue at 2.02am, Wednesday, 16th September 2009]

You shouldn't tag for software, there is ways of doing this without needing to explicitly tag it.

I'll attach an example patch, it may need improving some what and the highway shield images need someone better at this than me to touch them up.

Author: Ldp
[Added to the original trac issue at 11.29am, Wednesday, 16th September 2009]

This aussie patch is /an/ approach, but not necessarily the best. It makes relatively expensive calls to postgis to get the Aussie boundary and compare each route to that. While that may look innocent enough, try extrapolating doing this for 50+ countries. That's even discounting the explosion in the size of osm.xml.

As a way to handle the expensive postgis calls: I think a much better approach would be to determine locality of features during import, and not during rendering. The import will take longer, sure, but tile rendering should be much faster than using your run-time filtering method.

On the matter of stylesheet maintainability, XML entities definately come in very handy here, but it will still be a humongous stylesheet. Other approaches like cascadenik should not be discounted for this.

Author: JohnSmith
[Added to the original trac issue at 12.05pm, Wednesday, 16th September 2009]

I didn't think it would be the best option, for most of the reasons you point out, however we have to start some where, so I thought I'd get the ball rolling.

Author: JohnSmith
[Added to the original trac issue at 10.41pm, Tuesday, 29th December 2009]

I'm currently working on a new approach, instead of trying to work out polygons on the fly and render the shields that way, do some pre-processing and insert the information into a new column in the database combined with a lookup table on the wiki:

http://wiki.openstreetmap.org/wiki/Custom_Highway_Shields

However I'm still working out the best way to store the lookup table in memory and then can go on to work out what polygons a way runs through and then applying an icon to the way.

Author: math1985
[Added to the original trac issue at 2.03pm, Tuesday, 25th March 2014]

@gravitystorm has decided not to implement coloured route shields, and by extension custom route shields, on Github: gravitystorm/openstreetmap-carto#421

Therefore, I will close this issue now.

Author: Minh Nguyen
[Added to the original trac issue at 7.39pm, Tuesday, 25th March 2014]

Custom shields are a very different beast than custom colors on the existing generic shields. I dont think gravitystorms comment should preclude integrating some form of the [http://openstreetmap.us/~toby/shields.html shield renderer] ([https://code.launchpad.net/~asciiphil/osm-shields/trunk source]) in the future.

Author: math1985
[Added to the original trac issue at 9.32pm, Tuesday, 25th March 2014]

Ok, we can keep the issue open.

Author: pnorman
[Added to the original trac issue at 9.58pm, Monday, 7th April 2014]

The place to report issues with [https://github.com/gravitystorm/openstreetmap-carto openstreetmap-carto], the "standard" style on openstreetmap.org is on [https://github.com/gravitystorm/openstreetmap-carto/issues its issue tracker]. The old Mapnik XML based stylesheets have been retired.

If this ticket is about adding shields to the "standard" layer, this isn't the appropriate place for it. If it's about setting up some other layer with custom shields, this is also not the appropriate place.

Author: math1985
[Added to the original trac issue at 10.04pm, Monday, 7th April 2014]

The ticket was opened 5 years ago, when this was still the appropriate place to report these issues. I propose we leave the old tickets here open, at least as long as we have not migrated them to Github.

Author: pnorman
[Added to the original trac issue at 6.56am, Tuesday, 8th April 2014]

My recollection from EWG meetings is that it's fine to close them out. After all, they're reported against a component that will never be updated, not against openstreetmap-carto. If there is interest, a new ticket can be opened, but as it stands, this ticket will never be fixed, even if shields are added to openstreetmap-carto.

Author: math1985
[Added to the original trac issue at 11.47pm, Friday, 11th April 2014]

I would strongly prefer to either keep them open, or migrate them to Github. The open issues helped me a lot with re-factoring the road layers, and I think they will also help with seeing what are the problems with the other layers.

In any case, we are already down from over 400 to 319 issues.

Author: math1985
[Added to the original trac issue at 11.34pm, Monday, 21st April 2014]

This issue is now being discussed on Github: gravitystorm/openstreetmap-carto#495
I will therefore close the issue here.