[OSM-dev] Mapnik rendering of leisure=park + landuse=* relations
aschoell at gmail.com
Wed Oct 7 06:11:29 BST 2009
On 5 Oct 2009, at 15:38 , Dan Homerick wrote:
> It would be very nice to be able to use landuse tags within parks,
> especially large ones. Trying to do so is pretty 'buggy' though. I use
> buggy in quotes, because it seems like the rendering order is just
> undefined, or at least inconsistent between zoom levels when used with
> landuse relations.
As far as I have seen it's random. It has nothing to do with relations
or plain areas. But we can't really expect the renderer to know the
intend of the mapper.
> Ideally, leisure=park areas (which have an alpha transparency less
> than 1) would render on top of landuse=* areas (which mostly/all? seem
> to have an alpha of 1). This would allow a park to still be visible
> even when surrounded by areas of the same landuse, because the park
> would overlay the landuse and alter the coloration. As is, the render
> order appears to be the other way around, with landuse renderings
> overlaying the park and completely hiding it.
this is a good idea to use some transparency setting. a landuse forest
in a park and outside a park will differ slightly in color.
> While trying to work around this limitation, I noticed that the
> rendering order for relations is ... odd. "Buggy."
I thinks it's just undefined and whatever comes first is rendered first.
We need a proposal how to change it. It's on my wish list for a long
time but never found time to work on it
1) sort order for different landuse, leisure, natural tags or use
explicit tagging with layer tags
2) well defined transparency values to get nice maps
3) implement change for the Mapnik/Osmarender styles
> First, an example:
> Both units of Henry Cowell Redwood State Park (the 'Fall Creek' unit
> to the NW and the main parkland to the SE) have a multipolygon
> relation whose outer member is the park boundary and where the
> relation itself is carrying a landuse tag. Some inner members carry
> different landuse tags. The park itself is defined by a leisure=park
> tag on the boundary way. Note that we want the park boundary to be
> separate from the landuse relation, so that 'holes' in the landuse
> aren't holes in the park. Also note Wilder Ranch State to the SSE,
> which does NOT use a landuse relation. Areas of landuse overlay the
> park and obscure it.
in this area relations are used because areas with holes require a
multipolygon relation and can't be defined as a simple polygon area.
Or maybe the length of the polygon exceeds 2000 nodes.
and yes the landuse(or natural) should always be independent form
leisure=park. a park is nothing on ground it is a ownership and legal
> Now zoom in and out, and notice that at some zoom levels, the landuse
> relation is rendered on top of the park (obscuring it), and at other
> zoom levels the landuse relation is rendered below the park, taking on
> a coloration that reveals the landuse while still indicating the area
> is a park. There are various parks nearby without any landuse that can
> help note the color differences. Zoom level doesn't seem to be the
> primary causation of the differences in rendering, it just looks like
> the different tile sizes are triggering different rendering orders,
> since at one zoom level both parks may get rendered differently
> (zoom=14 for example).
maybe low zoom levels haven't been rendered at the same time. some
features may show after a full reimport only. Can you send an exact
> There's also a hell of a lot of crud left around from somebody's
> botched import(s), but that's another story.
> Is this inconsistent rendering order a known issue?
> Is there a better way, or workaround, to tag an area with both
> leisure=park and landuse=*?
I think we should always render a these parks with a boundary. similar
to the topo24k maps. they uses a thin black boundary. Mapnik uses a
thick green dashed line at the moment.
As soon as we have detailed landuse areas mapped the rendering of the
park itself is not easy in a way to see both. there are already many
shades of green. adding more might be confusing.
> - Dan
> dev mailing list
> dev at openstreetmap.org
More information about the dev