Observations/Identifiers count discrepancies

for example:

This shows chauncey with 1011 identifications of J. grandis.

Go to taxon information page:

This shows chauncey with 542 observations and 654 identifications.

I’m perplexed. What am I missing?

Thanks for your help.

Platform PC, website

Browser, Chrome

the number identifications that shows up in the Observation detail page includes seems to represent identifications you made on any research-grade observation, including your own observations (see https://jumear.github.io/stirfry/iNatAPIv1_identifications_identifiers.html?&taxon_id=77599&per_page=50&quality_grade=research); whereas the number of identifications that shows up on the Taxon page includes only identifications you made for others’ observations of any grade (see https://jumear.github.io/stirfry/iNatAPIv1_identifications_identifiers.html?&taxon_id=77599&per_page=50&own_observation=false).

i’m not sure why the two pages are counting different things, but i’m not sure it’s necessarily a bug either.

Thanks for looking into this. I’m not totally sure what to make of it, but sounds like things are working as they should.

Hi @jdmore,
the table below tries to compare different ways to count identifiers relative to the URL and sentence that I just quoted from your tutorial.

URL Total IDs User IDs Matching Community IDs User IDs on Own Obs IDs for Others Notes
#1 www.inaturalist.org/observations?ident_user_id=tiwane 77858 Yes+No included included From tutorial above
#2 jumear.github.io/stirfry/iNatAPIv1_identifications_identifiers.html?user_id=tiwane 81037 Yes only 27515 53522 cf Forum topic referenced below
#3 www.inaturalist.org/observations?user_id=tiwane Yes only 26675 By analogy
#4 www.inaturalist.org/people/tiwane Yes+No ? 27783 53522 Profile page
#5 www.inaturalist.org/identifications/tiwane ? 56158 Clicking IDs on Profile
#6 www.inaturalist.org/observations?place=any&user_id=tiwane&verifiable=any Yes+No ? 27783 Clicking OBSs on Profile

I would have the following questions.

Why does URL #1 give a total number of IDs that is smaller than URL #2 (77858 vs 81037) ? Yes+No should be equal or greater to Yes.

I understand that URLs giving 27783 for this account’s own observations (#4 and #6) have an option (verifiable=any) explaining why the number are greater than 26675 (URL 3) . But why is the latter smaller than 27515 (URL #2) ?

Why are IDs for others different between URL #4 (profile page) and #5 (that is 53522 vs 56158), even though the latter is obtained by clicking a link from the former ? Note that the proile page (URL #4) gives the same value as URL #2 for this parameter.

I know that some of these issues have been discussed in other threads (including the one from which I took URL #2), but why most of these differences exist… at all is not clear and explanations could be helpful here.

Thank you

Reference for URL 2:

Hi @odole your post and analysis seemed relevant to this recent bug report, so I hope it’s ok that I moved it here.

Thank you for your detailed analysis of the count differences. Not sure I have any definitive answers, and the developers might have to answer for sure. But a couple of factors that might be at play here are:

  • are only active IDs being counted, or active + inactive?
  • are they being counted on observations of all quality grades, or are Casual observations being excluded?

Maybe someone else will be able to chime in with better answers.

URL 1 is using the default hidden param verifiable=true, while 2 also includes IDs on observations that are not verifiable.

26675 is smaller than 27515 because 26675 is the number of verifiable observations by tiwane, while 27515 is the number of IDs tiwane made on all of his observations. They’re not asking for the same data – the first is asking for number of observations and only includes verifiable, and the second is asking for number of IDs and includes all observations. He could (and does) have some observations that aren’t verifiable, and he could (and does) have some observations that he never added an ID to, e.g. this one. So we wouldn’t expect these numbers to be the same, either one could be larger.

The profile page includes current=true, while the identifications page shows current=any. This was a design choice that probably only the developers could comment on.

1 Like

@jdmore Thank you. This topic seems perfect.

@jwidness Thank you for your explanations, highly appreciated.

To make sure that I understood, I tried to enter your explanations in the table, expanded as follows (I hope I got them right) :

URL Total IDs Matching Community default verifiable= default current= ID on Own Obs IDs for Others Notes
1 www.inaturalist.org/observations?ident_user_id=tiwane 77858 Yes+No true ?? included included From tutorial above
2 jumear.github.io/stirfry/iNatAPIv1_identifications_identifiers.html?user_id=tiwane 81037 Yes+No any ?? 27515 53522 cf Forum topic 7337
3 www.inaturalist.org/observations?user_id=tiwane Yes +No true true 26675 by analogy
4 www.inaturalist.org/people/tiwane Yes +No any true 27783 53522 Profile page
5 www.inaturalist.org/identifications/tiwane Yes +No any ? any 56158 Clicking IDs on Profile
6 www.inaturalist.org/observations?place=any&user_id=tiwane&verifiable=any Yes +No any true 27783 Clicking OBSs on Profile

Please note that I did not update the ID numbers, notably because the different panels seem to change asynchronously.

I have seen that it is easy to convert the result from URL#1 into that of URL#2 by just adding ‘&verifiable=any’ to URL #1. The reverse does not work : adding &verifiable=true to URL#2 does not change anything, but the format of URL #2 is very different.

In addition, it was my understanding that URL #2 restricted the counting to only the IDs that matched Community IDs (“Yes only” in my previous table), but because the result is equivalent to URL#1 + &verifiable=any, then IDs that do not match Community IDs are obviously included.

This issue was previously discussed notably in topic https://forum.inaturalist.org/t/urls-using-both-ident-user-id-and-ident-taxon-id/14510 for the same question ; it ended with proposal of using the same kind of URL.

Hi @pisum , please help again on this issue ! why is it that the URL #2 jumear.github.io/stirfry/iNatAPIv1_identifications.html seems to act just like ‘ident_user_id’ in the observations page ?

Otherwise, @jwidness to me there are 3 remaining questions (see “?” one each for URL #1,2 and 5), the most difficuly perhaps concerning URL #2 again. Indeed I was able to convert 26675 into 27783 the way you said, but I still do not understand why URL #2 shows 27515.

I think some of the confusion is because iNat treats searches for IDs very differently from searches for observations. You can see the API docs for IDs here and for observations here.

Correct, URL 2 is an ID search and doesn’t accept the verifiable parameter.

For URL 1, current isn’t a parameter for observation searches.
For URL 2, the API docs (or some experimenting) show that the default is current=true.
URL 5 is also an ID search, it doesn’t take the verifiable parameter.

I’m not sure what you expect it to show? It’s the number of current IDs that tiwane has made on any of his observations.

1 Like

the Explore (aka Observation Search) screen by default will look for non-spam, verifiable records. however, the Observation API endpoints don’t apply those parameters by default.

so https://www.inaturalist.org/observations?ident_user_id=tiwane would be equivalent to

and https://www.inaturalist.org/observations?ident_user_id=tiwane&verifiable=any would be equivalent to

the Explore page and Observation API endpoints return observations. there are other API endpoints that return identifications. observations and identifications are different things. so the user_id parameter on observation endpoints will refer to observers, while the user_id parameter on identification endpoints will refer to identifiers. the ident_user_id parameter is available to the observations endpoints as a way to reference identifiers (users who have current identifications on those observations).

so https://jumear.github.io/stirfry/iNatAPIv1_observations.html?ident_user_id=tiwane should be (more or less) equivalent to

not sure if this answers the question you were asking, but hopefully it puts things in context.