Verifiable=false in url: strange behaviour

The verifiable=false parameter works in urls: returns 4.8 millions observations

If I then try to filter by birds, the resulting url changes to “verifiable=any”: HOWEVER it still returns only unverifiable observations (800 thousand of them)

If I hit the back button in my browser, I go back to the url: but it is now showing me both verifiable and unverifiable observations! (all 35 million)

If I then refresh the page I will go back to seeing only 4.8 million unverifiable observations, despite still having the same URL.

To summarise:

  • verifiable=false will change to verifiable=any in urls whenever I change another filter in the UI, but it will still only show unverifiable observations
  • This mismatch between the url and the observations shown will remain through multiple filter changes
  • As soon as I go back in my browser, the page will now show both verifiable and unverifiable observations, even if going back to the original page with “verifiable=false” in the url.
1 Like

It dont know if this is related, but I will put it here anyway.

Why are subspecies not verifiable?


but if I click off verifiable I get

Not the position of Protea caffra changes from 32 observations with verifiable=true to 10 observations with verifiable=any

If I click on the “10 observations” line in the verifiable=any screen, I get::
which displays 32 observations comprising:

  • 5 observations research grade & 27 needs id
  • 28 observations ID’d as subspecies falcata & 4 as subspecies caffra
  • 17 have more than one image & 15 have only one image
    Simply: I am baffled by what is happening. Where does the 32 (logical) vs 10 (how does iNat get to 10?) come from.

Note that this may change soon, as I am expecting confirmation of the IDs as South Africa wakes up.

it’s not quite the same functionally, but i bet there’s a common underlying technical cause in the thing i noted here:

What are the use cases for verifiable=false?

Well, pretty limited, I think I was using it to find my own observations that had been mistakenly marked as casual by the data quality assessment. More reporting this in case its a wider issue that can cause unpredictable results for other searches. It does seem like something is going quite wrong if the same URL can result in two different sets of results.