Exclude certain taxa in Identify user interface

#1

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.

Exclude more than one taxon with the search filter
#2

Can you provide a specific example of what you’d like to do?

#3

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.

3 Likes
#4

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

2 Likes
#5

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.

2 Likes
#6

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.

1 Like
#7

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!

2 Likes
#8

So true!

Having this in the user interface would be a big help :)

2 Likes
#9

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.

3 Likes
#10

I edited the topic title to make the request a bit clearer. Feel free to further modify.

3 Likes
#11

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…

1 Like
#12

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?

1 Like
#13

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.

3 Likes
#14

I would definitely support an “advanced search” in the GUI

3 Likes
#16

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).

1 Like
#17

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.

#18

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.

4 Likes
#19

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.

2 Likes