Author: schuetzm[at]gmx.net
[Added to the original trac issue at 9.34am, Saturday, 13th June 2009]

Well, this is the old problem of using a fixed order for rendering landuses. There could be cemeteries with woods in them, so if you turn the order around, it would still be wrong.

Instead, smaller landuse areas should be drawn over larger ones.

Author: osm[at]petschge.de
[Added to the original trac issue at 11.18am, Saturday, 13th June 2009]

In theory a good idea but I'm pretty sure that this is not possible with XSLT. It might be possible in or/p but I'm not sure if it would be good if the two implementations generate different tiles.

Author: bob[at]cakebox.net
[Added to the original trac issue at 6.34pm, Monday, 15th June 2009]

This is imho a bug in the data. The cemetery should, unless this is a very weird case where the graves are put between the trees in the forest, be a hole in the forest using a multipolygon relation.

I'm fairly certain it's much more common to have a small forest-like part inside a cemetery, so the layering should be kept as it is.

And re: the comment by petschge it'd probably be way to complicated and resource intensive to implement that kind of logic in XSLT, and having the implementations differ would be really bad.

It's not as straight forward as it sounds to use that kind of size-ordered drawing either, mapnik does and there are some corner cases where it fails horribly and there seems to be no sensible workarounds.

Author: schuetzm[at]gmx.net
[Added to the original trac issue at 10.18am, Wednesday, 17th June 2009]

Replying to [comment:3 bob[at]cakebox.net]:

This is imho a bug in the data. The cemetery should, unless this is a very weird case where the graves are put between the trees in the forest, be a hole in the forest using a multipolygon relation.

There are woodland cemeteries as well. Also, for jewish cemeteries it is not that uncommon either.
And what about the other cases, e.g. a forest in a military area vs. a military area in a forest?

I'm fairly certain it's much more common to have a small forest-like part inside a cemetery, so the layering should be kept as it is.

And re: the comment by petschge it'd probably be way to complicated and resource intensive to implement that kind of logic in XSLT, and having the implementations differ would be really bad.

Well, who still uses the XSLT renderer anyway, now that the default for t@h is orp? I don't think we should limit ourselves to what XSLT can do. If anything, this would instead be an opportunity to drop official support for XSLT.

And AFAIK, XSLT doesn't support advanced multipolygons, while ORP does, so there is already a difference in an important feature.

It's not as straight forward as it sounds to use that kind of size-ordered drawing either, mapnik does and there are some corner cases where it fails horribly and there seems to be no sensible workarounds.

Out of curiosity: what are these corner cases? Right now I can't think of any that don't involve cases where one area is not completely contained in the other.

Author: bob[at]cakebox.net
[Added to the original trac issue at 6.44pm, Wednesday, 17th June 2009]

Replying to [comment:4 schuetzm[at]gmx.net]:

Replying to [comment:3 bob[at]cakebox.net]:

This is imho a bug in the data. The cemetery should, unless this is a very weird case where the graves are put between the trees in the forest, be a hole in the forest using a multipolygon relation.

There are woodland cemeteries as well. Also, for jewish cemeteries it is not that uncommon either.

If these are common then that's really a problem. But it can't be solved by inverting the current drawing order, since that would break every cemetery/graveyard with a small area of trees in them, which in my experience is very common.

And what about the other cases, e.g. a forest in a military area vs. a military area in a forest?

Yes, this is a problem, and I'm open to suggestions, but they have to be practical or it's just noise.

Also, if you want to change the way ordering is done in osma this is the wrong place for it. File a feature request, at least with at least a sensible scheme and preferably with a patch.

I'm fairly certain it's much more common to have a small forest-like part inside a cemetery, so the layering should be kept as it is.

And re: the comment by petschge it'd probably be way to complicated and resource intensive to implement that kind of logic in XSLT, and having the implementations differ would be really bad.

Well, who still uses the XSLT renderer anyway, now that the default for t@h is orp? I don't think we should limit ourselves to what XSLT can do. If anything, this would instead be an opportunity to drop official support for XSLT.

I strongly disagree, it may be true that not many T@H clients use XSLT any more, but another important usecase is the ability to run the rendering client-side with nothing more than a webbrowser.

or/p is a nice optimization for t@h, but I'm not holding my breath for firefox and internet explorer to start supporting running random perl-code.

And AFAIK, XSLT doesn't support advanced multipolygons, while ORP does, so there is already a difference in an important feature.

True, that's a missing feature in XSLT, but if you want to get into a pissing contest about feature-completeness in or/p I'll happily go along, but send that to me as a mail, it's not relevant in this bugtracker.

It's not as straight forward as it sounds to use that kind of size-ordered drawing either, mapnik does and there are some corner cases where it fails horribly and there seems to be no sensible workarounds.

Out of curiosity: what are these corner cases? Right now I can't think of any that don't involve cases where one area is not completely contained in the other.

Most of them might involve that kind of areas, yes. Do you have a solution for it?

Unless you cheat and do what osma does for the size-dependent area rendering now and look only at the bbox, then you get all kinds of weird shape-related problems.