Hi folks, I want to find out what pollinators visit a specific plant. I’ve found that I can search for observations that match a specific observation field, such as “Interaction->Visited flower of”, using the ID number of the plant. Here’s such a search for Fragaria virginiana / Virginia Strawberry, a native plant I’m growing in my garden:
Sadly not everyone agrees on the best observation field to use for this purpose, so there are observations that do not appear in this search, but are tagged with a different observation field, such as “Nectar Plant” or “Nectar / Pollen delivering plant”:
I would like to construct a search URL that searches for all of these fields at the same time, an “or” search matching hits for any of these observation fields. Is this possible?
no. you can’t do that in a single request. three different observations will require three different queries. in this particular case, because the combined result is not more than a few hundred observations, you could use the API and create a script to combine the result of the 3 queries into 1 result set, or to create a new query that filters by observation id, referencing all the ids from the 3 result sets.
short of that, usually, GLOBI provides a nice interface for looking for interactions between different organisms. it’s limited to a subset of properly licensed research grade observations, but it does a good job of merging similar observation fields together and allowing you to search taxonomic groups as opposed to exact individual taxa. there’s some discussion here on various ways to interact with their data set: https://forum.inaturalist.org/t/downloading-notes-and-observation-fields-tags-via-the-inaturalist-api/54985/2.
I have a question related to this. I left IT too long ago to understand the modern implications of this. It used to be that we looked at any “click” as a maximum of one transaction… but this was before support for synchronous transactions by things like JavaScript. At what point is too many bundled transactions too much burden on the server. If I remember right, when JavaScript first came out, we were using it mostly to load meta data that was cached on the server anyway (to populate things like drop-downs). In other words… the synchronous piece was just used to load meta-data that was cached, but we were still only supposed to have one transaction per click for the non-cached stuff.
Maybe from the servers perspective a bunch of synchronous transactions don’t hurt anything but it slows down the client?
i’m not sure what you’re asking here. i think how much a server can handle is just based on its hardware and configuration and its connections to other stuff.
iNat generally asks for a user to try to keep API requests to about ~1 req per sec, but even if you give it a small number like 3 at the same time, it should still handle those fine. if you give it, say, 100 at the same time, what will happen is that most of them will get rejected. so if you want to give it a ton of requests, you need to manage how many you give the server at a time. a lot of people tend to submit requests serially, waiting for one to complete before sending another. for requests that involve paging, i tend to send requests semi-concurrently, with just an incremental delay between the initiation of requests but not waiting for the previous request(s) to complete before initiating another. iNat’s servers handle either method just fine.