Render waterways over natural=wood pattern

[LucFreitas]

Waterways are rendered below the wood pattern. It seems more appropriate to me that the waterway overlaps the natural=wood.

(https://www.openstreetmap.org/#map=17/-20.33539/-40.54868)

[jeisenbe]

It is recommended to map natural=wood areas to coincide with the areas covered by trees. This means that areas of a river should be mapped as waterway=riverbank and excluded from the area of the natural=wood. If a waterway=riverbank area is added around Córrego Santo Agostinho, the rendering will also be improved.

This issue is still relevant for waterway=stream features which are not usually mapped as an area. However, it could be argued that it's reasonable to show the trees overlapping the stream, since in practice it's common for narrow streams to be completely covered by the tree canopy.

[jeisenbe]

We render the scrub and tree pattern other other landcovers and water areas to encourage better mapping. But it's true that streams and rivers mapped only as linear ways do not really benefit.

It would be possible to still render the tree (and scrub) patterns over other landcovers, but not over rivers and streams, by using comp-op, as mentioned in #3854 (comment)

If we want to render the tree and scrub patterns over water areas, but not over waterway lines, this would require another layer, like this:

• landcover (standard layering)
• cut out water-areas and ocean (cut out with comp-op dst-out)
• landcover pattern overlay for water only (drawn behind using comp-op dst-over)
• landcover overlay for patterns over water and over land (src-over - standard layering)
• cut out water-lines (cut out with comp-op dst-out)
• Fill in ocean, water-areas and river-areas (drawn behind using comp-op dst-over)
• Fill in water-lines (drawn behind using comp-op dst-over)

(Then render rest of layers as normally)

[Pikse]

Waterway lines were displayed over wood/forest until very recently, as opposed to water areas that weren't. It probably isn't useful to map narrow waterways as area and these narrow waterways, even if in forest, are not necessarily covered by canopy. No overlap also looked kind of cleaner to me. So it would make sense to me if layer order was restored the way it was.

[imagico]

What has been changed recently is making the layer ordering more consistent with the way things are rendered. Rendering water linework above the landcover overlay while rendering it in the same color as water areas has always been a strange quirk and a source of confusion for the map user.

The reason why the landcover overlay is rendered above the water layers is

• because for wetlands in particular this is necessary for correct rendering since the wetland edge does not necessarily coincide with the edge of the water and the wetland mapping should be accurately shown in cases of overlap.
• because it provides better feedback on accurate mapping of landcover.

As @jeisenbe explained it would in principle be possible to make an exception for water lines while keeping the logical drawing order using some comp-op magic. But i am not sure if that would actually be desirable for the pictorial pattern overlays (wood/scrub/wetland).

[jeisenbe]

I think we should stop referring to composition operations as "magic." It's just cutting things out instead of drawing on top. Then we add the new layer behind instead of on top. Nothing magic to it.

[LucFreitas]

The Ribeirão Santo Agostinho is large enough to be a river, but the rainforest is too dense to show it. You cannot determine its width with aerial images at the points it passes under the forest. Not only this, thousands of other rivers in the Amazônia or Mata Atlântica, or any other rainforest in the world will exhibit the same configuration.

Also, one of the basics of cartography is generalization. You demand too much when you ask to map the area of a river. A mapper will take twice or triple the time and effort to map the margins, while it can only map the riverbed. Unfortunately we do not have the same labor density as there is in the US, Germany or the UK.

I don't know of any other maps that make the same way. Overlaying a forest on a highway follows the same logic.

---

pt/br

O ribeirão Santo Agostinho tem dimensões suficientes para ser um rio, mas, a floresta tropical é densa demais para mostrá-lo. Não é possível determinar a largura dele com as imagens aéreas nos pontos que passa sob a floresta. Não é só este caso, milhares de outros rios na Amazônia ou na Mata Atlântica, ou em qualquer outra floresta tropical do mundo vai exibir a mesma configuração.

Além disso, uma das noções básicas da cartografia é a generalização. Vocês exigem demais quando pedem que se mapeie a área de um rio. Um mapeador levará o dobro ou o triplo de tempo e esforço para mapear as margens, enquanto pode mapear apenas os leitos do curso d'água. Infelizmente não temos a mesma densidade de mão de obra como existe no EUA, Alemanha ou UK.

Desconheço qualquer outro mapa que faça da mesma forma. Sobrepor uma mata sobre uma estrada segue a mesma lógica.

[IgorEliezer]

I don't know of any other maps that make the same way. Overlaying a forest on a highway follows the same logic.

I followed the logic above here. If the road clearcut is wide enough to be relevant (the left side), then I map the vegetation borders. If not (the right side), the road goes through the vegetation, unless the region is near the micro-mapping level.

I'd say the same for the rivers that are about 4 m wide. Even you can spot the riverbank, it is still rough guess since the vegetation gets in the way a lot. Visually it breaks even between a rough guess by representing a narrow river with a single way and a rough guess by representing also the banks, except the latter is quite time consuming and tends to require multipolygons to avoid overlapping the river area with the vegetation.

[atorger]

I'm all for making it easier for the mapper to make a map that looks good. I've recently been adding, by hand, over 700 wetlands and lots of tiny streams and minor rivers, as lines mostly. It's a rural area, the only active mapper in the area is me. There's only that much one person can do. As long as it's possible I'd like the map to look good all the way from little information up to dense details. Where I live the amount of detail vary greatly, and to expect that all places will have full detail is unrealistic.

I don't think that "encouraging better mapping" by having poor rendering if there is less detail in the database is a good idea. I think it is kind of the opposite when you see all your pioneering hard work for a previously unmapped area is rendered sub-optimally. It doesn't feel encouraging at all, if you ask me.

While you perhaps can argue that there is some logic to having trees on top of streams, I know of no other map that does it. To me it just looks like a bug.

[imagico]

You seem to have the idea that you should as a mapper primarily aim for the map rendered with this style to look good. That is not the case and that is not what we aim you to strive for. As a mapper you should aim to document the geographic reality accurately and we aim to support you in doing that. For that purpose precise feedback on the mapping is paramount - mappers should be able to see from the way the map is rendered how and how accurately things are actually mapped.

Anyway, if you have an area you think is accurately mapped that you think is badly represented by this style w.r.t. the way the wood pattern and the waterways are rendered please point us to it.

[atorger]

I think openstreetmap is a bit of a frustrating project. I don't think it's a good idea that the default rendering or even the www.openstreetmap.org site is not really intended to be used by end users, but more as a diagnosis tool for highly experienced mappers, which seems to be the aim for the project. An unattractive default look and making it hard to map just makes it hard to recruit new mappers, which around here we are in desperate need of.

But even if agreeing with the overall goal of the style it seems very strange that openstreetmap should have a different way to render streams than other maps. Even the high quality government maps we have that cover the whole country draw streams on top. And openstreetmap did render on top before as far as I know, someone has changed the style, to the worse I'd say.

I understand that it is a challenge to make a style that should apply to all conditions in the world. Pushing the boundaries for mapping by making the style require more detail to look sane may be good in an area where openstreetmap has great popularity and lots of active mappers with new mappers being recruited all the time. My perspective is here in Sweden. There's less than 50 active mappers for the whole country, and large parts of the country still has very low quality next-to-unusable map. I've spent hundreds and hundreds of hours of mapping in a never-ending quest. Openstreetmap has lost popularity here as there are high quality official maps from the government available to the public via online services which most use (which renders streams on top by the way). Foreign/international online services still rely on openstreetmap data on some form, but few know about it so its hard to get in new mappers.

Regarding "accurately mapped", I think the question is not put right. It's about detail. We could push "accuracy" down to every single tree and small rock on the ground. I think a good style should render well with different levels of details, because that is what reality is in OSM and will be for a very long time. At a certain level of detail single-way streams through large blocks of forest is accurate.

But indeed, if the style is just intended as an analysis tool and not to be used by end users... well... then I guess it's fine. Then the other problem is that there is no official end use style available, at least what I know of. I think it would serve the project well if such a style was made and maintained and would be the default when viewing the map on openstreetmap.org.

Another comment is if forest are rendered over streams for the sake of showing the error in accuracy, why is not the same made for roads? It actually makes more sense as there is usually wider open areas around a road than a stream or small river. Of course I don't think that would be a good idea to also render roads under the pattern (but rather restore the original waterway behavior), but I just wanted to point out the inconsistency.

[imagico]

You touch a number of interesting subjects but some of them are outside the scope of this issue tracker obviously so i will try to address briefly only those i consider on topic here.

• the goals of this project are outlined here. As you can see this is not a simple black and white thing - there are multiple and partly conflicting goals.
• we do neither aim to favor either detailed or non-detailed mapping nor do we want to tell the mapper how they are to map things. What we aim for is for the mappers to be able to intuitively see how things are mapped, in particular we do not want semantically accurate and inaccurate mapping to look the same. Hence we try to stay close to the data and make the rendering represent the nuances in how things are mapped. If one way to map things looks subjectively more or less desirable we would want the more desirable appearance not to result from the less accurate mapping (hence we would for example not want a plain natural=wood to look more appealing than natural=wood + leaf_type=*).
• regarding what other maps do - traditionally produced maps typically use patterns which avoid collision of symbols with other features. This is expensive to do and not an option here so such maps are not a valid reference point for us. Use of patterns in automated rule based cartography is generally and increasingly rare (for reasons outside the scope of this discussion). This style and its variants are by far the most extensive user of polygon fill patterns. Other OSM based maps vary strongly in that regard, OpenTopoMap for example uses a complex system with three different landcover layers and comp-op. Furthermore geometric cutting operations (ST_Difference(), ST_Intersection()) on mapped geometries are usually out of the question for performance reasons here which further limits what we can do.
• For clarity - the current drawing order is (somewhat simplified)

1. Landcover
2. Water lines
3. Water areas
4. Ocean
5. Landcover patterns
6. Buildings
7. Roads
8. Rest

The old legacy drawing order before the move to ocean polygons which was more complex, highly non-intuitive and irritating for mappers and map users likewise and was generally a dead end styling-wise was:

1. Ocean (as background color)
2. Land polygons in plain land color
3. Landcover
4. Water line casing
5. Water areas
6. Landcover patterns
7. Water lines
8. Buildings
9. Roads
10. Rest

To answer your question why we don't treat roads the same way as water features. That is

a. due to the complexity of layering within the roads layers which makes interleaving this with the layering of other features even harder. See #529, #2046.
b. because roads unlike water features are not typically deliberately combined with landcover mapping - though this does happen - hence #3281, #3872.

[atorger]

Thank you for taking such time to make an elaborate response, much appreciated, and adds clarity. I still don't think it's a good idea to draw landcover pattern over streams and rivers, I think it's not intuitive and it unnecessarily makes maps harder to draw and maintain especially in less mature areas of the map. I don't think it's an "accuracy" thing. It's just not logical. Anyway, I've voiced my opinion on this matter now. I personally won't be mapping river areas around streams, but rather hope this style will change in the future.

(Regarding the goals I think it's no longer a good idea to use the map as feedback mechanism for mappers, or rather I think it does that well enough even if it's not stated as a goal, and further feedback should be built in into the tools (which there already is some). As far as I understand the original idea of the project was that the default osm render would be a rather rarely used technical rendering and actual end-user services would instead make their own renders. However, in practice the default render has become a frequently used front-end map for many services, especially in the open-source and web world where most don't have capacity to have their own maps, so how it actually looks has become more important than originally intended, and I think the project should adapt to that situation.)

[imagico]

Discussion of maps featured on the OSM website and map styles hosted on OSMF infrastructure is out of scope for this issue tracker. There is policy for maps featured on OSM.org but there is currently no policy on map styles hosted by the OSMF. You would have to take that up with the OSMF. Personally i am all for more diversity in map styles (especially cultural and thematic diversity) but i would consider it a waste of valuable resources for the OSMF to invest in hosting a Google Maps/Mapbox/OpenMapTiles look-alike or a simplistic and short-sighted puff piece style.

The goals of this style are open for discussion and change (in a separate issue obviously) but the mapper feedback function is a fairly undeniable fact (i.e. that mappers let their mapping be influenced by the feedback they receive from this style) so embracing the responsibility of this fact by working towards the goal to responsibly address this function is not something you would likely find consensus here to neglect.

[atorger]

Yes sorry for straying off a bit... to step back, what I think is not a good idea is the concept that it would be incorrect/inaccurate to map a stream as a single line on top of a land cover. I think that is a logical, valid and indeed commonplace way to make maps at a certain detail level, a detail level that is relevant for lots of places on the map. And thus I think the style should support that way of mapping.

If it is technically difficult I guess I could live with the streams getting pattern on top, as it's not something that is clearly obvious until you look closely, but I rather not see that mappers are encouraged to make river areas for their streams, as that unnecessarily complicates the map. If river areas should be required for small rivers (I don't like it, but I don't know how many that are with me...), I guess the proper way would be to render rivers as narrow as streams (or perhaps not at all) so it becomes more obvious that they should be represented by polygons.

[jeisenbe]

I think that is a logical, valid and indeed commonplace way to make maps

Agreed. Streams are going to be less than 3 meters (and most are less than 1 meter), so in the case of woodland areas there is often no break in the tree canopy, and that means it is fine to model it as covered with one area of woodland.

As mentioned in a comment above (#3883 (comment)), there is a technical solution which requires an additional rendering step (or layer) and the prerequisite of implementing the ideas in #3854 which I support.