I recently noticed that many lakes that are lying inside a forest have the forest symbols (grey tree shapes) throughout the water surface in the standard rendering. The way to solve that was easy: Add the line that marks the lake’s coast to the forest relation, so that it’s recocnised as forest border.
Now look at waterways that flow inside a forest: Those also have forest symbols on the water surface. At least for all rivers I have looked at. But waterways are not areas, they are just lines, so they can’t be used as a forest border as far as I understand. Is there a way to tag the stuff in a way that the rendered map isn’t showing the rivers filled with trees? Is this a flaw in the rendering? Do you have an example where it’s rendered correctly?
Can you link to where you are seeing this? Different renderers do different things, and sometimes a different approach is taken to OSM mapping in different places in the world.
In OSM, they are often both. Here is a linear waterway and here is the area polygon that has been drawn around it.
I am specifically talking about rivers that go through a forest. You could look anywhere around the area to find examples, one is here: OpenStreetMap
The more you zoom in, the more tree symbols are rendered in the rivers (of course).
Everybody, please get zen with me for a minute and see this as multi-dimensional. There was a day that a mapper mapped a forest, without much regard to rivers. There are many mappers who map rivers, careful with their boundaries and edges, not necessarily paying attention to the forests around them.
Sometimes we carve out areas with relations using an inner role tag. But, OSM being a relational database, there is a level to which this denotes that remains sane. Complex edges, OK, but only once (in any given relation). Difficult to grok morpho-syntactics, yes, that happens, let’s minimize it as it’s already getting out there (in complexity and comprehend-ability). Relations should specify no more than a Goldilocks amount, not too much, especially.
Listen to many mappers about the “edge” (between forests and rivers, and the many ways that they are “drawn” and “shared”) in OSM.
Part of “seeing tree shapes in the water” (river, blue…) happens at OSM’s edge between tagging and rendering. So, peek-a-boo, I see you; we’re here again. It’s OK, it happens a lot.
This gets sorted out in different ways around the world. @Makeena, you seem standing at an edge of discovery of many ways to do this. Listen.
I would say it’s quite common this way and the easiest approach 
Though the order of rendering is a bit odd. It seems to be green forest area, river-ways and then on top the “tree-overlay”. I would expect top render everything of the area first and then on top the ways.
Really, what’s going on is that exactly how “two polygons which overlay each other” (one a forest, the other a river) are actually undefined as to how they render. You can affect this with various strategies, but I have learned to consider spending too much effort on this right on the edge of “wasting time.” The important thing is to capture into OSM what is “really there.” Let renderers “do their best” to draw the results, while understanding that sometimes we are going to see “overlays” and sometimes we are going to see “something clever that takes into consideration such overlays.” It isn’t really defined, and the renderer is allowed to draw / display / show us whatever it wants to.
Use the data that are in the map to decide if what is in OSM are correct data, not how things look rendered by any particular renderer.
Agree with you, overlapping polygons are never easy and usually a guess-work and should be avoided. But the given sample is a waterway-way on a forest-area. So at least to me the order is quite clear.
But will Carto change? I don’t think so
Actually, in the example provided it was one linear feature (the waterway) and one polygon (the forest). However, the effect is usually much more obvious when two actual polygons overlap.
Actually, I think that this is a deliberate (and correct) design choice here. There are areas of the world where trees and water overlap (large swamps, mangroves, etc.). It does actually make sense to show “there are both trees and water here” in those areas.
Where water has been marked by polygons, it’s straightforward for mappers to “not have those polygons overlap” if they actually don’t. What isn’t easy is when the waterway is just linear. Here is an example in Derbyshire in England. The river is just represented by a linear way. It varies in size with the seasons and wouldn’t really make sense to map it as an area. There’s no real break in the trees where the river is, so it wouldn’t make sense to stop the trees one side of the river and start again the other. This results (on OSM Carto) with tree symbols drawn over the river.
An example of a map that doesn’t have “trees in the river” is here (one of mine). That’s the result of a few cartographic decisions:
- The region this map covers doesn’t have many swamps or mangroves or similar, so it’s easy to say “always draw water over trees” - most of the time that’ll be correct.
- The symbol for “broadleaved” is deliberately much smaller and greener, so there are fewer places where it might overlap with anything, and the “forest” and “wood” colours don’t have a tree pattern.
- Waterways are shown narrower than on OSM Carto
- The “broadleaved” pattern isn’t shown at low zoom levels.
One thing that OSM Carto might try (and of course anyone can take a copy of OSM Carto and have a go changing it themselves) is to allow swamps to be shown as now, but always draw linear waterways over trees. I suspect that that would cause some artifacts where linear waterways go through water areas, might it might be worth experimenting with.
Edit: For info, an example where a pond in some trees was not marked as an inner of the trees. That’s arguably a mapping error, but is provided just for comparison.
There are some details for sure carto could render better than it does now. Making sure that tree symbols do not touch the blue line of a creek or little stream winding its way through a forest may be seen as such an detail but I would not say it is an issue of any importance.
Such small waterways are usually completely covered by the forest canopy with trees standing very close to the creekbed or even within from time to time so the actual rendering reflects the situation on the ground quite well. I would not see any reason to change that. Just my personal opionion.
yes, mark area which is not tree-covered and exclude it from area marked as tree-covered (using multipolygons or by splitting area into parts)
if you link specific location and ideally post photos of locations (that can be used for mapping) you are more likely to get more specific advise
In the example of the Lathkill that I mentioned above, I don’t think that terminating trees on one side and starting them again on the other would be the best answer. There’s no real break in the tree cover, so “not micromapping the river area” is not just laziness, it’s actually more accurate than the alternative. I’d be more than happy to do that where there’s a genuine gap on the ground, but not where there isn’t.
in such case making fake breaks would be definitely wrong (and my advise would not apply as there is no area which is not tree-covered to be mapped)
in such case tree marks appearing over river also seem fine and accurate
When I look at the aerial photos in this area, I see treetops and only sometimes a short section of stream (orthophoto Canton of Zurich from spring 2021). I think it’s fine the way it’s currently presented. This is a design decision by the renderer (here carto-osm) and I think this is the right decision:
First, the landuse=forest is rendered, i.e. the green area of the forest (the forest floor as a surface). Above that, the ways of the streams are rendered - they flow over the forest floor. And then the layer of the tree symbols, in this case mixed forest, is rendered above it. That seems logical to me, the trees stand on the forest floor and the treetops are above the streams.
The fact that there are small gaps here and there - ok, that is generalised. That’s ok too!