Captive Observations not in ID tool: - please add them by default

If one goes from an filter:
say:
https://www.inaturalist.org/observations?place_id=any&project_id=city-nature-challenge-2019-cape-town&verifiable=any&iconic_taxa=unknown
(i.e. project with any verifiable, no IDs) = = 1091 observations
and on that filter box selects “Identify” (bottom bar right)
then one gets:
https://www.inaturalist.org/observations/identify?verifiable=&page=1&spam=false&place_id=any&user_id=&project_id=city-nature-challenge-2019-cape-town&swlng=&swlat=&nelng=&nelat=&lat=&lng=&iconic_taxa[]=unknown
which at present has 122 observations

Why does the identity tool not show all 1091 observations?

converting the ID tool back to observations (remove “/identify” from the url) gives:
https://www.inaturalist.org/observations?verifiable=any&page=1&spam=false&place_id=any&project_id=city-nature-challenge-2019-cape-town&iconic_taxa=unknown&user_id=
(there is a bug - I dont remember it yesterday - it becomes:
iconic_taxa%5B%5D=unknown
instead of
iconic_taxa=unknown
but it is easy enough to “fix”)
which has = = 1091 observations - which is not helpful in detecting the dependency.

However, starting with the ID tool.
https://www.inaturalist.org/observations/identify?quality_grade=needs_id%2Ccasual%2Cresearch&iconic_taxa=unknown&captive=false&project_id=32829&place_id=any
(select project and tick all grades and iconic = no IDs) = = 257 observations
except that the url now includes captive=false.
I also did not tick threatened, but threatened is not set to false, nor was photos and sounds set to false. So why is captive not also “any” like the other checkboxes on the tool?
ticking captive = true gives 828 observations
If I untick captive, then captive = any (by omission), but if I tick either research grade or needs ID then the url is set to captive=false.

The only way to fix this is via the url and adding captive = any:
https://www.inaturalist.org/observations/identify?quality_grade=casual%2Cneeds_id%2Cresearch&iconic_taxa=unknown&project_id=32829&place_id=any&captive=any
== 969 observations.
The discrepancy (1091-969= 122 observations - see above) is because captive=any switches off “needs ID” and “research grade” even if they are coded in the url (see in the filter box to see this effected).

The net effect of this, is that I cannot get my identification teams for the City Nature Challenge to find all unidentified observations using the ID tool. Although we thought that we had finished, it was discovered that nearly 1000 observations that were captive had not been identified because of this strange behaviour.

It turns out that there is a url that does display all unidentified observations
https://www.inaturalist.org/observations/identify?quality_grade=any&iconic_taxa=unknown&project_id=32829&place_id=any
(i.e. quality=grade = any) = 1091 observations
but it cannot be selected from the filter box: the filter box requires that at least one of the three options is selected.

This is a strange behaviour:

  1. Why is captive = “false” the default instead of “any”, like the other options
  2. Why does selecting all three quality grades, preclude the option of captive = any when using the filter box?

All this funny behaviour has its roots in the strange notion that if an organism is captive or planted, then people dont want to know what it is, and so it cannot be “needs ID”, nor indeed can the ID when achieved and supported become a “research grade” ID. Captive and planted observations are consequently removed from the identification cues/streams and data quality assessment. Even though a significant proportion of the biodiversity of our cities is planted (plants are different from animals in this regard, although many animals are commensal and often only exist because of this planted landscape): but this significant element (in some cities 100% of trees are planted, and even 100% of woody shrubs in some neighbourhoods) of our urban biodiversity - which may even support threatened animal species - is not even included in the identification tools for naming our urban species.

Can we please separate identification assessments from data quality assessments: they are different issues. IDs are one factor (with location, date and other issues) in determining data quality, but data quality should not be an issue in determining the status of an ID (although poor quality data - such as bad photographs or incomplete localities - may hamper an ID).

Your request has been addressed here but I that discussion had slipped my mind so I approved this feature request. The short of it is, it’s unlikely that including captive observations in Identify by default will happen unless the overall data quality structure and terminology change, but right now if you check “Captive” on the Identify page, it should show you all non-RG observations that you haven’t reviewed. So anyone interested in IDing observations marked as captive can click that.

This is because “Needs ID” on iNat does not include observations of wild organisms, and the default setting for Identify is to show you “Needs ID” observations that you have not reviewed yet (which I understand is the crux of request).

But just to address this specific case:

This only shows up when I click on Research Grade, but it doesn’t disappear when I turn off Research Grade and/or Needs ID. Which is a bit odd and might be a bug. We’ll take a look.

Would making the “Captive” box setting “sticky” or giving you a toggle on your Account Settings page to include observations marked as captive in Identify be useful for you?

No: I share my urls with hundreds of users, and if my system behaved differently from theirs it would cause endless confusion. Please let us keep it simple.
Besides, I want to look at “Needs ID” to make IDs - I dont want research grade (i.e. 2 or more IDs) observations included among the captive observations.
Also, I want to see unidentified “not wild”, not just “Needs ID”, which also behaves strangely.

So the only real solution is to wait until https://forum.inaturalist.org/t/make-captive-cultivated-not-automatically-no-id-needed/112 is addressed. The ID toolbox can then be fixed to work as one would expect intuitively, instead of springing surprizes on even very experienced users of many years.