Why should it? It is, very literally, what is there!
4 Likes
overpass turbo , I was surprised to find some (just made the check for a town, for the Netherlands, it took a while, 4,274 individual trees in 31,694 rows in your country).
So an average 0.13 tree per tree row 
.
1 Like
So is a tree in a wood, but mapping it is not very common.
1 Like
Most of those are mine, concentrated in Zuid-Holland. I am reviewing those now; most of them will disappear in the coming days. So far I encountered two other mappers who did a few; of course I will leave those nodes as they are.
Well yes, but mapping individual trees in a wood is essentially impossible - you canât accurately survey individual trees in dense woodland on the ground or from imagery. Trees in a tree row are often easy to see from either.
Mappers already have the option to map tree rows with natural=tree where there are trees; we donât need to change wiki definitions just because someone doesnât want to add that one tag where there is actually a tree.
7 Likes
IIRC there was a comment(s) in the German forum on mapping both, row and individual trees, so youâd find them likely there as well in a TO. Moi, maps one or the other, not both. The many pine tree rows here with complete intertwined tops and the rarely straight trunks make that a challenge⊠the trunk is most always not at center.
In dense wood, itâs impossible to map individual trees, but wood comes in a variation of densities. Many wood areas show individual trees, in fact mappers often make a choice whether to map individual trees or an area of wood.
The same goes for tree rows. Often you can locate individual trees (though itâs very hard to do this from survey; you need quality aerials and/or quality open data), and often you canât. Even with quality aerial data, you often canât tell where exactly the main stem is.
I can see in our governmental open data that their administrative mappers struggle with the same issues as we OSM mappers: where exactly to place the trees, do I map a wood area or individual trees (sometimes they map trees in wood), do I map all the trees in a tree row or do I map a line (sometimes they choose a line and only the first and the last tree). And accuracy is sometimes good, but most of the time I can improve considerably. Some official cartographers just distribute a bunch of trees evenly along a line to approximate the density of the tree_row, ignoring missing trees and in effect placing all the trees wrong. Others appear to be copying from plans instead of mapping the actual trees. And maintenance⊠I know places where kilometers of tree row have been replaced years ago, by different trees at different distances and often on a different âheart lineâ a few meters apart from the previous line, but the data still shows the old trees.
(I can tell, because we have both excellent aerial photography (little or no displacement) and open governmental data (no displacement) as overlays in JOSM.)
In short, I think accuracy of tree placement in OSM (node in the centre of the stem where it hits the ground) is quite low on average. 5m off is no exception. I try to improve on that, of course.
Did I propose to remove the option to tag individual trees in the row with natural=tree? No, I did not. I do get the impression that this is mostly done if there are special trees in the row which merit additional tags. Mapping all the trees as natural=tree AND the row as natural=tree_row, is not common practice, to say it mildly. Most mappers choose one or the other.
Did I propose to map all the trees in the row as separate nodes? No, I did not. I just proposed to recommend that any extra nodes be placed at actual tree locations. Which reflects actual practice, because: extra nodes are only needed where the direction of the row changes, and that can only happen at a tree location. Even if you canât make out individual trees on imagery, you can identify the place where the direction changes, and there will be a tree there. This also holds up for trees placed along a âcurvedâ line.
Where did I propose that?
Ah, I see. I did not mean to recommend to map all the trees in the row as nodes, just that if you add a node, for whatever reason, to place it at the location of a tree. Which is hard to avoid anyway, because, well, itâs a row of trees.
PS: actually my first proposed text was:
Well it would still offer the opportunity to place a node on every tree in the row which I understood was your point:
That would make sense to me whereas rendering trees for few nodes where the row has a bend would not add much value imo. Either I want to show individual trees in the row or I donât.
- If mappers choose to map a line of trees as a
natural=tree_rowway, thatâs fine. - If they choose to map them as individual
natural=treenodes, also fine - If they choose to map them as a
natural=tree_rowway, with untagged nodes along the way to show the shape of the tree row, regardless of whether or not they land on a tree trunk⊠fine. - And, if they choose to map them as a
natural=tree_rowway, with each node being placed upon a tree and taggednatural=tree, this is also fine.
I am not actually seeing any problem here, only different ways to map the same thing with increasing levels of fidelity. Most of the time when I map a tree row, itâs because I canât be arsed to plot out each individual tree.
4 Likes
I also did not say that the nodes should be rendered as a (regular) tree. If I were rendering these nodes, I would stick to e.g. a small dark brownish dot, reminding of a stem rather than a tree with a crown. Then it wouldnât look strange at all to see them only at the beginning, at the end, and at bends, because these are significant points in a row.
Should the row have nodes at all trees, it would have as a bonus mainly that it would show density (average tree2tree distance) and exceptions (missing tree, unequal distances).
Should a render decide not to handle this at all, nothing much would change, because the overall row is still the same row.
Personally I will not mark individual trees in a row.
There are a good many new lined up trees in the neighbourhood, they all have the same problem: first year, about two in a small row, four in a large one, wonât survive. The row is still recognisable, but it is a dead tree contributing to it (sometimes as a node). Next, third, fourth year, same problems.
Then (some of) the dead ones are replaced. A double row (same or different type) to (partly) adjoin it, alternating front and back row, with of course the same problems.
Like a dense forest is a unit, here the line is shaping the landscape, the individual tree is not.
I think adding a node to each and every one is a tedious and imho unnecessary task.
3 Likes
Thanks, I think you voiced the general feeling about this. However, the wiki says you can indicate the position of individual trees, and I see no reason to forbid that either.
In Nederland, for the majority of tree rows the individual trees can be seen on aerial imagery, and there is governmental open data containing the locations of individual trees in many municipalities. The accuracy often is not very high, though. Removed trees keep their spot, because usually they will be replaced within a year. Sometimes whole tree rows of several Kmâs are replaced or shifted, because a road, water body or field gets a make-over, and I noticed that the data often does not (or is very slow to) reflect the changes (different distance, different stem line, different tree type).
This topic is not about whether or not to map tree rows as a way, or as individual trees, or both. That ship has su^H^Hsailed.
It is about the wiki saying that a mapper can map all the trees as nodes tagged natural=tree on the natural=tree_row way. I guess the reason for this is that the renderer can use this to modify rendering of tree_rows without having to know density and stuff like that. What happens instead, is that renderers use a standard display for tree_rows and separately render the trees as usual.
(This is where rendering mappers can come in with âmy map does this completely different!â⊠)
I think that sentence should be reformulated to recommend this only for special trees, where you want to indicate why this tree differs from the others in the tree row. Imagine a tree row of willows where every 10th tree is an oak. Park designs have that sort of thing. That would be a reason to map the tree_row and place natural=tree nodes where the oaks are. I regularly map hedges-with-trees-in like that.
But what I proposed was to recommend that any plain nodes of the tree_row way be placed on tree locations. Note: this is not a recommendation to map each tree as a node; itâs the other way around. Which should be standard practice already, because:
- The first and last nodes are by definition on the first and last tree stems.
- Corners and bends in a tree row can only be trees; tree rows consist of straight lines between the adjacent stems.
My project in Nederland shows that this generally is the case, except for long curved tree rows, where nodes used to draw the curve tend to be in between two trees, but seldom exactly in the middle. The inaccuracy is max 1/2 the distance between consecutive stems, that is, usually within 5 m of the nearest tree stem, and still under the crown. Many separate tree nodes, when mapped from aerial imagery, have the same inaccuracy.
The reason is that this lets mappers (if they care about it) map the tree row at a higher level of detail, for example by indicating âŠ
- attributes which differ between trees, such as different heights, different species, and so on
- the location of each tree. In perfectly regular tree rows, you could get the same result by mapping the number of trees or the distance between trees, but as soon as you have missing trees or slightly varying distances, thatâs no longer possible.
And of course it then lets applications (if they care about it) use that extra detail.
It already says these extra nodes âmay beâ added and tagged as natural=tree. I think we can leave it up to each mapper to decide which reasons they find important enough to justify that extra work. Your proposed reformulation misses some of these possible reasons, such as indicating the locations of the individual trees in a row.
Iâm inclined to disagree.
Obviously, the lines between the trees only exist in peopleâs minds, so there is no objective way to determine whether this claim is âtrueâ. But people have contradicted you on it, and your own observations show that existing data does not always match up with that mental model of tree rows. (See: curved tree rows.)
If we accept that it is possible for the inner nodes of tree rows to be in a location where there is no tree, we cannot reliably derive any useful information from their placement. So it confers no benefit to recommend that they are placed according to any particular rule.
2 Likes
⊠and that is why mappers might map it. Full circle. How many mappers map all the trees in tree rows AND the tree_row?
Itâs not a claim, itâs fact. The tree row is made up of the lines between the tree stems. If it changes direction halfway, it runs up to to a tree, then from that tree to the end or the next bend. I observed that existing data would have a hard time not to match with this, within the accuracy you may expect with tree mapping. If a mapping clearly places nodes outside the tree progression, itâs probably simply an error. Which I also observed, and corrected.
But never mind, the whole topic is not that important. Most mappers do not map trees and tree rows at all, and many trees and tree rows are never mapped. I will use my own guideline, itâs conforms to the current state of the wiki and improves a little on current practice, by making sure that bends and corners are at tree locations.
This makes sense if more details are available on open data and if open data is accurate and regulary updated. Otherwise maintenance will probably not been done. Note that some mappers check locally and inform data providers of discrepances.
And having the producer of open data contributing to OSM, helps too. It doesnât avoid discrepances!