Streetcomplete: Quest: support trees

Created on 2 Apr 2017  ·  17Comments  ·  Source: westnordost/StreetComplete

Please add support for individual trees, see https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

Make sure only to offer one-of-many choices such as leaf_type, genus, species and/or (when applicable for the species) sex. Note that for these four values, many can be derived when the most specific was chosen in the app. Best to consult the decision tree with a tree expert / botanist.

Other values such as taxon, name, circumference, height, diameter_crown and start_date are to be derived (taxon) or difficult to impossible to simply observe by looking and should not be offered.

wontfix

Most helpful comment

Based on @matkoniecz experiences with a prototype version of the quest, and the fact that he already implemented quests for leaf-cycle for (small) forest patches, I will close this ticket as will not fix.

To summarize:

  • type of single trees are rather unimportant, mostly only useful for 3D rendering
  • highly repetitive (waste of time)
  • tree type (coniferous or broadleaved) can often be determined easily from good areial imagery
  • Most importantly:

individual trees are impossible to precisely locate during survey and I was never sure whatever I am answering correctly.

So, the latter is a real problem that can and will lead to wrong data entered by the users.

All 17 comments

A common tag is also species:foo where "foo" is a two-digit language code. This is used for common names. I think it would be useful to have this as more regular people (non-wizards) know the common names rather than the scientific names. The relevant lang code can be pulled from the system language.

So maybe let's have a 'be sure of what you're doing' before the user inputs a scientific name in the species field, or worse: the user adds a comon name into the species field.

Let them pass a simple English or localises test first.

Mmh, maybe not the most urgent quest to implement.

Agreed, nevertheless a valuable one. Perhaps only start on this when offering a compulsory user test to check if they know what they are doing is easily available in street complete.

I used to have leaf_cycle and leaf_type quests in my fork but I removed them because

  • individual trees are impossible to precisely locate during survey and I was never sure whatever I am answering correctly. Maybe it would be improved by map showing locations of trees - but it is rejected by guidelines for SC map style
  • quests turned out to be extremely boring, even for somebody who really loves nature
  • I had constant feeling that solving this quests is a complete waste of time

Overall, I would not recommend adding this quest.

Hmm… do they map forests as single trees where you use StreetComplete? :laughing: :wink:
Because otherwise you may only find these in parks or some single ones at streets or so. I think they are both always the same (when in a row or so) and less often different when standing near each other,
And in parks one may not have too many trees at once to answer. I think there can hardly be a quest, which is even more boring than the street surface one in cities… :wink: That's why I just move it down from the priority.
So I still consider this not soo bad, maybe limit it to tree rows or so… (then you only answer once for a row, similar to how you do it for a street)

Maybe also consider https://github.com/westnordost/StreetComplete/issues/366 the follow-up of this issue and maybe generally the better idea. As the implementation should be the same for both quests, however, one may e.g. just include the _tree rows_ in the other quest there.

Yes, in my city some parks have individual trees mapped. Maybe in places with only major trees mapped it would be less flustering.

Some cities in the Netherlands have exported their tree databases under an open license and these have been imported into OSM. So some cities have tens of thousands of individual trees.

Here is an example. example F4 uses leaf_type to render the correct shape of tree.

It is certainly not to be used for forests, only for individual trees which are missing these details. See, as @rugk also mentions, https://github.com/westnordost/StreetComplete/issues/366 for more fine-tuned approach.

Hmm, ok. Now we have one argument in favor of this quest (F4) and one against it (the database import)…

However, once trees are mapped, they are mapped… 😐

If a tree is mapped, it can still be missing:

  1. leaf type
  2. leaf cycle
  3. an optional node relation for a man-made nest with:

    • man_made=nesting_site

    • support=tree

    • material=plastic, material=metal or material=wood

    • taxon:order=Chiroptera (for bats) or taxon:class=Aves (for birds)

    • (Omit species, genus and capacity as this is hard to observe or determine. Perhaps also store somehow that there is no man-made nest?)

Especially the man-made nesting site is very interesting addition to be made by StreetComplete users as they are usually not part of the open tree database from local governments. Note that natural nesting sites are not to be mapped.

example

See also https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Nesting_Site#Nest_for_bats_on_a_tree and https://wiki.openstreetmap.org/wiki/File:Nest-for-bats.jpg

Uh, that is getting very much…

Please note StreetComplete quests should not spam users. And I am very sure most trees do not have such a nesting site.

Also I do not see a concrete use case, just because it is not mapped in government databases.

And generally, I'd say this is a new quest type, so next time, just directly open a new issue. (and fill out/check the issue template)

Agreed, so only leaf type and leaf cycle then.

To keep it practical, query only leaf_type. In OSM natural=tree occurs 10,211,795 times. Of which 7,538,527 trees are missing leaf_type and 12,236 trees have leaf_type=mixed, which is not allowed for a tree.

If natural=tree has is missing leaf_type or has leaf_type=mixed, offer the user only leaf_type=broadleaved or leaf_type=needleleaved to choose from.

The query should perhaps also include leaf_type values that aren't 'broadleaved|needleleaved|leafless' for natural=tree, to fix up the mistagged trees. (It seems like leafless should maybe be spineleaved, given the accompanying images.)

The query should perhaps also include leaf_type values that aren't 'broadleaved|needleleaved|leafless' for natural=tree, to fix up the mistagged trees.

That is a poor idea, except cases that are clearly missing data (like access=unknown for parking access quest) existing data should not be overwritten silently.

Agree with @matkoniecz because this could overwrite (unwillingly,unknowingly) new tags which are in the making or starting to be used. I doubt it will apply here, but better to be strict.

By the way, leafless applies to huge cacti which are added as a tree or dead trees (which should be tagged as a pole or something else, as the original tree did have a leaf type). so I would recommend to stay away from leafless too.

Based on @matkoniecz experiences with a prototype version of the quest, and the fact that he already implemented quests for leaf-cycle for (small) forest patches, I will close this ticket as will not fix.

To summarize:

  • type of single trees are rather unimportant, mostly only useful for 3D rendering
  • highly repetitive (waste of time)
  • tree type (coniferous or broadleaved) can often be determined easily from good areial imagery
  • Most importantly:

individual trees are impossible to precisely locate during survey and I was never sure whatever I am answering correctly.

So, the latter is a real problem that can and will lead to wrong data entered by the users.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ecksun picture ecksun  ·  3Comments

RubenKelevra picture RubenKelevra  ·  3Comments

HolgerJeromin picture HolgerJeromin  ·  3Comments

nmxcgeo picture nmxcgeo  ·  3Comments

Helium314 picture Helium314  ·  3Comments