Improvements for natural=tree

[PanderMusubi]

Here are some improvements for natural=tree, see also https://github.com/simonpoole/beautified-JOSM-preset/blob/master/master_preset.xml#L10388

The key taxon is used rarely, species is the most important. Genus can be derived from species but is good to have in there, nevertheless. See also https://wiki.openstreetmap.org/wiki/Key:taxon

The keys type and cycle are no longer to be used for a tree, so these need to be removed as well. See also https://wiki.openstreetmap.org/wiki/Key:type and there is no wiki page for key cycle. Instead of these leaf_type and leaf_cycle need to be offered. See also https://wiki.openstreetmap.org/wiki/Key:leaf_type and https://wiki.openstreetmap.org/wiki/Key:leaf_cycle (Note that mixes for natural=tree should never be chosen. That is for forests etc.)

To be added, as it can be measured relatively easy by surveyors, is circumference. See also https://wiki.openstreetmap.org/wiki/Key:circumference

See also the following screenshots. What is a property and what is a detail is for me for trees prety much the same. Keys genus, leaf_type and leaf_ cycle can be derived from species, so those are to me details. A tree does often not have a proper name so that is for me a detail too. When it has a name, it usually also has an organisation taking care of it, so the key operator is also good to offer with name under details only.

[SK53]

All the notes here completely conflict with recent experience of using Vespucci for mapping trees (session at SotM-Fr 2017 in Avignon. Both genus & taxon may be required when generally mapping trees & particularly those in towns & parks: the principle use-cases are for trees not identified to species, cultivars such as Lombardy Poplar, Copper Beech, cultivars w/o a specific name such as many flowering cherries (Prunus 'Kanzan').

[PanderMusubi]

Thanks for your contribution. I agree that taxon should remain. However, type and cycle should be renamed as they are deprecated abd replaced as described.

[simonpoole]

With exception of adding a circumference tag this seems to be a non-issue as we have always used leaf_cycle and leaf_type (the human friendly labels don't use "leaf").

[SK53]

If I was to lose anything from this dialogue box it's the name field: very few trees have names & it is likely to encourage people to place vernacular or scientific names of the species/taxon in the field. I'd also like to see height & circumference at bottom of dialogue. My experience is one wants to fill in at least one of genus / species / taxon and if time permits or one hasn't identified the tree leaf_cycle & leaf_type. My experience so far suggests that for first pass surveying height & circumference are too much if one is collecting tree info for an area (e.g., perhaps aiming for 40-50 trees mapped in an hour).

[simonpoole]

name should clearly be optional, the current preset likely goes back to when we were only mapping trees of special significance and/or landmarks at that time name was probably used regularly.

[PanderMusubi]

Ah, now I get how it is put together. For users who know also the key type https://wiki.openstreetmap.org/wiki/Key:type exists this could be confusing. Personally, because of the one but last bullet in on that wiki article, I got careful not to enter any values there. Would it be okay to write the full labels as there is space enough and prevent this situation?

I also noted that values we use regularly is operator=name_of_local_government_or_land_owner and source=survey/local knowledge/survey;local knowledge so those two key I would like to propose to be added too.

As for normal surveyors, all that can be observed or measured easily and applies to most trees should be offered. For example height is not suitable for this, as it is hard to measure. This is better done with low-altitude radar imagery. https://forum.openstreetmap.org/viewtopic.php?pid=642577#p642577 However, details such as circumference, but also crown diameter can be measured easily during a survey.

In short my proposal is:

1. rename label "Type" to "Leaf Type" for key leaf_type to avoid confusion
2. rename label "Cycle" to "Leaf Cycle" for key leaf_cycle to explain bit more
3. add key circumference with label "Circumference (m)" to capture during survey
4. add key diameter_crown with label "Diameter crown (m)" to capture during survey
5. remove key name as it is rare
6. add key source with label "Source" to fill out during survey
7. add key operator with label "Operator" to fill out during survey

I am looking forward to your views for each point. When we have consensus, we should also have a look at tree_row "Tree Row" as it offers height, which is not only hard to measure but can also differ per tree in a row.

[simonpoole]

Source tags on objects have not been considered good practice for a long time (with some limited exceptions).

Note that this is the wrong place for arguing about new or changed tagging, that should be done on the tagging mailing list

[PanderMusubi]

Thanks, I will move the discussion there and post the result back here.

[SK53]

I think the standard view of Vespucci is that source belongs on the changeset: it doesn't provide any support for source tags in any of the presets. So requesting this is a much bigger issue than just trees.

Height can be readily measured using a clinometer or an app in a mobile phone or the old trick of holding a ruler up a known distance from the tree. I've not had great results with available OpenData Lidar yet, perhaps because the available metadata is not adequate (are trees in leaf etc). So it makes sense to leave it there.

I'm not sure about operator: firstly it's often more complex than ownership because tree maintenance may be let out as a contract; secondly, ownership can often be inferred from other data (landcover/landuse polygons, location adjacent to a street etc).

I'm also fine with height on tree_row: in practice this should be the average height of mature trees in the row (a local 200 year old one is having a lot of removal of trees and replanting but it doesnt make the row look very different). It might make sense to alter descriptive text in this case.

Finally, my belief is that mapping trees would be best served by a dedicated application which provided additional information: simple identification guides, glossary of terms, extensive pick lists of common tree species and cultivars, tools to help measure height, calculate biomass etc.

[PanderMusubi]

I have processed the discussion from https://lists.openstreetmap.org/pipermail/tagging/2017-July/thread.html#32862 in combination with latest data in taginfo and articles on the wiki. The result is in https://josm.openstreetmap.de/ticket/16222

Please continue any discussion there. When that patch eventually trickles through to this project, this issue can be closed.

[PanderMusubi]

Here is already an SVG icon for in icons/svg-osm-icons/natural to represent a tree stump.

tree_stump.zip