SCEE
SCEE copied to clipboard
Upgrade "What is the genus or species of this tree?" quest
Use case People can answer the "What is the genus or species of this tree?" quest adding a genus or species value. The result is a tree of which we know the genus/species but that it is still missing the leaf_cycle (or even the leaf_type if the user disabled such quest or if they have quests in reverse order mode). These values can be deducted from the genus/species, and therefore could be automatically added along the genus/species.
Proposed Solution
In 2023 I created this wiki page: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree/List_of_Species (inspired by a similar one about genus). The table as today has 327 different species, with the respective leaf type and cycle. SCEE could use this list to automatically add leaf tags of species contained in it. The wiki could be easily converted to a .csv file if needed.
Btw the link reminds me of #582, which could add a lot of tree data, including the wikidata tag. With the wikidata tag we'd have a more reliable identifier.
I'm wondering is SCEE is best place for it, however.
If that leaf_type data always follows from genus/species (which makes sense to me) then instead of SCEE being modified to adding it always wouldn't it be better to:
- have an OSM bot which upgrades all trees with
genus/speciesbut withoutleaf_typeto add the missingleaf_type? That would then work with all editors (not just SCEE), and also work on already existing data lacking details. Sounds like a win to me?
or maybe even:
- if that is just data duplication[^1], perhaps it does not makes sense to keep it recorded in OSM at all? I.e. let data consumers which care about
leaf_typeparsegenus/speciesthemselves too (this sound better from database POV as it avoid problem with possibly conflicting tags, but requires more work from data consumers). Perhaps make an library (or even just easily parsable JSON or something) which makes it easy for them to consume it?
[^1]: like e.g. healthcare=hospital implies amenity=hospital
I'm wondering is SCEE is best place for it, however. have an OSM bot which upgrades
In an ideal world, we’d have a bot that automatically adds all this information, presets for every tree species in every language, validations for implausible heights/circumference/diameters in every editor, etc. But we don't have that, and I don’t think SCEE needs to be the best place for improvements like this, every tool can contribute in its own way. Osmose already has some flags, SCEE could help by auto-adding leaf tags, NSI could have tree presets ecc.
if that is just data duplication, perhaps it does not makes sense to keep it recorded in OSM at all?
That would exclude regular users like me, who can't deal with libraries or JSON files, and just want to run a simple Overpass or QLever query using the leaf_type tag. Anyway, I think this discussion should be made somewhere else, is not specifically about this issue.
if that is just data duplication, perhaps it does not makes sense to keep it recorded in OSM at all?
That would exclude regular users like me
Well, I'm personally not of the opinion it is a great idea to be explicitly adding automatically implied derived tags like e.g. motor_vehicle=designated on every highway=motorway (or leaf_type=broadleaved on every species:wikidata=Q37083) just to make it easier for users to consume data...
That being said; if people want to write such functionality for SCEE and @Helium314 is fine with that, I'm not objecting...
I was primarily trying to suggest that for about the same amount of invested effort - but writing a bot code instead of SCEE code - would bring same results but more reliably and to much larger amount of data.
Anyway, I think this discussion should be made somewhere else, is not specifically about this issue.
Agreed, that is what I wanted to ask too - has this idea (of explicitly adding otherwise automatically implied derived tags - see above) been discussed somewhere in wider community (OSM community forum or elsewhere)?
Some relevant links:
- Discussion about exactly this proposal (auto-filling
leaf_cyclefromspecies:wikidata) on the iD repo. - Similar discussion from OP of this issue.
- Discussion on just using wikidata instead of additional redundant tags.
natural=treeon the OSM wiki has a "Use of redundant tags" section under "How to map" that comments on exactly this topic.
Personally I am intuitively of the same opinion as @mnalis, it doesn't seem preferable to me to include tags in OSM that can be deterministically derived from other existing tags on the same feature. As a general principle I think it makes sense to minimize redundancy and to try to only serve to a consumer the information that that consumer actually requires. Because firstly, storing and serving information where it isn't needed is inefficient and secondly, because I think the community/organization/group for whom that information is actually relevant/valuable is pretty much always better equipped, qualified and suited to curating that data and related systems and applications than the general OSM community. For example, I personally think something like an iNaturalist species ID is ideally all you would store for a tree, then if you're building an application where you need/want information about that tree you'd use the species ID from OSM to grab it from iNaturalist because 1. That way you are going to get far better data than you'd get from OSM, 2. Effort isn't being wasted unnecessarily contributing and curating that data on OSM, and 3. You're not burdening OSM and other data consumers that have no use for that data with storing and handling it unnecessarily.
However, from the looks of it whilst there isn't exactly consensus on this specific topic or the question of tagging features with information that can be derived from other tags in general, it would seem that generally speaking there is a strong preference towards adding and retaining these redundant tags.
That being the case, I think it's probably worth implementing this suggestion of automatically deriving and tagging leaf_cycle and leaf_type from genus/species as part of the "What is the genus or species of this tree?" quest, if someone actually wants to spend the time to do so. I might take a crack at it at some point, if I ever get around to it.
I can see the argument that making a bot is a more effective way of solving this problem, but I agree with OP that this isn't a reason not to implement this in SCEE also.