Correction/Change to URL for "identifier leaderboard" on taxon page

Feature Requests
1

Hi all,

This overall topic has been suggested before, but I thought I’d make a more focused proposal that highlights the use in a way that hasn’t been proposed yet.

Here is a taxon page. Say I’m a expert, researcher, or interested user. I want to see all the iNaturalist observations of this taxon.

image
image1502×394 105 KB

It says there is 1 total observation. I click “View All”, and get right to it. But then I see up top, under Top Identifier, that the taxon was used IDs 4 times total. Most likely meaning there are 3 additional observations out there in limbo, likely representing this taxon, that I am also interested in looking at. If not just to help confirm the ID and push it along, but to review and make sure it is correct.

Great, so I’ll look at this area here…

image
image358×148 15 KB

And click on this. As the site is set up, you’d assume this leaderboard button would take you to a page where you can see all 4 observations where the ID occurred. But you cannot. If you click this button, instead it filters only to observations where the community ID reached that level. In this case, clicking 4 then takes you to a results page that again only shows 1:

image
image1482×519 29.9 KB

This seems like an oversight to me. Leaderboards are a function of iNaturalist and generally work correctly, but not in this case. I’ve had many ask why it doesn’t work the way it shows. The site knows there are 4 observations, but hides them behind a curtain, and you can’t actually reach them. And yes, I’m aware there’s a “secret” URL code for this kind of search called “ident_taxon_id=”. But 99% of identifiers are not aware of this, and cannot utilize it. This should be a basic function of this page.

My proposal is that the leaderboard link should be modified to include ident_taxon_id=, so that it actually matches the number shown on the page, and also gives a means of searching for observations that aren’t at community agreement, but worth looking at for interested parties.

2

The downside of this proposal is that it will include in that search everything which at least one identifier IDed as that, even if that identification is maverick. This search for example:

https://www.inaturalist.org/observations?ident_taxon_id=10411&quality_grade=research&verifiable=any&view=species

returns 31 species at research grade that at least one person has identified as a red crossbill.

You are certainly correct that most identifiers won’t know about ident_taxon_id= but most also will have to notice that the link they clicked on the species page is showing them pictures of other species, and some won’t.

3

I thought the 3 missing ones were - not verified - could be retrieved by including Casual ?

4

Regarding the 4 IDs, we think there’s a bug in our IDs index and we’ve made an issue for it.

4 Likes
5

So do you envision a better solution? Maybe one that utilizes this search code, but some other criteria as well?

I don’t see a problem with maverick IDs. These may have been made by experts providing a correction, but did not have any further progress or confirmation. But at the end of the day, the supposed leaderboard is a very basic count of IDs, even if they are wrong.

The argument is that for someone interested in that taxon, it is still worth their time to see those maverick cases to ensure the decisions were correctly made.

5 Likes
6

that’s not the right “secret” URL. in fact, no link to an observation page will get you the right answer. instead, you need to get identifications to find the information you’re looking for. currently, there are 2 identifications that can be found in the system (oddly though, the pie chart on the page suggests that it can still find 4 identifications): https://www.inaturalist.org/identifications?taxon_id=481082&user_id=wongun

the reason the site is reporting 4 (not 2) appears to be that two identifications had been made but then were subsequently deleted but have not been eliminated from the identifications index. you can still see where they would have been here: https://jumear.github.io/stirfry/iNatAPIv1_identifications?taxon_id=481082&user_id=wongun

i assume the index problem is what tiwane was referencing in terms of a bug?

5 Likes
7

I think ultimately taxon experts and curators need to learn to use the search URLs, because no matter where staff decide links should go, there will always be cases where someone wants the links to go somewhere else. Hopefully the new explore page will make this easier, but I assume some URL editing will still be required.

1 Like
8

I think we should aim for a more user friendly system than URL editing, which imo is fairly complicated and at least personally tough to learn/remember as someone without coding experience. By restricting the system to URL stuff (which AFAIK there’s no obvious iNat made and readily available tutorial for) and which most users are likely unaware of, the system remains unnecessarily complicated. Apologies if this reply is overly wordy.

3 Likes
9

I agree that it would be optimal to have a search system that requires no URL editing. I just don’t expect it to happen.

2 Likes
10

see https://www.inaturalist.org/pages/search+urls

1 Like
11

