We’re trying to improve both the consistency and efficiency of making Dronefly displays include user counts of taxa. The current API endpoints cause various problems for us as I describe below. We would simply like an API call that counts leaf node taxa per user for a set of users.
Here’s an example display from https://github.com/synrg/dronefly/issues/98 which shows a typical display interaction. A user requests a display for their own counts for a taxon, and another user presses a button to add their own count:
To limit the number of API calls made, the additions and removals to this table are handled one at a time as users press the buttons. This approach means the table is prone to inconsistencies caused by various people adding their stats over time, since the total line at the bottom is recalculated on each button press, but otherwise only newly added users are fetched from the API for each line in the table. We’d solve those inconsistencies if we could by fetching all of the user counts from one API call and updating all users in the table at once, but no single API call is available to tally up all of the leaf taxa.
/v1/observations/observers endpoint tantalizingly seems to offer the answer, except it returns
observation_count per observer only for the "distinct rank of
species" and not leaf taxa. See: https://api.inaturalist.org/v1/docs/#!/Observations/get_observations_observers
/v1/observations/species_count also yields disappointing results. It lumps all of the counts into a single statistic per taxa for all requested users. That’s great for determining the total, but otherwise needs to be called once per observer, racking up a considerable number of API calls in succession if you want the latest data for more than just a handful of users. Eventually those calls will add up to enough to cause noticeable delays, as Dronefly’s rate throttling will kick in to adhere to iNat’s required rate limits.
Therefore, we request an API call that returns stats like
/v1/observations/observers but without restricting counts to species rank, returning leaf node taxa instead. If
/v1/observations/observers cannot itself be modified, could it please be modified in the next version of the API?
Confusingly, this API endpoint also offers as parameters
lrank, which seem to promise a way to break free of the "distinct rank of
species" constraint, but alas, these don’t help. Adding
rank=genus to the API call will count up any observations of rank genus in the
species_count in that case is
0, an unhelpful result for our use case.
We don’t want to change our Dronefly tables from counting leaf taxa to species because the broader concept of “leaf taxa” is more motivating when it comes to discovering more kinds of life, since for various reasons, the kinds found might not have any chance of attaining a species-level ID. We have observed that users are interested in finding as many as they can, even when that is the case. Furthermore, the counts have a second role in the display: each count is also a link to search those observations on the iNat web site which counts leaf taxa too, not "distinct rank of
species". We need the number shown in the display to match what is shown on the web.
Our members enjoy the flexibility and ease of use of Dronefly not only to check how they’re doing on their goals, but also to do this with others who share the same, sometimes niche interests. We hope to build out for them some more advanced features in Dronefly to broaden the range of this kind of activity on Discord. Implementing this feature request would assist us in this goal, achieving a net win for the users, for Dronefly, and for iNaturalist as a whole. Through these bot interactions, we encourage users to be more engaged with each other, with nature, and with the iNat data that they are collectively improving. Unfortunately, without this help from the API, writing more code in that direction will cost more in terms of API calls and/or result in more inconsistencies in the tables, leading to a poor user experience.
We hope there’s no huge technical barrier here to satisfying this request and that it fits with your overall plans for the API. Please let us know what you think can be done.