How to use iNaturalist's Search URLs - wiki

Welcome to the forum!
I don’t think there’s an easy way to do that, but there are a few somewhat complicated ways you could try.
This search will show observations in Big Cypress National Preserve that are unique: https://jumear.github.io/stirfry/iNatAPIv1_observations_species_counts.html?order=asc&place_id=95106&rank=species (just scroll down until taxon obs count changes to 2)

So there are currently 450 species only observed once, but you’ll have to do more to filter it by user. You can copy/paste the text off that page, process the json from the API yourself, or maybe if we ask nicely, @pisum will add an export tool.
Once you have the list of 450 unique species, I would import that back into iNat as a list, and then use the list_id as a search parameter. Since each species is unique, every observation returned shows the only user to have seen that species at that location. If you add yourself as a search parameter, it should return only species in Big Cypress that you (and no one else) have seen.

It’s not ideal if you want to be able to do it repeatedly, but I think it should get the job done.

Edit: I realized that it won’t find species that no one else has observed, but that you have observed more than once. I’ll have to think about that…

2 Likes

i don’t totally understand what you’re looking for, but maybe the experimental compare tool might get you something like what you’re looking for?

page: https://www.inaturalist.org/observations/compare
example usage: https://www.inaturalist.org/observations/compare?s=eyJxdWVyaWVzIjpbeyJuYW1lIjoiUXVlcnkgMSIsInBhcmFtcyI6Im5vdF91c2VyX2lkPTEzMjEwODUmcGxhY2VfaWQ9OTUxMDYmaWNvbmljX3RheGE9UGxhbnRhZSJ9LHsibmFtZSI6IlF1ZXJ5IDIiLCJwYXJhbXMiOiJwbGFjZV9pZD05NTEwNiZpY29uaWNfdGF4YT1QbGFudGFlIn1dLCJ0YWIiOiJzcGVjaWVzIiwidGF4b25GaWx0ZXIiOiJub3RfaW5fY29tbW9uIiwidGF4b25GcmVxdWVuY2llc1NvcnRJbmRleCI6MCwidGF4b25GcmVxdWVuY2llc1NvcnRPcmRlciI6ImFzYyIsIm1hcExheW91dCI6ImNvbWJpbmVkIiwiaGlzdG9yeUxheW91dCI6ImNvbWJpbmVkIiwiaGlzdG9yeUludGVydmFsIjoid2VlayJ9

UPDATE: i read the request again with rested eyes / brain, and i think i understand what you’re asking for now. i think you’re saying that you want to pull back observations where the taxon has been observed only by that user.

for me, the easiest thing (without creating some sort of specific tool to do this) to do would be to just export the dataset, load that into something that allows you to run a SQL query on it, and then run some variant of the following SQL statement:

SELECT B.*
FROM (
   SELECT taxon_id, COUNT(taxon_id), MIN(user_id), MAX(user_id)
   FROM observations
   GROUP BY taxon_id
   HAVING MAX(user_id) = MIN(user_id)
   ) A
INNER JOIN observations B
   ON A.taxon_id = B.taxon_id

i wrote the SQL statement above in data.world. so it should work there (i think), and it should work in Microsoft Access (as long as you put brackets around the table name for some reason). i vaguely recall that Excel should also handle SQL through Microsoft Query or Power Query, but i’m not patient enough to figure that out today. i tried fancier SQL statements with WITH clauses and WHERE…IN and other syntaxes, but the statement above is the only one that i could get to pull what seemed like reasonable results. so either the tools i tried don’t handle that fancier syntax correctly, or my SQL is really rusty.

2 Likes

As far as I can tell, the link you provided to the compare tool does exactly what I was trying to do!

Thank you!

Sorry if this exists somewhere - I looked and didn’t see a match. I want to QC my IDs of others’ observations - I seem to have a lot recently where I make an ID that turns out to be incorrect. I’d just look through my IDs, but I have over 10K, and of course every day potentially brings a new set of opportunities…

So, the characteristics would be:

All of these

  • I made the ID, but was not the observer
  • My ID is not maverick
  • Any quality level (RG, NI, C)
  • Exclude observations where I have already withdrawn my ID

Any of these

  • My ID was followed by other IDs that are different on the same or higher taxon level (e.g., my ID was genus level, but it is followed by a different genus or higher, e,g., I entered Corvus (crows) but it is followed by Cuculidae (cuckoos))
  • My ID is species level but is followed by others that are genus level or higher (i.e., mine were more granular than warranted but otherwise correct, e.g., I said Quercus rubra (red oak) but is followed by Quercus, or I said Quercus but it is followed by Fagaceae)
  • My ID is preventing the overall ID from progressing to RG (I know this may not be possible to code)

Thanks so much for any/all help.

2 Likes

I think &current=false with either &category=leading or &category=improving could work

2 Likes

I’m looking at https://www.inaturalist.org/identifications?user_id= and I am wondering if it is possible to see only observations that have a value in the last column “disagreement with.” This isn’t one of the listed params so it might not exist, but I would find it useful.

I think that’s what current=false would help with, sort of.

My understanding is that value is for when your active ID doesn’t match the community ID (the problem is it doesn’t distinguish between whether the mismatch is due to disagreement or refinement).

Oh is that what that means? I thought it meant I withdrew the ID, ha. Well I forgot about the scheduled maintenance, so I guess I will have to check on this tomorrow.

1 Like

That page won’t filter by disgreement status, but the API does take that parameter. So you can see your disagreeing IDs using the tool @pisum made: https://jumear.github.io/stirfry/iNatAPIv1_identifications.html?user_id=arboretum_amy&disagreement=true

The column labeled “ID = disagree” lets you know your ID was a disagreement, and the column labeled “Prev Obs Taxon Name” tells you what you were disagreeing with.

There are two ways to have your ID register as a disagreement. First, if you give an ID that is incompatible with the Observation Taxon, your ID will automatically disagree with it. Second, if you give an ID that is coarser than the Observation Taxon, you can choose to disagree or not (via the much-maligned popup with orange and green buttons).

This is one of the first kind:

And this is one of the second kind:

In both cases, you can tell it’s a disagreement because of the text at the bottom of the ID, and because it shows up in the algorithm summary.

Whether an ID is a disagreeing ID or not is independent of whether it is active. So here’s an ID that isn’t active, but is a disagreeing ID:

When your ID is a refinement of the Observation Taxon (e.g. you add species to a genus level observation), it doesn’t count as a disagreement. So this is not a disagreement:

5 Likes

Wow, thank you!

Actually in this case it returns all the IDs I have withdrawn (either by refining or just plain withdrawing.)

1 Like

Oops, you’re right. I could have sworn in the past it showed me coarse IDs I hadn’t withdrawn, but that don’t match community because the ID has been refined by others.

1 Like

I think I figured that one out though, it is current_taxon=false. So very similar.

2 Likes

Is there a URL feature that limits the search results to only observations I’ve favorited?

You want to use Explore/Identify to go through observations that you’ve favorited? Can I ask if there’s a particular reason you don’t just want to use the page for your favorites?

I use the Fav button to quickly save tough observations to ID later when I have more knowledge of a given group etc. But when later arrives, there’s no convenient way to sort that pile, that I know of, but it seems like there easily could be.

It notifies the observer when you favorite their observation; would it be better to just leave it “unreviewed” or bookmark it or add it to (insert your to-do app of choice here)?

Funny how favoriting an observation notifies the user, but following their account does not.

Makes sense, subscribing to other content like journal posts or flags doesn’t add any notifications for the content author.

https://github.com/inaturalist/iNaturalistAPI/issues/17
describes the same issue as it existed in the API.

1 Like