I like to map trees. Last year, I wrote a diary about trees mapping, a wiki page to document tagging of Italian monumental trees tagging, a trivia thread about the tallest trees in the database etc. In this diary, I’d like to focus on quality assurance (QA) checks we can perform on tree data. Many of these checks have been turned in MapRoulette challenges in my Tree Validation project.
Measures 📐
• Circumference
The circumference=* tag is used to describe the circumference of a tree’s trunk at a height of 1.3 metres above the ground, with the implied unit of measure being metres. Therefore, circumference=2.3 describes a trunk with a circumference of 2.3 metres.
According to the Guinness World Records, the greatest circumference for a tree is 43 metres. Trees with circumferences exceeding this value are likely errors. Often people forget that metres is the standard unit, so they tag using centimetres, creating giant trees. E.g. they tag circumference=650 instead of circumference=6.50.
• Height
The height=* tag is used to describe the height of a tree in metres. Therefore, height=15 describes a tree that is 15 metres tall.
Hyperion is a coast redwood (Sequoia sempervirens) in California that is the world’s tallest known living tree, measuring 115.92 m. Trees with height exceeding this value are likely errors.
• Specific species measures
You can refine the above checks using known limits for individual species. For example, according to monumentaltrees.com, the biggest circumference for a Tilia cordata is 12.81 (instead of 43) and the tallest specimen is 41.60 (instead of 115.92).
• The “slenderness ratio”
The height-to-circumference ratio can be considered a form of “slenderness ratio”: lower values indicate stocky or stout trees, while higher values indicate slender or spindly trees. This can be helpful to find wrong circumference or heights.
- This Quercus robur has height=24 and circumference=0.01. This makes it the most slender tree of its species with a “slenderness ratio” of 2400, while the average for its species at the moment is 15.07.
- This Tilia cordata had height=26 and circumference=864. This made it the most stocky tree of its species. The problem here was the circumference expressed in centimetres instead of metres.
Leaves🌿
• Leaf type
The leaf type can be broadleaved, needleleaved or leafless. In case of woods and forests mixed could also be used. leaf_type=palm is also used, though disputed. Other values are likely incorrect.
Some examples I just took from taginfo:
- leaf_type=genus=Tilia is clearly an error, should simply be genus=Tilia
- leaf_type=Broad should be leaf_type=broadleaved
- leaf_type=oak should be leaf_type=broadleaved + genus=Quercus
• Leaf cycle
The leaf cycle can be decidous, semi_deciduous, evergreen or semi_evergreen. In case of woods and forests mixed could also be used.
Some examples from taginfo:
- leaf_cycle=broadleaved should be leaf_type=broadleaved
- leaf_cycle=coniferous is likely to be leaf_cycle=evergreen
- leaf_cycle=Quercus rubra should be species=Quercus rubra
• Specific species leaves
All trees of the same species should have consistent leaf_type and leaf_cycle.. I created a list of species on the wiki (inspired by the genus one). This list is actually used by Osmose and in the past I also proposed it to NSI for a new tree category.
This list can be used to improve trees without these tags or to QA trees that have mismatching values. For example, a tree of the Pinus genus should have evergreen needleleaved leaves, if not either the species/genus or the leaf tags are wrong.
Species and genus 🌳
An easy check is to check for species values that are one word only and for genus values that are not one word only:
- species=Quercus should be genus=Quercus
- genus=Quercus rubra should be species=Quercus rubra
Wikidata 🌎
Thanks to QLever, we can run some checks on Wikidata values. Some people often mistakes species:wikidata with wikidata, linking to a whole species instead that to a specific notable tree. Or they link genus/species:wikidata to Q-Items that are NOT instances of taxon.
- species:wikidata=Q52515011 this user wanted to link to the Laurus nobilis Q-Item, but linked an homonymous botanical illustration.
- species:wikidata=Q102322232 in this case the user wanted to link to the Malpighia emarginata Q-Item, but linked its fruit Q-Item instead.
- species:wikidata=Q55741734 the user wanted to link to the Quercus ilex Q-Item, but linked to a monumental trees of the same species (located +700km away) by mistake.
Mateusz’s OSM-wikipedia-tag-validator also has some wiki checks for species and genus.
Conclusion ✅
Tree mapping could benefit from far more QA checks in editors and tools. I believe more people would contribute if we had a dedicated site like WaterwayMap, but for trees. There’s still a lot of potential for improving data quality with better validation tools.
Discussion
Comment from mycota on 31 July 2025 at 15:22
One of the biggest problems with taxonomic data quality is that the names change all the time. It’s very common for a species name to change or to be split into two separate species. But it even happens at the genus level and above. One of the most common trees in Arizona was formerly known as Prosopis velutina, but now it’s called Neltuma velutina. The original name is semi-valid, but it’s considered a synonym. Is there any mechanism in Wikidata to add a new name and link from the old name in a way that indicates the old name is a deprecated synonym? And what do we do with all the trees in OSM that have the old name?
Comment from ivanbranco on 31 July 2025 at 17:14
I’m not an expert on how tree taxa are modeled in Wikidata, but I know there are relevant properties like P1420 (“taxon synonym”).
In OpenStreetMap, I think it depends on the case. For example, if a widely used name like Acer platanoides (about 94,000 uses) were renamed, it would be a significant issue. But something like Prosopis velutina, which only appears once in the database, is easier to handle manually.
Comment from Pieter Vander Vennet on 3 August 2025 at 17:07
Checkout https://mapcomplete.org/trees
Comment from Túllio on 5 August 2025 at 22:48
Excellent content, very useful for data standardization. I’ve been using https://mapcomplete.org/trees, and it helps a lot with maintaining data quality because it makes everything more intuitive.
Comment from Pieter Vander Vennet on 11 September 2025 at 00:16
I’ve now added a maximum height check and circumference check into mapcomplete/trees, it won’t accept trees bigger then 116m now