I am helping onboard a researcher who focuses on street tree species. This has forced me to start learning how to access and deal with Casual observations. I’ve stumbled into an issue/difference I don’t fully understand and searching around has not given me a clear answer.
In Identify, you can clearly select Casual as an option in the UI and utilize “&quality_grade=casual” or “&quality_grade=needs_id,research,casual” in URLs. This does not seem to work when using Explore, which instead offers “&verifiable=any” or “&verifiable=false”.
Is there a meaningful difference between a Casual observation and a “&verifiable=false” observation? What is the purpose of this distinction?
It’s quite confusing, especially given the location, time, photo, seasonality, etc can certainly be verified and revisited for a cultivated plant. In contrast, the logic that cultivated plants are Casual as a current iNaturalist category is clear. I totally understand the Verifiable hover text “Eligible for Research Grade” as a category describer, but that’s not inherently synonymous with being verifiable, as the word is commonly used. One of these trees that has been growing in the same spot for over 100 years is definitely verifiable, in the usual sense. Thus my confusion!
Thank you for your help clarifying. I want to get this new researcher hooked and want to be sure I’m passing on good info. Casual observations have value too!
because the Explore page defaults to verifiable=true under the hood, you need to explicitly set verifiable=any (or verifiable=false) if you want to be able to specify casual observations.
As you might know, multiple reasons for an observation being casual, including being captive
If you want to see casual observations that have all other DQA correct except captive then you might want to use the filters: &mappable=true&photos=true
unfortunately there is currently no way to exclude observations that are missing a date @pisum correct me if I am wrong
EDIT: sorry. i just tested fails_dqa_date, and it’s actually filtering for “date accurate”, not “has date”.
…
i think the definition of verifiable in here is inaccurate. it says:
A verifiable observation is an observation that:
has a date
is georeferenced (i.e. has lat/lon coordinates)
has photos or sounds
isn’t of a captive or cultivated organism
but look at what this returns: https://www.inaturalist.org/observations?captive=false&verifiable=false&id=19386749. that observation has a date, is georeferenced, has a photo, and is not captive or cultivated. according to that definition above, it should be verifiable, and yet gets picked up as verifiable=false. as far as i can tell, the converse of the definition of casual is the actual definition of verifiable.
while there doesn’t seem to be a date presence/absence-related parameter specifically to filter out observations missing dates, you should still be able to exclude them through other means, namely setting the start date in the date observed range (d1) to something like, say, 0001-01-01. observations without a date won’t fall within any range of dates, so should be excluded from any date-based search results accordingly. (if you also want to exclude observations with messed-up dates extending back a couple thousand years, you can set it to a more realistic start date. i’m not sure there’s currently any way to do the reverse, searching specifically for observations lacking dates, though)
it doesn’t matter. the criterion is simply that there is a date, accurate or not. it has a date, and so by that definition it should be verifiable.
but just to prove the point, i took away downvote on date is accurate, and i downvoted recent evidence instead. you get the same result. anything that makes the observation casual also makes the observation verifiable=false.
This page was a collaboration of many members of the iNaturalist community. Want to add or edit something? Any iNaturalist Curator can edit this page - the link to edit is on the bottom right. Otherwise, reach out to @bouteloua and she’d be happy to work with you on making changes or additions.
I know your question was directed to another user but I love doing searches. This assumes that captive should be casual - I think the following satisfies part of the query you asked : https://www.inaturalist.org/observations?captive=true&subview=map&verifiable=true
Oddly: some of them are research grade; some although they appear captive, I can’t see that being acknowledged in the DQA or elsewhere; and none of them are marked casual. Am I missing something?
ah sorry i see your point now. the actual verifiable filter is getting affected just as casual filter in similar way from all DQA flags.
but according to help article explanation there it shouldn’t have - so not sure if its bug or how it should be and then article is wrong.
If its a bug, solving it can help inturn in this feature request i guess? - https://forum.inaturalist.org/t/make-captive-cultivated-not-automatically-no-id-needed/112
where they can use verifiable filter for IDing those, if fix can also push that non-wild condition too out of verifiable in addition to DQA conditions as is now. the casual flag can still apply for all these.
it’s likely just bad indexing. if you vote and then unvote any of the DQA flags on any of these, these should drop out of captive.
even if the intent was to do what the article was describing, because it’s such a core part of the system, i think it would be better to adjust the article to reflect what the system is actually doing right now (and has been doing for years).