Talk:Osmarender/NewFeaturesProposal

Could you add a bit about why this is necessary, for those of us who don't know what the current situation is and why this might be a good idea? I'm guessing from what you've written that at present there is some sort of definition files where things like core and casing are scattered around a bit? EdLoach 14:26, 30 September 2008 (UTC)

Yes, you're guessing it right. I've tried to explained that a bit in the proposal. --Jttt 14:42, 30 September 2008 (UTC)

RelativeLayer is a bit confusing / hard to understand / distinguish from Layer - maybe use of zIndex or drawOrder is a better name for it
Also use of setDrawOrder or GroupDrawOrder instead of SetLayer --Dido 08:40, 2 October 2008 (UTC)

Thanks for the suggestion. RelativeLayer was there for reason - currently when you want to draw something on the top you have to override layer. So relativeLayer was just logical extension. But you're right that this whole layer/relativeLayer bussines can be confusing. Hopefully current z-index and z-mode would be easier to understand --Jttt 18:35, 3 October 2008 (UTC)

Symbol/Icon offset heading

Hi all. I've been doing a lot of work in using Osmarender to automate map-making for Wikitravel. Thanks to your work it's been pretty straight-forward, but there are a couple of extra things that I'd like to do.

I've had to come up with a way to render boundary relations as areas. Basically this requires a tiny change to Osmarender, plus a couple of additional templates, the code for which is posted via git on Gitorious: http://gitorious.org/osmatravel. It would be nice if this code could eventually be included upstream, though if anybody has a better way to do it that would be great.

There are still a couple other things that have to be done manually with the maps I generate. The main thing is that symbols are rendered exactly on top of their lat/long location, and often in order to make the map legible they need to be offset a little, away from the street or the corner that they are found on. To make this easier I'd like to propose adding an osmarender:offset-heading to attraction etc. nodes in the osm data, and then optionally offsetting according to the zoom level at render time.

I prefer this approach over trying to calculate the offset vector in osmarender because it's something you only have to figure out once, so why spend the processor power on it for every rendering. It would be better to have a bot go through the OSM data from time-to-time to add the correct offset tag, saving precious cycles at render time.

I'd really like to read others' opinions. -- Mark 20:50, 18 June 2009 (UTC)

PS. Maybe see y'all in Amsterdam. We're working on getting a babysitter. -- Mark 20:50, 18 June 2009 (UTC)