I’m making tentative steps towards having Dronefly Discord bot display establishment means information. These displays should show if an observation is native or introduced in the place it was observed, and a taxon display requested by a user with a preferred place should show the same info. However, I have run up against some difficulties choosing between two API calls, /v1/taxa/autocomplete vs. /v1/taxa/#, as the first returns incomplete results, and the second gives inconsistent results.
For these examples, consider the following three URLs, the first being what I see on the web, and the next two are two alternate API calls available to me to write bot code to do something similar.
https://www.inaturalist.org/taxa/3454
https://api.inaturalist.org/v1/taxa/autocomplete?q=zenaida+macroura&preferred_place_id=6853
https://api.inaturalist.org/v1/taxa/3454?preferred_place_id=6853
Because Nova Scotia, Canada (6853) is my preferred place, when I visit the web URL, I see:
This is my model for the information I want to include in our Dronefly bot displays.
But when I turn to the API to try to get this result using the /v1/taxa/autocomplete call, establishment_means is missing the text of the link to “Canada Check List”. It only has a reduced subset of the fields, containing the establishment means label (native) and id#, but missing the name of the checklist, which is needed to construct the link to the /listed_taxa page on the web.
"matched_term": "Zenaida macroura",
"iconic_taxon_name": "Aves",
"preferred_common_name": "Mourning Dove",
"establishment_means": {
"establishment_means": "native",
"id": 6435212,
"place": {
"id": 6712,
"name": "Canada",
"display_name": "Canada",
"ancestry": "97394"
}
},
"preferred_establishment_means": "native"
I had a glimmer of hope that maybe switching API calls would work for me, when I saw that /v1/taxa returned more info in “listed_taxa”, i.e. full establishment_means records, with “list” included in each, and within “list”, “title” which is suitable for the text of the link to the listed_taxa page. But then I started noticing inconsistent results. Here’s an excerpt from an earlier test run:
"listed_taxa_count": 89,
"listed_taxa": [
...
{
"id": 5535438,
"taxon_id": 3454,
"establishment_means": "native",
"place": {
"id": 6712,
"name": "Canada",
"display_name": "Canada",
"admin_level": 0,
"ancestor_place_ids": [
97394,
6712
]
},
"list": {
"id": 187791,
"title": "NatureServe Canada"
}
},
Note that a completely different listed_taxa id# is shown! It’s still for Canada, but from a different list (NatureServe Canada). So then I start filing this issue and tried reproducing the same result with the exact same API call, and got the original Canada Check List result again.
{
"id": 6435212,
"taxon_id": 3454,
"establishment_means": "native",
"place": {
"id": 6712,
"name": "Canada",
"display_name": "Canada",
"admin_level": 0,
"ancestor_place_ids": [
97394,
6712
]
},
"list": {
"id": 7025,
"title": "Canada Check List"
}
},
It’s not like it’s doing it every time. Most of the time, I’m getting back the NatureServe listing, but some of the time, I’m getting back the Canada Check List result. And it never gives me both (i.e. it always counts 89 entries in listed_taxa, but non-deterministically filling in one or the other listed entry for Canada each time. Shouldn’t it be always using the “primary listing”?
I went back to the web to confirm my initial result there and now It’s giving me the NatureServe listing instead:
wrong screenshot deleted - see new screenshot in the comments below. but note the API call output below that provides the evidence the flipping is real.
And now I can’t get it to show the Canada Check List result again, neither on the web, nor through the API call. So I have no idea how it’s deciding, but once it determines which record to give me, it keeps giving it to me for a while.
Because of this inconsistency, I have spent a few hours off in the wrong direction, thinking I didn’t really understand how it was supposed to work, or that I had made some error in how I had set up my tests. Frustrating.
Please check it out and see if both the web & the API can be made to always return consistent results for each place.
This isn’t a blocker anymore, now that I understand it’s inconsistent both on the web and through the API call. I’ll go write the code that does both API calls (the autocomplete one to match what the user types, and the /v1/taxa/# one to get the complete record from listed_taxa). It’s a bit inconvenient to do two calls where one would’ve been ideal, but not the end of the world. And if users notice the inconsistent results, I can at least refer them back to this Bug Report.
p.s. once I was done filing this Bug Report, I went back to up-arrow my curl tester and finally it had switched back to Canada Check List again …
$ curl -sl "https://api.inaturalist.org/v1/taxa/3454?preferred_place_id=6853" | python -m json.tool | grep "title.*Canada"
"title": "NatureServe Canada"
$ curl -sl "https://api.inaturalist.org/v1/taxa/3454?preferred_place_id=6853" | python -m json.tool | grep "title.*Canada"
"title": "NatureServe Canada"
$ curl -sl "https://api.inaturalist.org/v1/taxa/3454?preferred_place_id=6853" | python -m json.tool | grep "title.*Canada"
"title": "Canada Check List"
