Ideas for a revamped Explore/Observations Search Page

oh, true. i guess then adding counts for exact taxon only would be the straightforward thing. but looking at it in more detail, probably another reason i didn’t add links is that the Explore page doesn’t support the exact_taxon_id parameter.

linking to the Identify screen is less ideal, but is a link to Identify better than nothing?

UPDATE: i ended up adding exact taxon links to my own APIv1_observations page, since that’s something that folks have access to even without an iNaturalist account (unlike the Identify page).

2 Likes

Note that hrank and lrank (and rank) are observation search parameters (not species-tab sorting parameters)—they restrict your search results to observations with an observation taxon at or above/below those ranks, and then what’s displayed on the species tab are the leaf taxa among those resulting observations (with infraspecies rounded up to species as usual). For a higher taxon to show up on the species tab using lrank, there have to actually be observations with an observation taxon at that rank or above (and the number of observations listed for each taxon on the species tab will be the the number of observations in your rank-restricted search results [i.e., the number of observations of that family/genus/etc. that are only identified to family/genus/etc.], rather than the total number of observations of that taxon and all its descendants regardless of rank); and because the species tab only shows taxa at species rank or above, restricting your search to observations identified to infraspecies using hrank won’t make infraspecific taxa show up on the species tab.

(For a couple examples: if your initial search [without any rank parameter] resulted in 200 observations of a number of different taxa, but all of those observations were identified to genus or species, going to the species tab and adding lrank=family to the url wouldn’t bin all the listed leaf taxa into their respective families to give you a list of all families represented among those observations—it’d give you nothing. And if you had, say, five genera represented among your original search results, but all observations of three of those genera were identified to species level or below within their respective genus, going to the species tab and adding lrank=genus to the url would only show you the two genera with at least one genus-level observation [and the observation count for each of those genera would be the number of observations with an observation taxon at genus level, not the number of observations of that genus and all its descendants if you hadn’t used the lrank parameter])

2 Likes

Looks good to me – you could maybe add a link to Identify at the top of your observations page? That seems like it might just generally be useful (even if Identify doesn’t support every single API param).
Actually, now that I think about it, I fairly frequently want to switch between stirfry, Identify, and Explore, and would probably use all the links if available (again, with the understanding that some of the params might get dropped)

Clarification: I do not intend to give you work, my suggestions were initially for iNat, but since you mention the possibility, I continue the discussion.

For reviewing observations, I think it’s better not to link the same observation from several links (for instance a link for the Order and a link for the Family). I suggest another count at non-leaf taxa, a count not including subtaxa, with a link (taxon_id + lrank) not including subtaxa that would be fine for reviewing observations.

i don’t understand how what you’re describing here is different from what’s already been implemented earlier today.

Sorry, I didn’t know you implemented it.

done.

2 Likes

This is pretty useful. It would be nice if it didn’t show the full tree though if you are trying to get an exact taxon count. Maybe an option could be added to show the full tree or to show only nodes that have “Exact Taxon Obs Count” >= 1. That would make it very similar to what the iNat Explore page should actually show.

Here’s an example with more taxa that should maybe only show 100 nodes if you wanted a real taxon count of what the observations are IDed to but shows 358. There is also just a lot of clutter in the view if you don’t want to see all the empty nodes. Below you can see that that only actually shows 5 observations but has 23 nodes.

In that same search, I can easily see what is and isn’t IDed to subspecies, which is great.

I’m working on a website to that adds features to iNaturalist Explore page. One feature I added is to display the subspecies with observations counts.

Here’s a search for Eriogonum umbellatum , variety rank

https://inat-explorer.dataexplorers.info/?taxon_id=77040&verifiable=true&spam=false&rank=variety&per_page=24&page=1&view=observations_species

  • Search for “Observed Species”
  • type Eriogonum umbellatum or sulfur buckwheat
  • click “Filters”
  • click “Species” tab, Rank > Rank > select “variety”

When people select any rank lower than species, the subspecies will be displayed. People can select multiple ranks if needed.

The site has over 50 fields to filter search results. I am trying to make the site look ok on mobile devices, but I haven’t tested the site on multiple devices yet since I only have limited number of devices. Here’s a thread for the website where I show various features.

https://forum.inaturalist.org/t/website-to-explore-inaturalist-data-feedback-wanted/70438/28

4 Likes

Excellent! Nice to have tiles with the taxon page cover photo.
Possible to have a link to the observations (link to iNat) on the text “1 829 observations” in the tile?

the nodes provide context, and i’m hesitant to remove nodes to reduce clutter for just one use case, if the tradeoff is loss of context. to me, it seems like it should be relatively straightforward parse the results yourself to get rid of things you don’t want to see, if you want to do that.

This is cool! Is there a way to see all taxa together at their identification level or just species, subspecies, and varieties together? Or separate side-by-side tabs for each? Here is an example search. If I choose all, I get 91 “species” which I think includes species and higher ranks just like the iNat explore page for the same query.

