|
Hello, there. I modeled here a needle-leaved forest parcel in a bigger broad-leaved forest as an inner multipolygon, but this inner parcel is not rendered, as if there was nothing here, a big hole, full of nothing, in the middle of the forest. I'm wondering: did I messed up the modelling, or is the area misrendered? Awaiting your answers, Regards. |
|
Hard to believe but: "Not a bug, it's a feature" As I've learned only recently too, after years of struggling and wasting endless time with this and other "mysterious forest bugs", those empty forest-in-forest inners are not a bug at all. This behavior is fully intentional! The reason is that otherwise the old legacy style to create multipolygons would not work anymore. Way back when MPs were first invented, things worked completely different: the forest tag HAD to be given on all outers AND all inners too, not in the relation itself. Therefore it was decided, when the "new" method was introduced years later, that if inners contain the same tags as the relation itself, renderers SHALL keep ignoring such "duplicate" tags on inners. To keep compatibility with that legacy method. Can't remember anymore where exactly this was explained by one of the osm history experts... Have read it on some discussion page, perhaps in a forum or the Talk mailing list. And the wiki contains a giant quotes collection of multipolygon discussions, some 30 pages filled with MP discussions going back some 10 years! Perhaps it was in that huge heap somewhere: The recommanded workaround for this non-bug with different leaftypes was to either The prob is, hardly anyone is aware of that issue, myself included until only recently, and therefore have occasionally "fixed" such "nonsense 1-member-relations" or "nonsense duplicate ways" :-( Anyway, the example in the first post above contains 2 mini-forest inners. PS: of course this affects not only forests but all sorts of MULTIPOLYGONs, incl. meadows, water etc. |
|
I dont expect to see much difference. Forest areas have a minor casing and the rendering does not distinguish between areas with different leaf_type tags (at least in part because this depends on a major refactoring of the osm2pgsql database schema). At best one might expect However I think you would expect to see narrow green lines outlining the parcels. SomeoneElse has mapped an area of mixed woodland in Nottinghamshire in detail: http://www.openstreetmap.org/#map=16/53.1443/-1.0733&layers=C. You can also view the area in Overpass-turbo here. This area is a useful testbed for creating a reasonably sized data set for extending the cartography, but perhaps more importantly understanding what is involved in mapping such places. You can make out the thin lines separating the different compartments, which should also be there in your case. 2
My vague recollection is that there's a known issue (possibly historical, possibly with osm2pgsql) with a multipolygon inner having the same area tag as an outer which causes the inner tag to "disappear". If someone can find the same situation (inner forest or wood polygon within an outer) in the UK or Ireland I can investigate further.
(28 Sep '16, 11:08)
SomeoneElse ♦
1
For info I've reproduced the issue here, with a "mixed" inner in a "broadleaved" outer: http://www.openstreetmap.org/#map=19/53.18662/-1.34311 My own rendering, which treats broadleaved wood as different to mixed wood doesn't show the hole (it renders a mixed area inside a broadleaved area) but OSM-Carto does. Issues have been raised at https://github.com/gravitystorm/openstreetmap-carto/issues/973 and https://github.com/openstreetmap/osm2pgsql/issues/185 . That osm2pgsql issue seems to have been closed because it was an "old-style" multipolygon, which isn't the case in my example. It probably needs raising again at osm2pgsql's github (I can't see a current issue describing it). A workaround would be to avoid the use of multipolygons where possible (which makes sense from an "ease of mapping" perspective if your dealing with multipolygons that are "most of Thailand" or "most of Quebec") but in a simple example like yours a multipolygon should be a sensible way to map it.
(28 Sep '16, 13:16)
SomeoneElse ♦
1
I didn't expect to see a difference either: I knew that different rendering for broad-leaved and needle-leaved wasn't effective because of some database issue, but I mapped it anyway for the day it will be rendered. Besides, I expected the inner polygon to be rendered, even if it is rendered the same way than the outer one; its disappearance is unexpected, and a bug IMO, as the underlying data is, AFAIK, valid, unless one can explain me why the data is malformed, or unoptimized, and why it causes the rendering bug. I opened an issue on Github for that: https://github.com/gravitystorm/openstreetmap-carto/issues/2381
(28 Sep '16, 15:38)
Penegal
|
This issue has been fixed, and such inner polygons are now rendered correctly.