I usually check the identify page when on the site and would find it helpful if there was a filter that would remove all obs for a family / genus / species etc to narrow down what I may be able to help ID.
I do know there is the ability to limit the identify obs to a family etc, but that also cuts out the unknowns whereas having a remove filter would allow the unknowns to still be there.
Can you provide a specific example of what youâd like to do?
Senario 1
Person has a good general knowledge of most kingdoms except insects so on the identify page they can remove insects from what shows
Senario 2
Person is good at mollusca but not Sea Hares and Akera Snails. They can set the species as mollusc but remove Order Aplysiida from what shows.
Adding on to this I think this would also be a good feature to add on to the observation search function.
For example, say I want to see all warblers in a specific area that arenât Setophaga coronata
This can actually be done by manipulating the search URL. See the tutorial wiki here:https://forum.inaturalist.org/t/how-to-use-inaturalists-search-urls-wiki/63
For example, this should show all Parulids in California except Setophaga coronata:
https://www.inaturalist.org/observations/identify?taxon_id=71349&place_id=14&without_taxon_id=145245
So itâs there, just not in the user interface.
I second this! This is a good idea, and possibly one that many of us have wished for at some point. :) This needs to be added to all kinds of observation searches, including but not limited to the Identify page.
Just saw this message, @tiwane. :) Itâs great that this already exists (I had no idea it did), but could it be built into the user interface? Iâm glad I discovered this thread, but there are tons of users who wonât⌠and a ton more who wonât manage to manipulate the URLs to pull this off!
So true!
Having this in the user interface would be a big help :)
The flip side of this is that the more complicated the user interface, the more daunting it is for new users. There is also the side effect that learning these features (url edits) via other members by âword of mouthâ does in fact build and strengthen the community.
I edited the topic title to make the request a bit clearer. Feel free to further modify.
or you can just put all the families (or any other taxa ID number) that you like an know well on like this:
https://www.inaturalist.org/observations/identify?verifiable=true&taxon_id=51120,48928,83800,47374,47556,48151,48232,47363,47366,47562,48700,64516,47853,47181,47540,56739,49288,49658,57391,78589,78975
you can also add multiple place ID numbers to that as wellâŚ
I really appreciate that this is possible! +1 to adding it to the UI.
And, is there a way to exclude taxa in subscriptions to a place? For example, Iâm interested in almost all taxa in Western Washington, USA, but want to exclude all birds (sorry, birders!). How could I do this?
The flip side of this is that the more complicated the user interface, the more daunting it is for new users.
It could be put away neatly into a sub-menu (or even a sub-sub-menu within âadvanced searchâ), I presume - it need not clutter up the opening interface. Maybe users could even be required to enable these tools on their UI, kind of like how one has to go a few extra steps to enable the advanced (âdeveloperâ) settings menu on a mobile device.
There is also the side effect that learning these features (url edits) via other members by âword of mouthâ does in fact build and strengthen the community.
Thatâs a good point, but I would prioritise easy, ready access to these tools over the dependence on discussions to know about it. iNat communities are super strong in some places, but have isolated users in other places (I mean with limited discussion activity on the forum as well) - so I think itâs very possible that this wouldnât pop up in iNat discussions everywhere. And itâs a tool that I think would be used very often and very widely if easily available. Not having easy access to it would narrow down the user subset a lot, probably limiting the good use that iNat data can be put to.
I would definitely support an âadvanced searchâ in the GUI
By âadvanced searchâ I meant the nice set of search filters already existing in the GUI; new features will only need to be added to it (under an optional sub-menu, taking @kiwifergusâ point into account).
when you are talking about the use that iNat data can be put to, you are typically refering to a different subset of users than those that need easy access to tricksy search queries. Also, I am one of those isolated iNatters, and I have had many discussions (in iNat itself) regarding the url hacks, and it has been one of many reasons to engage with people I would otherwise not have a reason to. Anyone needing advanced search functionality will generally ask how they can achieve something, and we can point them to how to accomplish that. I guess what I am saying is, there is no need to hand everyone a chainsaw, when for most people a pair of secateurs will do fine.
it already is⌠the api documentation describes them, and the url is where you access them.
Excluding potential QOL improvements to the GUI in the name of âstrengthening the communityâ does not make even a little bit of sense in my opinion. URL modification is clunky, annoying and time-consuming and I donât see how adding some helpful new functions to advanced search can even be considered to be anything less than a good idea.
I would definitely support having this more readily accessible (i.e. under Advanced options) and also under Observations and Identifications. It really isnât public knowledge that these are viable URL modifications, and there have been a number of threads on this functionality variously involving the Observations and Identify sections.
Iâd love to be able to exclude the âhomo sapiensâ entries when viewing new primate observations in my feed. Just my two centsâŚ
In the meantime, depending on what you mean by âfeedâ you can bookmark this URL to review primate obs excluding Homo spp.: https://www.inaturalist.org/observations/identify?taxon_id=43367&without_taxon_id=43583