I found out that some observations are recorded in GBIF, but can’t be found by searching for the country where they took place. Is there a way to achieve that?
Possible explanation in “Issues and flags”: “The taxonID… was not found in the associated checklist. … may be caused by a newly created ID that isn’t yet known in the version of the published checklist.”
Could that be the reason, every country has checklists even for insects, and if the species is not officially listed as present, it won’t appear in the search?
If so, is there a consistent way to filter and display all these observations, maybe with parameters in the search url (eg something like &checklistID=null or &datasetKey=null)?
Note: I know the location of some observations is either “obscured” or the accuracy is low enough to have possible locations in different neighboring countries, but this doesn’t seem to be the issue here.
I hope my question is clear, thanks for any information about that.
Hi S.E., the taxon identification should not play a role here. A more likely reason would be if the country could not be (unambiguously) identified based on the information supplied, e.g. if
the country name or code supplied by the source does not exist or could not be interpreted
no coordinates are given either that would allow placing the record in a country (missing, invalid, unlikely)
both coordinates and a country name/code are recognized, but they contradict each other
…
You can find more information on coordinate interpretation here, and on (geospatial) flags and issues here.
If you could provide an example for a record that provides country information, but that does not turn up in your search filter: could you post the URL to that search request, please? It will be easier to figure out what really happened that way. My suspicion is that the search contains other criteria to lead to the exclusion of said record, but if not, we would certainly like to find out!
OK, let’s say I enter “Tenthredo livida” on the searchbox on the home page, then click on “occurrences”.
I can’t see these observations on the map (I added a space after the https else the editor adds other formatting and I can’t read what I’m typing):
https ://www.gbif.org/occurrence/5830960577
https ://www.gbif.org/occurrence/6413468716
If I add a filter for the country Switzerland (CH) it lists 0 occurrences.
I hope it’s a good example because one location is “obscured” the other not, and both are located in the correct country, looking at the original records.
Maybe I’m missing something and you have an explanation for that… I noticed that issue recently.
BTW most other observations are correctly displayed on GBIF, even if the “obscured” locations falls in a different country than the coordinates’.
Thank you for these examples! You are right - this is indeed down to name issues rather than geoprocessing, if in a slightly different way than suspected.
In short, the version of the Catalogue of Life Extended Release that the GBIF occurrence store is currently organized against (COL26.6 XR) contains two entries with identical names and authorship, one of which marked as accepted from the United Kingdom Species Inventory (UKSI), the other as “provisionally accepted” from the “Taxon list of Hymenoptera from Germany compiled in the context of the GBOL project”. For whatever reason, GBIF’s species matcher currently aligns a number of occurrences against the “provisionally accepted” one, so that they turn up to a search that looks identical, but uses a different taxon concept (see here).
You can reproduce this by starting from the occurrence search page set with a filter for Switzerland, and starting to type the name “Tenthredo livida” in the search for Scientific name. This offers two near identical options, only distinguished by the status and the organization of their higher taxonomy:
Needless to say, this is certainly not what we want. The duplicate entry is already today fixed in the latest release of the COL XR (COL26.8 XR). This will mean that this issue should go out of scope with the next processing run of the GBIF occurrence store against the more recent version of COL. In addition, we will likely want to consider taking the status more explicitly into account when matching occurrences against the available taxonomic sources from COL.
Thanks for reporting this - I hope the explanation helps somewhat, even though it does not immediately fix the issue for users.
Great, I had this issue with several taxons/observations, now I can find them - provided I enter the country first, and then select the correct taxon. Thanks a lot for this explanation.
Best wishes for this update, taxonomy is a never ending fight as well as big data(bases…)
If I recall correctly, for e.g. families sometimes the provisionally accepted name is the “correct” one, i.e. the one containing most of the accepted species. That was 26.6 and 26.7 though, 26.8 seems to be looking pretty good so far from cursory checks.
as well as big data(bases…)