I would like to talk about a refinement of the tree_row definition: add the recommendation that nodes be placed only on actual existing tree stems. Renderers may opt to show this in the rendering.
The current definition of natural=tree_row says: “Additional nodes may be added to the way at each tree trunk and these nodes may be tagged with natural=tree.”
Of course mappers may or may not do this, because mappers can always map individual trees. I would propose to add something like: Additional nodes are recommended to coincidence with actual tree stems.
This would give renderers the option to render the nodes in a tree line as actual tree positions (stems), even without the natural=tree tag. Mappers who want to indicate every tree position in the row can simply draw a line with nodes at every stem position they can verify, without having to add natural=tree to each and every tree.
I am proposing this after doing a lot of work mapping individual trees and tree rows.
I agree that your proposal would make mapping of individual trees in a tree row much faster. A negative effect would be that every node in a tree row line would probably be rendered as a tree even if the node is placed in a gap by a mapper who does not care about such details.
Most tree rows are not perfectly straight und require a node here and there to follow the shape. If a mapper only places nodes for this purpose there may be some 4-5 nodes in a row of let’s say 60 trees. If those 4-5 nodes would be rendered as individual trees, whereas the remaining 55 are not, wouldn’t this look a bit silly?
Well, that mainly depends on the rendering. If a tree row is rendered subtly and an individual tre in the row is rendered less subtle, as if it were a very important large tree with an extensive crown, then it would maybe look a bit silly. But I imagine that a renderer would treat trees in a row a bit more subtle, for example a small brown dot in the tree row to indicate the presence of a stem. Then, no, it wouldn’t look silly. Outside of OSM, I have seen maps which render the first and last tree of the row, and when there is a significant bend or a corner, place another tree there, or start a new row.
As long as each node in the row is placed on a tree, I think it can be rendered ok. If the mapper thinks that is not enough, and the information is available (we have official open data for trees in Nederland), they can add more nodes.
I have encountered corners and bends in between trees (some of which I have mapped myself…) . That is not consistent with reality. A tree row can only bend at a tree location! So nowadays I take care to put the nodes exactly where a tree is. If that means that the connection between the nodes at a corner would cross a water body, I just start a new row there. But most of the time it is a slight bend, and I can easily shift the node to coincide with a tree stem. These are typically the trees that you can see from aerial or satellite imaging.
Another example: OSM Carto currently renders very broad, coarse green lines for tree rows. Rendering an individual tree on that line (following the ÿou may add a natural=tree node for each tree), just adds a barely visible darker green dot. It would be no problem if those dots appeared only at start, end and bends; most people would even notice.
At the other extreme we have Tracestrack Topo, which renders tree row as rows of individual trees, disregarding the actual placement of trees. An extra tree or even tree nodes at all actual trees, do not make much of a difference.
What happens in the case of a tree row that isn’t straight, but the mapper doesn’t know (or doesn’t want to map) the precise locations of each of the trees?
(Changing things like this in a non-backwards-compatible way is problematic, since there’s likely to be existing data where mappers added nodes not necessarily corresponding to all the trees. Moreover, I don’t think it’s that much effort to add natural=tree to each node if you want to. JOSM at least has a function to select all nodes on a given way.)
Exactly. The idea enables a tree row which optionally has tree positions, but no natural=tree nodes attached. Just plain nodes, optionally, but if present they signify individual stems.
First, I propose to recommend that intermediate nodes be placed where a stem is. That is not a redefinition.
Second, the irst and last nodes are already definied as beinig at the stem of the first and the last trees. I do not know how many of the 1,2M tree_rows are just straight lines between two nodes, but where I live that is the majority.
Third, a tree row can only be bent at a tree. So nodes at bends and corners represent trees, even if they lack precision.
I have added and edited a considerable amount of tree_rows, and in my experience most treerows already are in agreement with this recommendation.
Note that the goal is not: to add all trees. The goal is: to improve tree_row mapping, without having to add nodes tagged as trees.
Direction changes in a tree row, if mapped correctly, will naturally be at or close to a tree location. Tree rows do not change direction willy nilly.
If a renderer decides to render nodes of a tree_row way, this would not be a problem in all the work I have done with existing tree rows. In Nederland, I might add, we have a fair share of tree rows.
I have been doing that, but it’s outright double tagging for the renderer (OSM Carto’s small dots appear in the green tree_row rendering). I will no longer do that. In addition, so many in themselves insignificant tree_row members mapped as full blown trees (without the tree_row way) will clutter most maps. I won’t do that any more either.
Would it make sense to add the number of trees in a row (tree_count=*) so that renderers can calculate the tree positions if they want (assuming equidistant trees)? Similar to address interpolation…
That is why most tree_rows only have start and end nodes, which are placed at the first and the last tree. No intermediate nodes because the locations are not known.
Where there is a bend or a corner in the tree row, an intermediate node may be present. The intermediate nodes will always be close to a tree, because you can’t bend a tree row far from a tree. If renderers would start to put a dot in the tree row at places where a bend or corner is indicated, it would not change much from current rendering.
Could it be that tree row mappers in other parts of the world do it completely differently, so that bends and corners are not on or very near trees?
I don’t understand the underlying idea. If mappers were to start marking each tree in a tree row as nodes, why not tag those nodes as trees?
I draw a tree row where I don’t want to bother mapping each individual tree, or if it’s not clear from aerial. If I were to map each tree, I wouldn’t need a tree_row way.
When mapping individual trees, I find it’s fast to tag each tree with editor presets, the slow part is identifying where each tree is and what properties it might have (leaf cycle, crown diameter, etc)
The current definition of natural=tree_row says: “Additional nodes may be added to the way at each tree trunk and these nodes may be tagged with natural=tree.”
I am not challenging the mapping of tree rows, nor the addition of nodes for each tree you can verify. It’s just that if mappers do that, adding the natural=tree tag to all these nodes seems redundant and mainly aimed at the renderer.
It may be ‘close’ to a tree in some sense, but I don’t think that’s really good enough. Consider a gently curving tree row, which the mapper has chosen to represent with say 20 roughly evenly spaced nodes. But in reality suppose there are 50 roughly evenly spaced trees along its length. You can’t really say those 20 nodes in any way approximate the locations of the 50 trees present. Some of the nodes will almost coincide with individual trees, but some of them will close to a mid-point between two trees. Most of the trees will not have a node near them.
I’ve done a sizeable batch, as a test. Putting nodes at the trees does make sense but adding natura=tree to them feels silly. That’s not going to catch on, I’m sure about it. I’m undoing the test batch, meanwhile micromapping and aligning the area so the effort is not entirely wasted.
Regular practice is to map straight tree rows with only a start node and an end node, and only id the trees are close enough together to be seen as a row. Intermediate nodes are used only where the row bends, and that is always at a tree.
Now sometimes you can’t see the individual trees, because they are intertwined and/or the stems are shielded. Now try and put a node on that line which is not on or very near a tree. If you can do that, it’s not one tree row.
As said, with Lidar data (DTM), you can. It’s not available everywhere and if DTM is very well done, you can’t. Left DSM, right DTM. BTW, I tag a tree row as… a tree row, not as individual trees.
Is anyone comfortable enough with overpass to write a query returning the number of natural=tree nodes attached to a natural=tree_row way? I’m sure in Nederland it’s a pretty low number, but I don’t know about other countries.
