@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.
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.
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.
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.
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.
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.
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.
