Is there a way to limit the observations returned to only those…
that have an observation field called, say… “other organism” and
that observation field is of type taxon and
that observation field used names lookup and
that observation field has an iconic_taxa of, say… plantae?
I can filter out the observations I’m not interested in on the client, but it messes up the paging.
I think you can find what you’re looking for in this thread: https://forum.inaturalist.org/t/how-to-use-inaturalists-search-urls-wiki-part-1-of-2/63 . The parameters for the observations endpoint are almost exactly those of the regular search/explore page.
If I understood your question correctly, then the answer is no, but see this feature request: https://forum.inaturalist.org/t/searching-observations-with-this-field-and-value-for-fields-that-use-a-taxon-as-the-datatype-should-show-children-taxa/51902
yah, i’m gonna mark it solved and vote for that. that’s kinda the same thing, but more complex actually. i was just wanting to filter results by iconic that’s stored with the taxon for the OBS fields of type taxon… we aren’t supposed to define OBS fields that are specific to a taxon (e.g. using “plant” in the name of the field)… but then there is also no way to use the taxon information stored with the OBS field to filter results on the server side.
possible via parameter &field:oother%20organism
sort of possible via &ofv_datatype=taxon. otherwise, currently only possible on the client side.
likely not possible. i don’t think how the user inputs information to that field is even tracked anywhere. at best, i think you just have to assume that if the field was always set up as a taxon type field, then the only way a user could have entered the information without selecting from a lookup would be via a custom interface or via code.
currently only possible on the client side.
Does it help at all that the names lookup would seemingly always store a numeric as the value (corresponding to the taxon_id) and an external interface bypassing names lookup would seemingly always store a non-numeric (the name) as the obs field value?
select where is numeric() or some such
if you want to delineate things that way, sure, it’s possible to filter for only observations with numeric values in that observation field, but you’d have to do that on the client side, i believe.
Finally had time to revisit this a little. Now loading data into the session so I can filter more than one page, in theory… only loading 200 rows for now (limit on the query set to 1000). Is this closer to how you’d expect it to work?
new version
i’m not sure what you’re trying to build.
Mainly, it’s something that allows you to -or- observation fields together. There are many observation fields that are synonymous or nearly synonymous. This is something that comes up quite a bit on the forum (ability to -or- them together) and I thought it’d be nice if something existed to do this. When I’ve talked to people here in the past it’s been obvious that this would need to be a client side join… which is essentially what I’ve done. It’s meaningful to me because I’ve met several people in my same region who are restoring their own properties. We all met through iNat and were fairly established on iNat before we met (meaning we all made different choices about which observation field to use when wildlife is visiting a plant)…
name of associated plant
nectar / pollen delivering plant
nectar plant
plants that the organism was found on
host plant
etc.
This would allow all these fields to be or’d together and merged into a consolidated view… as long as the OBS fields are of the same datatype. Basically, how many times did someone in our group see something visiting plant x? It can also display multiple OBS fields of different types and allows sorting and filtering of those based on OBS field value and/or taxon.
ok. based on your description, i suppose the page is doing what you’re describing. without knowing what it’s supposed to do, it’s just not obvious what it’s supposed to do or how to get it to do what it’s supposed to do.
however, i think i can see how you’ve incorporated #2 from your original post, and i assume you’ve done #1, too. i didn’t check #3, and i’m not sure how to do #4.
sorry, yes… it’s still pretty confusing. I added a splash page similar to one of the links jwidness shared on another thread. the splash page requires an ofv_datatype (or you can specify “all”) and also allows any of the other parameters the obs endpoint takes to build the cache. when I set ofv_datatype to taxon, and enter the following in the query parameters field… “project_id=cincinnati-re-wild&term_id=1&term_value_id=6”, I get a list of all observations of larva documented visiting a plant on a project within our umbrella. participants within the umbrella used a total of seven different observation fields to document the plant that the larva was found on…
plant that the organism was found on
host plant id
host plant
name of associated plant
insect host plant
nectar / pollen delivering plant
other organism
I can select any (or all) of these from the drop down after building the cache. I can then merge them together… effectively “or’ing” them together. And then also select a specific taxon to see the number of occurrences of that larva species and which plants it’s been observed on.
If “all” the ofv_datatypes are chosen on the splash page, it lets you see different inter-related observation fields and allows filtration based on the observation field values. I do think it’s still a little confusing tho. Will probably think about it some more and adjust.