Moving natural=tree to higher zoom

[kocio-pl]

While natural=tree progression is nice in theory, in practice single trees do not belong to z16-z17 when tagged fully:

z16
Before

After

z17
Before

After

[kocio-pl]

Any comments or reviews of this PR?

[matthijsmelissen]

Agree, I noticed the same recently.

[jeisenbe]

It's a little odd that natural=tree_row now appears 2 zoom levels before natural=tree. Perhaps trees should still be shown on z17.

[kocio-pl]

Then we would have punished people for adding data in big cities, just like in the examples I have shown. Think about the forests - they are also visible much earlier than single trees and it makes sense.

I think this is not always best to use the simplest rules, unfortunately the world is much more complex. Finding the right rules is not straightforward task.

[jeisenbe]

The trees in the "before" pictures above fine to me. If there's a problem, it's the red, dashed footway/path lines.

Removing them from z16 was fine, especially considering how it would look nearer to the equator, but I'm not sure it made sense at z17, as long as tree rows are still rendered at z16.

[kocio-pl]

I see no problem with red paths, because they are not too dense and predictable, while single trees make visual chaos and are everywhere in this area.

I still don't get what problem do you see with progression of zoom levels forest > tree row > single tree? It's pretty natural for me that we start with complex objects and end up with single ones.

[jeisenbe]

Rows of trees along streets, paths, canals or between fields can either be mapped individually as natural=tree or as a single way with natural=tree_row. By showing only the latter at z16 and z17, this steers mappers towards using natural=tree_row so that the trees will render sooner. (Or alternatively, it may sometimes steer mappers to split up a tree row into individual trees, if they dislike the rendering on z16 and z17). In general, I believe this style should not give contradictory mapper feedback in this way.

[kocio-pl]

Sure, but this argument is also applicable in the case of the forest. If it's small enough and not too dense, you could represent it both ways even in practice.

[jeisenbe]

I'm totally ok with this style discouraging mappers from individually tagging every tree in a forest. :-) I believe this has not yet been done anywhere, has it? But it's not clear that natural=tree_row should be encouraged for rows of trees along streets or roads, rather than tagging them as individually with natural=tree, nor should natural=tree_row necessarily be discouraged. Even if we don't intend the different rendering for the two features as encouragement or discouragement, the difference will encourage some mappers to fiddle with the tagging to get a certain rendering effect. Such "mapping for the renderer" is a waste of mappers' valuable time, and should be avoided when possible.

[kocio-pl]

What makes me extra cautious in every discussion is a fact that a lot of people use "tagging for rendering" not according to how it is defined. It is bad in itself, but I expect people doing some serious work, especially related to rendering - as you do for example - to never make this mistake, to make a good example for other people.

Tagging for rendering is not about choosing the tagging with specific rendering effect, which is perfectly valid case, it is only about tagging false data just to have such effect. Both tree row tagging is valid, so this is not wrong. In a matter of fact I see no perfect way to do this.

Moreover current tagging promotes row, because it is shown earlier. I would like to promote both structure and more detailed tagging (not every tree in the row has to be the same!), but in this case chaos with individual trees is critical for me, so I'm OK with single trees being less visible than row object.

[imagico]

Tagging for rendering is not about choosing the tagging with specific rendering effect, which is perfectly valid case, it is only about tagging false data just to have such effect. Both tree row tagging is valid, so this is not wrong. In a matter of fact I see no perfect way to do this.

It does not really matter how you call it - the conclusion implied in this view, that any rendering strategy that does not specifically encourage mapping that demonstrably contradicts the observable reality is fair game, is not consensus in style development here.

The main goal of this style in terms of mapper feedback has historically been to limit itself to an affirmative role of supporting mappers in pre-existing consistent use of tags. Encouraging mappers to choosing the tagging with specific rendering effect is decidedly not part of this.

Anyway - back to the subject at hand. This change has selectively modified tree and tree row rendering (as it was previously designed in #978) by dropping rendering of individual trees from z16 and z17 while not changing anything else. A re-consideration and discussion of the overall tree rendering strategy of this style and the zoom level progression of the symbology in light of this change has not happened - which is what i have criticized in #3845.

[kocio-pl]

I believe it is important to use the right words for the problem to know what are we really talking about, to not make other types of error go unnoticed (like tagging for routing and so on), because this common usage twists the sense of this rule in a serious way, and to not mix encouraging (better use this than that to see it better) with forbidding (this is not going to be shown, no matter how proper it is in your opinion). I support the first one and I reject the second one most of the time.

The row case does not deny observable reality in both cases - it is an object in itself (row), but it consists of separate trees, one can observe this duality, especially if she cares for accuracy. Probably tagging for row should be better defined to let show individual trees (especially if not all of them are the same), then rendering changes can follow it, not the other way around. But this is separate thing from dot chaos, which is purely visual problem.

Of course there can be overview of tree tagging, but there are huge problems with natural=wood for example (with common different meanings) and that makes the whole idea very ambitious at best (and hopeless at worst). That solution should also allow tagging single trees in park for example, because they can look like a forest more or less, but each can have a ref (which I saw once in Berlin). And there is also the case you have shown in some ticket (I don't remember which one) with sparse trees and a grass mixed. Good luck with that, but I suppose it can easily take months or years of big discussions with no effect guaranteed.