API endpoint species_counts returns strange preferred_common_name

NodeJS API v1

The API call using preferred_place_id results in strange names being used like “Earth-hog” and “Ceruleam Antelope”:

If the place_id is used instead of the preferred_place_id then the names are better (but then it throws out the threatened species, like Blue Duiker, so using place_id isn’t a viable alternative):

Links to the iNat pages:

Description of problem:
I would expect the call that uses the preferred_place_id to return the same names as the call that uses the place_id. The place_id has the more correct names.

Maybe the preferred_place_id variant always uses the last name?
(I’m not sure how to tell on the taxon page what name is used in what region, or which is the default.)

Even if I add the place_id (for example to South Africa), it still returns strange names:

Again, doing the reverse gives the correct names, but throws away species, so it’s unusable.

The preferred_place_id parameter is only used for localizing taxon names to that place (see the documentation at https://api.inaturalist.org/v1/docs/#!/Observations/get_observations_species_counts). You will not get a different number of results if you use preferred_place_id or not, but the common names you see will be the preferred common names for that place.

The place_id parameter will filter results to observations that occur in that place. Depending on the size and type of place and the geoprivacy of the observations, some observations may not appear in search place search results so as to not expose obscured locations. See https://forum.inaturalist.org/t/why-dont-these-observations-show-up-in-this-project-official-topic/12523/16 for a similar issue in the context of collection projects with place filters.

Since you’re filtering your search by project, and the project seems to have a limited geographical range, do you need to filter by place at all? Perhaps you’d prefer simply https://api.inaturalist.org/v1/observations/species_counts?project_id=17900&iconic_taxa[]=Mammalia - Mammal observations in your project not limited by place, and with common names not localized to a place?

1 Like

Thanks for the reply.

Yes, I understand there are issues regarding obscured observations, in this case not being picked up by “small” places. But that’s a different can of worms - including the argument of whether all threatened species should be obscured or not. Personally I would like to have less species obscured by default - in many cases it doesn’t make sense. It would be very helpful if there was a way to allow collection projects to include obscured observations, for example maybe if I join the project then my obscured observations can be included in the project.

Back to this problem:

  1. Can you maybe explain or show me how to see (and change) which names are used by my place? My place (id 124527) is nested under the Eastern Cape province (id 8872), which (I assume) is part of South Africa (id 6986). So why is it showing these strange names I’ve never heard spoken in South Africa?
    The names used by the Southern Africa (id 113055) place (or when no place is specified) are much better, though I believe still incomplete.

  2. My reasons for setting the preferred_place_id (and not the place_id) is as follows:

    • As discussed earlier I can’t use place_id, for the same reason I can’t switch over to a collection project, because it throws away too many species. I was able to include these species in the old project by hand, which is a saving grace. These are threatened species, and as such arguably the most important to have included. I use the project as a sort of “field guide”, so missing any species, especially the threatened ones, is not desirable.
    • It is supposed to return the best common names, yet as you can see the exact opposite is happening. For example everybody speaks of an “Impala”, so why does iNat think in SA we use “Pallah”? I’ve never heard this word being used before.
    • Most importantly, I set the preferred_place_id in order to get back the preferred_establishment_means, which is otherwise not included in the results.

The problem is definitely also present at the South Africa (or higher) level, because this link returns odd names as well:
Interestingly it seems even worse, with many Afrikaans names suddenly popping up as well.