The problem with these pages is that there is no way to find them unless one happens to have a link – there is no place from iNat’s interface from which one can access them.

2 Likes
12

I’m a software developer. I agree that asking people to manually edit the url to access some features is a bad idea. I can’t think of another website that I frequently visit where the users are asked to edit the URL to access some website features.

User experience (UX) is a subfield in software development that focuses on creating software that is easy to use, intuitive, and accessible. There should be someone on the iNat team who is advocating against editing URL and advocating for updating the website to make all these features available through the website UI using normal searching and clicking on links. Only some iNaturalist user visit the forum. That means all the users who don’t visit the forum are unaware of URL editing. There are some users who rely on screen readers and other accessible devices to visit websites. Asking users who face accessibility issues such as blindness and limited mobility to manually edit the url is a bad idea.

I created a website that adds features that are present in the iNat API but are missing from the iNat Explore page. One of the features I added is an Identifications section to search through identifications. To search for identifications by wongun for Leutiola

  • Click on “Identifications” on the top menu.
  • select “Identifiers” in the “Search for” menu.
  • type in “wongun” and select the corresponding user
  • select “Identified Species” in the “Search for” menu.
  • type “Leutiola” and select the corresponding taxa
  • click “Grid” to see one identification per observation. click “History” to see all identifications per observation.

Screenshot 2026-02-20 at 9.13.03 AM
Screenshot 2026-02-20 at 9.13.03 AM1920×1027 172 KB

https://inat-explorer.dataexplorers.info/identifications/?taxon_id=481082&user_id=476404&per_page=24&view=identifications_identifications&subview=history

Here’s the iNat identification api results for user wongun for taxa Leutiola. There are four results.

https://api.inaturalist.org/v1/identifications/?taxon_id=481082&user_id=476404

However, when you try to go to iNaturalist identification page for identification id 764279103 and 764278765, we get an doesn’t exist error. identification 764281949 and 242730905 are fine.

6 Likes
13

https://forum.inaturalist.org/t/how-to-use-inaturalists-search-urls-wiki-part-1-of-2/63/474

14

It’s going to be added to help.inaturalist.org too.

2 Likes
15

I’m aware. But that doesn’t change my point that information that is – at present – only accessible through unlinked, hidden pages does not meet the criterion of “readily available” or “user-friendly”. Providing links in a forum thread on a different topic doesn’t change that, as it hardly increases the visibility of the pages for the average iNat user.

So not only is the expectation that users engage in URL editing less than optimal, there is a second issue connected with it – namely, that the information about how to do so is so hidden that many people are unlikely to be aware of it in the first place. Maybe these are features that are unlikely to be relevant to the majority of users and it would unnecessarily complicate the Explore and Identify pages to include them there. But the proportion of users who would likely find it valuable and who would use these URLs more often if it weren’t so annoying to look them up every single time they need them is not so small that it makes sense for them to be as hidden as they are.

Help pages are also not where I would expect to find a tutorial on advanced filtering options using URL manipulation.

2 Likes
16

I would prefer options to be available as filters in identify. If there is a named filter, it is reasonable to have a mouseover prompt - and then a clickable link if it is more complicated.

Random example is the new Disagreements filter, which I find very useful. Sometimes a project can achieve one click to an elaborate URL. Most of my bookmarked iNat URLs are from kind people answering questions in the forum. That is definitely not my skillset - building elaborate URLs. Once you have a complicated URL, you can tweak it to fit your purposes.

To the original question - it still displays as one obs. But now with only 2 IDs, so only one is still hidden. For some reason. And not verifiable does not display the missing one.

1 Like
Website to explore iNaturalist data - feedback wanted
17

Good discussion all.

I think the core desire is to have a way to find “observations identified as this taxon, but not at community ID” because of how many times only one expert will ID on an obscure taxon. That causes valuable data to be stalled or lost in the void for a long time, if not indefinitely, if no one else with knowledge pitches in.

There are assuredly other ways to facilitate this goal. But that it’s being talked about here is a good start.

18

One useful way to find disagreements is using the ‘Similar species’ tab - but it only works if things are identified at the same (or very similar?) level. Maybe an easier way to access this currently URL-only functionality would be to have a link to all disagreements involving this taxon on that tab?

19

Yes. 1000% agreed.

2 Likes