Use OR boolean logic in URL searches for observation field values

Feature Requests
,
1

Platform(s), website

URLs (aka web addresses) of any pages, if relevant:

Description of need:
To include searches that can choose whether they have one field value OR the other, rather than AND.

Feature request details:
Currently in the url we can stitch together different field values or anything else with &, it would be nice to include either or.

For Example: I would like to make a search that will show results that have ‘DNA Barcode ITS’ field values OR ‘DNA sequence’ values.

2

I approved this request but after some discussion with our devs, this would be pretty complex so I’m not going to make any promises as far as implementation goes.

3

I understand doing OR on observation field values could be difficult because values are freeform text.

For annotations, we can pass in multiple comma-separated ids for term_id, and the app use OR to select the observations. It would be good to have something similar for observation fields. Pass in comma separated list of observation field ids.

I also wish there was an AND option for annotations, which is the current behavior for observation fields. For both annotations and observations fields, I think it would be good to let people choose AND or OR when doing query. Maybe add an annotations_operator and of_operator that accepts ‘or’ or ‘and’.

4

This doesn’t help with your observation field ask (although if this feature request was implemented, you could use the same trick), but I discuss a workaround for the AND logic for annotations in this tutorial here:

https://forum.inaturalist.org/t/searching-for-annotations-basic-to-advanced/65375

It’s definitely not as good or useful as built in functionality would be, but it can at least get you part of the way there.

5

I think the problem with using projects as a way to implement AND is that only the small percentage of people will read your post and know about that functionality. It would be better to have AND/OR option built into the API.

6

I agree. I still think that feature request would be valuable for other situations. I voted for this request as well because I think the best scenario is having it doable without community workarounds like mine.