I get good results for cultivated plant ID with Google Lens. I use it when I want to ID a cultivated host plant for insect observations.
Can confirm! I am a professional scientist/professor at a research institution. I use “captive” plant data, my fellow faculty use it, and my students use it. Most people aren’t even aware it’s an option in iNat, because Casual buries IDs so you have to know how to find them. Every month or so, I have to do an onboarding meeting to help walk new students through how to access Casual obs, what limitations are, warnings about false IDs empty observations, etc. I find myself apologizing to students all the time that iNat has all these great features, but your plants don’t count so you can’t use them or have to use workarounds.
What’s funny is because these researchers are the experts on their particular plants, the best people to do authoritative ID on the species in the region have to have insider iNat experience (don’t bother with the app, uncheck this box in Explore, check this box in Identify…) in order to contribute IDs. And even if they get that far, they then have to wade through a lot of no location/no photo observations to find their plants. It’s unfortunately counterproductive and discouraging.
Recent uses we’ve had in the dept:
- Phenology of urban tree blooming for pollinator observations
- Urban tree growth habit variety and genotypic diversity
- Comparison of wild specimens, cultivated specimens, and feral/invasive specimens of a genus
- Locating particular cultivated species in unique locations
I totally understand identifier fatigue, I am also fatigued. If I see one more blurry shrub in a mulch volcano obs, I’m going to shove my computer out the window. However, letting us have a legitimate category of “Cultivated”, rather than dumping them in the bad ID slush pile, would make a world of difference for plant scientists/researchers. If I can take the time to filter out all the roadkill turtles when I’m on an ID tear, someone else can filter out Cultivated without taking added identifier fatigue.
It is a workaround to make identification a bit easier rather than a true solution, but I believe it should be possible to add this to the URL to find observations marked as captive/cultivated while excluding observations that are casual for other reasons:
&fails_dqa_wild=true
(From this thread: https://forum.inaturalist.org/t/how-to-use-inaturalists-search-urls-wiki-part-2-of-2/18792/)
Things that fail the wild dqa might still also have other issues.
I would suggest https://www.inaturalist.org/observations/identify?captive=true&d1=1900-01-01&geo=true&photos=true&fails_dqa_accurate=false&fails_dqa_date=false&fails_dqa_evidence=false&fails_dqa_location=false&fails_dqa_needs_id=false&fails_dqa_recent=false&fails_dqa_subject=false
which is captive observations that do have a date, a location, and photos, and which don’t fail any of the other dqas. But it still doesn’t distinguish between observations that have many agreeing IDs and those that don’t.
Since there is currently very little incentive to mark multiple DQAs given that the result is the same in all cases (casual), I suspect that just filtering for observations explicitly marked as captive/cultivated will probably exclude the majority of observations with other issues – though there is sometimes a tendency for people to use captive/cultivated as a generic way to “get rid of” any observations they don’t think should be verifiable (hitchhikers, duplicates, etc.). But this is not something that using different filters would fix.
The complaint was specifically about wading through no location/no photo observations to find cultivated plants, rather than non-wild vs. other DQA, however. Along with existing filters in Identify/Explore such as “has photo” (the number of meaningful audio observations of cultivated plants should be close to zero) and a location-based rather than global search, using the URL snippet for finding captive/cultivated should be a fairly simple way to get roughly the set of observations that are of interest. Obviously it isn’t perfect, and I didn’t suggest it was, just a quick workaround to substantially reduce the signal-to-noise ratio.
I’m aware that there is currently no way to distinguish between captive observations that have already been verified and those that have not. Making this possible would be one of the main benefits to this feature request. But this was not the main concern cited above. It is also not a problem that is unique to non-wild observations. For taxa that often can’t be ID’d to species from photos, IDers also have to figure out strategies to manage their workflow when they can’t use Needs ID as a way to prioritize those observations that need attention.
There is little incentive to add agreeing IDs to cultivated plants. Sure, some of them are interesting, some rather rarely seen trees in arboreta and similar, but most are just stock Rosa sp., Tulipa sp., Paeonia sp., where no specific name makes sense (Or what does Tulipa gessneriana actually mean? For roses there is really no way.). There is little reason to add another vote that yes, it is an unidentifiable rose (exceptions are R. rugosa, sometimes R. majalis and R. multiflora, but it may be hard to distinguish their cultivars from their hybrids).
This may be true for roses, but speaking as someone who has had to go through and re-identify hundreds of fabaceae urban trees (honey locust? black locust? kentucky coffee tree? kentucky yellowwood?) having multi-id confirmation would have saved me hours, if not days of work.
How? Aren’t you just providing the multi-ID confirmation in that process? Even if it were required, it’s quite possible that they would just have been sitting in Needs ID rather than Casual, with the same lack of a second ID.
Indeed. Alas, a good half of my wild plant observations from the recent weeks is sitting in Needs ID. Some of them pretty easy ones. There is just not enough IDers for the influx of observations.
I am confused by your confusion! If something is Casual:
- Users have to intentionally seek it out as it will not appear in Identify by default
- There’s no status change regardless of how many confirmed IDs there are
- There’s no shift to “research grade” or any other category which makes a baseline filter for quality and judgement for data usage
Surely you can see how that’s different than “Needs ID”? By default, fewer people will ever see it to identify it.
Edit (Last one i swear): Due to the previous two comments, it seems worth clarifying that I mostly ID plants (nearly at 15k) so I’m not demanding someone else do the work while I lounge around. All I’m asking is for a second pair of eyes every once in a while.
I’m well aware of all those differences. My point was merely that the fact that things are in Needs ID doesn’t mean they get IDs, and it’s quite possible that even if the observations you’ve been reviewing had been in Needs ID, your work would still have been needed (I’ve seen plenty of things left for years, presumably due to insufficient identifers). So when you ask for a confirming pair of eyes, that’s just what you’re providing, whether it’s in Needs ID or Casual.
For the record, I’m not specifically opposing the idea of making cultivated plants not Casual (as long as I can still screen them out), merely trying to point out that it may not solve problems the way people like to think. It seems to me that by default it must either (a) make little or no change in the amount they’re identified because people want to focus on wild plants, or (b) make wild plants take even longer to get identified - unless we can recruit a proportional number of additional identifiers with skills and interest in identifying garden plants.
To the extent that there are people interested in identifying garden plants, I’m guessing they would find the iNat taxonomy frustrating to work with. The labelling system in place for cultivated plant hybrids is both simplistic and messy and clearly made by people who care more about natural and naturalized populations than about the nuances of garden cultivars.
iNaturalist is useless for garden plants in that regard. It doesn’t include cultivars and probably never will, yet cultivars are utterly vital to full garden plant identification. In particular there are genus level cultivars for many plants which have such a complicated ancestry they cannot be assigned to a particular species. With the iNaturalist identification system they’d just be left at genus level.
This thread never reached a resolution but doing what is discussed there would help with many of these highly cultivated genera: https://forum.inaturalist.org/t/suggestion-allow-hybrids-that-specify-a-genus-only/9739
Then the hybrid taxon could be created and cultivars could be added under it. There have been a number of threads discussing these types of issues but they never resolve because curators disagree about whether to prioritize practicality vs. taxonomic integrity and there is no one to arbitrate. Or you could interpret that as a de facto expression of not being a priority from staff.
Thanks for sharing your experience. This matches what I’ve heard from plant (and plant parasite) researchers I know. And it’s nice to hear my efforts in IDing cultivated trees may be utilized despite the hidden nature of the data.
I am wondering if an open letter from researchers would reinvigorate this popular request, since it appears to have been ignored or rejected at this point.
I agree with this. A small traditional project that tracks wildlife use of different cultivars would be really interesting. But I’d recommend tracking the individual cultivar taxonomy via an observation field with a dropdown list (or even tags) and limiting the contributors to the trad project to those who understand the difference in the cultivars.
Since observation fields can be used across iconic_taxa the “cultivar name” observation field could be added to insect observations that also identified “plant that the organism was found on”. And since the fields can be and’d together, you could search on
&iconic_taxa=insecta
&field:plant+that+the+organism+was+found+on=xxxxx
&field:cultivar+name=yyyyyy
* I wish the obs endpoint took an obs_field_iconic_taxa and limited results to only observations with a taxon obs field with a matching obs_field_iconic.