Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[mapnik] natural=wood doesn't render #401

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments
Closed

[mapnik] natural=wood doesn't render #401

openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments

Comments

@openstreetmap-trac
Copy link

Reporter: tom[at]acrewoods.net
[Submitted to the original trac issue database at 9.13pm, Saturday, 31st March 2007]

http://www.openstreetmap.org/index.html?lat=51.7648494192975&lon=-0.308752428412556&zoom=15

In the above view, a small wedge of woodland is visible at the top. At the bottom there are a series of wiggly footpaths which go through another bit of woodland, which sits adjacent to a park, but neither of these two features are showing up. They showed up in the last render, and I've checked to confirm that all the tiles are indeed up to date.

I've checked that the data is OK, they are both clearly visible in the Tiles@Home layer, the woodland to the North is also on top of a residential area and still shows up, and they used to show up, so I can't think why they don't this time.

@openstreetmap-trac
Copy link
Author

Author: Sebastian[at]SSpaeth.de
[Added to the original trac issue at 11.00am, Monday, 14th May 2007]

There is a rule in osm.xml but it doesn't work. I suspect the commented out rule a couple of lines above freaks out rendering. Send a mail to the list. Let's see if it's true. If yes, this bug would also fix the landuse=industrial is not rendered bug. Please check that if this is closed.

@openstreetmap-trac
Copy link
Author

Author: Sebastian[at]SSpaeth.de
[Added to the original trac issue at 11.36am, Monday, 14th May 2007]

This should be fixed with r2901. Keep this one open until it is confirmed.

@openstreetmap-trac
Copy link
Author

Author: Sebastian[at]SSpaeth.de
[Added to the original trac issue at 7.04am, Tuesday, 15th May 2007]

Actually, jburgess writes:

I guess you mean the way(id=4372580, natural=wood). That is being hidden
by way(id=4044516, landuse=residential). The reason is pretty
straightforward -- neither area has a layer= attribute so the rendering
order of these two features is currently undefined. 

I have just set layer=-1 on the large landuse area which should ensure
that any other object will be rendered over the top of this.

So the real fix will be to set the landuse layer in mapnik to -1.

@openstreetmap-trac
Copy link
Author

Author: jburgess[at]uklinux.net
[Added to the original trac issue at 8.44pm, Thursday, 16th August 2007]

osm2pgsql has had the following for ages which implements this...

/* landuse tends to cover large areas and we want it under other polygons */
if (landuse)
    z_order -= 1;

This biases the landuse polygon to be under any other polygon which doesn't explicitly have a nagative layer= tag.

There was some discussion about this on the mailing list/IRC and I believe everyone agreed that other polygons should generally be rendered on top of the landuse rendering.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant