In order to be displayed properly, renderers like OsmAnd require that land use areas (e.g. lakes, reservoirs, farmland…) drawn inside a larger land use area (e.g. wood) must be assigned to a shared Relation using inner/outer roles.
Land areas seem to cover both natural=* and landuse=*. Ways/nodes are not affected.
In order to be displayed properly, renderers like OsmAnd require that land use areas (e.g. lakes, reservoirs, farmland…) drawn inside a larger land use area (e.g. wood) must be assigned to a shared Relation using inner/outer roles.
rendering doesn’t matter, it is a question of meaning, some features that get tagged with landuse are not actually about „use“ but about cover (e.g. „grass“) and these can conceptually overlap with use information. Otherwise a spot cannot be e.g. a lake and a field at the same time, so it is correct to not tag both things on the same land.
that is because it is general meaning of geometry? If you have larger area A and area B inside (without multipolygons), then points inside both of them are in both of them. Though something similar to Tag:place=island - OpenStreetMap Wiki can be added there, feel free to do so.
the bigger issue is missing established tagging for forest not as “tree-covered area” but as “named place that includes also treeless glades and clearings”
the bigger issue is missing established tagging for forest not as “tree-covered area” but as “named place that includes also treeless glades and clearings”
This is not a specific issue for forests but for all named geographic features that refer to areas with significant extent.
the original landcover proposal proposed to use natural for this, but this way of reading the tag structure wasn’t generally shared and people used natural more and more „natural“ for landcover as well (natural=mud, natural=sand, natural=bare_rock etc.).
Most of it still refers to (often named) natural features, be they areas, linear or point features, e.g.
tree
scrub
wetland
grassland
peak
cliff
heath
scree
ridge
spring
beach
glacier
bay
…
generally those forests that haven’t trees all over them but also cities, lakes and glades within aren’t really forests, they are geographic regions named after a forest
It’s not just “natural” or “landuse” - anything that might have a polygon geometry can potentially overlap with some other polygon. Whether that actually makes sense or not depends entirely on the context.
For example, the idea of a “highway=pedestrian” area is that you can walk anywhere in it. It therefore wouldn’t make sense for there to be overlap, and people would be expected to cut building-shaped holes in the pedestrian area, as you describe.
However, something like a “natural=water” polygon might well overlap with a “natural=wood” one, in areas such as mangroves. Where there is no overlap (no trees in the water) you have to cut a hole in the wood for the lake.
Renderers generally interpret overlapping polygons in one of two ways:
If the overlapping polygons “make sense” (like wood and water in the example above) they’ll often try and represent them so that both can be shown at once. OSM Carto (the “standard” renderer at osm.org) does this with wood and water, but I’m not sure what OsmAnd does.
If the overlapping polygons “do not make sense” then one will be drawn over the other. Often (and again, OSM Carto does this) the smaller will be drawn on top of the larger, where there is no other drawing order priority.
For example, the idea of a “highway=pedestrian” area is that you can walk anywhere in it. It therefore wouldn’t make sense for there to be overlap, and people would be expected to cut building-shaped holes in the pedestrian area, as you describe.
exactly, and there could be situations where you would have some overlap, e.g. if a building is hanging over the pedestrian space. There is no general rule besides looking at the individual situation, and yes, renderings will typically not get all such exceptions right / display them in a comprehensive way.
I think this is fundamentally a mistake and expects too much precision etc from OSM mappers.
The most effective way to process landuse (and other rendered polygonal areas) is to use painters algorithm, either a simple-minded set of predefined layers for rendering order, or the approach of OSM-Carto which also makes assumptions about smaller areas vis a vis larger areas which they overlap.
Actual processing OSM data to tesselate or partially-tesselate a scene is quite complex and really not worth doing for rendering. It requires a lot of very defensive programming as typically large numbers of invalid geometries may be produced as well as many odd geometries (slivers etc when two areas abut but not all nodes are shared). Any tesselation algorithm also has to apply similar rules to the painters algorithm to deal with overlaps anyway.
I agree with @SK53
There was a lot of complaint about imports in large territories like in north of Canada. Part of it was historically with sketchy vector maps produced from low resolution images. This is less a problem nowadays. But strict rules in OSM plus wood multipolygon make mapping very difficult in large forestry territories covered with woods, rivers, lakes, ponds, mash … A lot of complaint about Canvec imports but no solution yet for huge wood multipolygons.
Adding inside wood multipolgyon infrastrucures like power lines, landuse, etc. you end up creating multipolygons in multipolygon in …
There are implicit rules for highways that cross forests. Could the same implicit rule be applied, like « with 400+ kv power line or power substations, there is a wide wood cut, otherwise it burns » or «water has precedence over wood unless explicit rules (ie. natural=wetland, wetland=[swamp, mangrove]». Then, mapping would be a lot easier in these areas.
Should this be implicit, it would avoid cutting and cuting and cutiting.
Some of that is doable (the web maps I make assume that buildings are on top of pedestrian areas), but “woodland on top of water unless wetland” is tricky.
I don’t think that it’d be worth anyone trying to persuade the OSM Carto people to adopt this approach, but I’d certainly look at a suggestion of how to code it (and it needs to be “how to code it” not “it is a good idea if you would code it”, because the latter is implicit above)!
Yours does, Carto standard does not. Classic case, I mapped the post office building on St. Peter’s square. Still a no-show, but I’ve resisted making it an inner object like I’ve seen countless times elsewhere with buildings, kiosks etc made inner for the purpose. I moseyed over to F4 Demo 3D render map, where my post office does show up though, as it should be.
And then popped another one up few months ago. Buildings are suddenly required to have an area mapped around them when build on farming lands, regardless whether the crop grows wall to wall like we have many here, so suddenly hundreds of thousand of alarmistic flags showed up and the QA checking logic as of now is not yet able to handle buildings on multipolygons farming lands, at least last I looked. And the fun part, just 1 flag per farmland area as else the whole map would turn yellow pins. And someone inserted that it was not a good idea to make building inner directly, no it had to be an area around the building.
As for ponds in forests… no matter how big, lake size, unless made inner it renders in Carto with trees in it so guess what is done.
That said, go to the MP wiki and how it describes an area, a hole i think it’s called, one makes it an inner object to what was before a simple polygon. What applies to this applies in that logic to everything else. Carto standard is what every mapper gets pushed up front and everyone assumes Carto is right. If it’s not correct than that needs to be changed and surely I’ve seen on others rendered maps that ponds are treated as superimposing.
Another example. A picnic area in a forest. Have seen argument that the picnic site has trees all
over, Piano di Mele here is one, so it’s not made inner to get Carto to render trees thru. There’s a case to be made for that as almost no one is going to sit down and map all the individual trees in the area.
I’m actually OK with this, for the following reason: not all applications will consume buildings and a large pedestrian area without holes may be misleading, and particularly so if the data is used for routing. I therefore think that cutting holes in potentially routable elements is necessary (although obviously not sufficient) for routing. Of course, it is possible as SomeoneElse and F4 map demonstrate to make some assumptions about the implicit relationship, but if part of the relationship is not consumed at all, no assumptions can be made.
This is an exception to my general view on the matter: although I probably wouldn’t be consuming pedestrian areas directly for landcover/landuse.
That is because without inner polygon forested area is mapped as covering also water
not sure what you mean here, which QA? Is reliable QA like JOSM also complaining?
Can you link it? Is there square pedestrian area mapped as being uninterrupted by this building? Is this building underground/hovering/otherwise not actually interrupting it?
This is actually a technical limitation in how forest/wood polygons are mapped AFAIK. The symbology is an overlay in a different Mapnik layer and it is very difficult/impossible to sort out the layer ordering so both layers work in conjunction. Therefore the pond blue is overlaid on the forest green, but then the symbols are overlaid on both. I think if you search back through the PR discussion (c.2014-2015) this was treated at length, but as you say it is not wrong as the pond is not an inner.
Can you link it? Is there square pedestrian area mapped as being uninterrupted by this building? Is this building underground/hovering/otherwise not actually interrupting it?
there used to be a mobile post office in a container or similar temporary building on the square IIRR. Arguably it interrupts the pedestrian area