If I set it to subspecies, I see just those five IDed to subspecies, which are not shown in the previous species tab.

If I set it to variety, I see just those two IDed to variety, which are not shown in the previous species or subspecies tabs.

If I set it for everything below species, I can see subspecies, varieties, and hybrids all together.

If I try adding species to that, the observations go up to include them but it still shows just those below the species rank in the subspecies tab.

I would like to see a summary of all taxa with their IDed rank in a combined species/subspecies tab or side-by-side tabs for species and higher (current species tab) and everything below species (current subspecies tab). The ideal situation is that one taxa tab would show all by default but you could choose to see family to species or species to variety or genus to subspecies or whatever ranks you are interested.

Having a minimum-ranked-taxa tab would be awesome as well, which if you had and observation IDed to just genus, one to a species in that genus, and one to a subspecies of that species, it would only show the subspecies. This would give you the standard taxon count most people who ID beyond species are looking for when they want to know how many taxa are known from an area.

What is the url for the search shown in your screenshot?

https://www.inaturalist.org/observations?project_id=274258&verifiable=any&view=species

I adjusted the site to display species and those below species if people use the filters to select higher ranks and ranks below species. Search for Nemophila menziesii at Lake San Antonio Recreation Area. My site shows two observations and 2 species (Nemophila menziesii and Nemophila menziesii menziesii). iNaturalist site shows two observation and one species (Nemophila menziesii). It sounds like you want to see subspecies without setting the rank filter.

There is a difference between having bug in the current features and people wanting new features. I would classify the way iNaturalist species page treats ranks below species as a bug. Using the example you provide, I wanted to see all subspecies by setting rank=subspecies. There are 4 subspecies displayed on my site. However when I do the same query on the iNaturalist site, it shows four species. The four species shown are the correct species for the subspecies, so the iNaturalist site and API does recognize rank=subspecies. But instead of returning the subspecies, the api returns the species, which causes the site to display the species. The iNaturalist observation view shows four the subspecies. It feels like a bug that the observations view and species view treat ranks below species differently.

Great! Out of curiosity, I just tried this to see what vascular plant taxa I have not observed in a local park. With just species, I get 104 to go look for.

If I let it show me all taxon ranks including and below species, I now have 152 “species” to go looking for. That’s a bunch more cool taxa that I would possibly not have on my radar if I just used the iNat Explore page. To me, that well illustrates the issue of the iNat Explore page not showing a summary of taxa below the species rank. The iNat Explore page basically implies that those taxa don’t matter and it is an impediment for those people that want to learn more and see more taxa they have never seen.

Going back to Eriogonum umbellatum, we can now easily see how many are identified only to species and as well as how many are IDed to each of the lower ranks all on one page. This really makes it easier to get quick summaries beyond just the species rank. In this case, it well illustrates the huge amount of ID work needed in this species that will likely be split into several species in the future.

If you submit a bug report about the API returning species if the rank is below species and why lower ranks are important for identifiers, maybe the iNat devs will update the API so people see lower ranks by manually changing the url on the iNaturalist Explore page.

I had to use the /observations/taxonomy and /taxa API in order to show lower ranks because /observations returned species for rank=hybrid,infrahybrid,subspecies,variety,form

The v1 docs only say that /observations/species_counts should return leaf taxa, and the help page that defines leaves says that infraspecies are intentionally rolled up to species when determining leaf taxa. There is nothing to indicate that the devs consider this a bug rather than a design decision.

I use /v2/observations/species_counts because the iNaturalist site uses v2 api on the species view. v2 api docs do not mention leaf taxa. The docs do state:

Available values : kingdom, phylum, subphylum, superclass, class, subclass, infraclass, subterclass, superorder, order, suborder, infraorder, parvorder, zoosection, zoosubsection, superfamily, epifamily, family, subfamily, supertribe, tribe, subtribe, genus, genushybrid, subgenus, section, subsection, complex, species, hybrid, subspecies, variety, form, infrahybrid

As a software developer, when api docs list all available values, I expect all the values to behave the same way. Since all the ranks species and above return taxa for that rank, I expect all the ranks below species to also return taxa for the rank.

keirmorse is a professional field botanist. When keirmorse pointed out issues with the way I implemented ranks below species, I updated the code. The changes improved the way he can examine iNat data. He gave specific examples that shows the negative impact of the way iNat Explore page handles ranks below species.

When the code gets in the way of exploration, identification, and research, the code needs to change.

1 Like

The available values apply not to the returned leaf taxa, but to the observations that get lumped into leaf taxa. For example, you can ask for only observations with photos, and then the system will categorize the observations that have photos, but it 's not returning taxa that have photos.

If you don’t like the way it works, that’s fine, but the devs have made it pretty clear they do not currently consider it a bug, this is intentional behavior.

1 Like