Which ID of an observation is exported to GBIF?

@tiwane can you speak to the non-Explore aspects of this request? E.g. Identify, place checklists, and for me the big one is exports to GBIF. For example, in the screenshot below, you can see the observation has two IDs: one for Quercus agrifolia and one for genus Quercus. The community taxon says genus Quercus, but the observation taxon is Quercus agrifolia with the research grade banner next to it. This should be in GBIF at the genus level, but it’s actually exported at the species level. I guess I’m not sure whether a fix to Explore will necessarily solve this part of the problem.




The identification we share with data partners is the community identification

This isn’t true. Either the community taxon should be shared (as requested above), or the text should be changed.


This seems an important oversight, even a bug, that could undermine ID accuracy of observations going to GBIF. Perhaps warrants a separate topic, or a bug report, as this is not expected behaviour?

Well the “About community taxa” pop-up on observation pages used to also claim the community taxon was getting shared with data partners, but then it was “corrected” in May 2019 (just after the first post in this thread) to say observation taxon.


Pre-May 2019:

I think this indicates staff are definitely aware of the issue, and they either don’t consider it a bug or don’t have time to make the difficult change (export CID) and so would prefer to do the simple change (alter text).

So I totally agree this is not expected behavior, but I doubt a bug report or new topic will provide an additional push for change.

1 Like

The Account Settings page will be redone soon (within weeks) and will have amended text.

If the observer does opt out of CID, the observation won’t reach research grade unless the community agrees with the observer, meaning that GBIF should basically never get the observation because we only export research grade observations for GBIF.

(splitting this from a feature request)

This should only affect a small minority of observations. But I agree that because only research grade observations are exported to GBIF, and research grade is based on community ID, community ID should be what’s exported. I’ll see if it’s a change we can make.

1 Like

Great, thank you @tiwane!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

It does look like the identifier here intended to park this at genus level (in which case, why not a disagreeing ID?) - the best way to confirm this is to ask them, via an @ or private message.

iNat prioritizes the finer ID (observation ID) for display, but it should be the community ID (still at genus in this case) which is sent to GBIF. It was the case in the past that the observation ID got sent to GBIF, not the community ID, but hopefully that error has been fixed.

I just checked and data downloads from both iNat’s data export tool and GBIF are showing the species level ID and not the CID, which I believe is a mistake. Only the CID should be exported IMO.

For ease of checking, here’s the GBIF dataset I used:
GBIF.org (2 December 2023) GBIF Occurrence Download https://doi.org/10.15468/dl.r2qybm

I just searched for the iNat observation ID (13493532) to find the record.


Thanks @cthawley! @tiwane, on this other thread, now closed, you commented:

This seems like an important data management error that should be corrected. There are now a lot of observations that are RG at genus, for example, that if I understand correctly are being exported to GBIF with unconfirmed species-level IDs in cases where just one person has added a species-level ID.


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.