Dear API users,
Based on the recommendations from the GBIF Data Fitness for Use in Distribution Modelling group and user feedback, the GBIF Informatics team decided to apply some changes to the GBIF API for the occurrences[1] response. We decided to deprecate the field "coordinateAccuracy" in favor of the DarwinCore terms based fields "coordinateUncertaintyInMeters"[2] and "coordinatePrecision"[3] as provided(see details below) by the data publishers.
The JSON response will remain the same structure except:
- coordinateAccuracy will never be found since it will be null and null values are not provided explicitly (same as the current behaviour for most records)
- coordinateUncertaintyInMeters and coordinatePrecision will be included (example: coordinateUncertaintyInMeters: 1000, coordinatePrecision: 0.0001)
These changes should not break existing applications using the JSON API, and therefore as a non breaking change can be included in the V1 of our API as an enhancement.
Details:
-coordinateUncertaintyInMeters:
DarwinCore definition: "The horizontal distance (in meters) from the given decimalLatitude and decimalLongitude describing the smallest circle containing the whole of the Location. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term."
GBIF comment: double, must be greater and not equals to 0 and lower than 5000000 (5000 km), as provided by data publishers with unit stripped (if the value is provided in imperial, conversion will be applied), related issue OccurrenceIssue.COORDINATE_UNCERTAINTY_METERS_INVALID.
-coordinatePrecision:
DarwinCore definition: "A decimal representation of the precision of the coordinates given in the decimalLatitude and decimalLongitude."
GBIF comment: double, must be between 0 and 1, elated occurrence issue OccurrenceIssue.COORDINATE_PRECISION_INVALID
We expect the changes to be available next week (between 11-15 April 2016).
The GBIF Informatics team
----
[1] http://www.gbif.org/developer/occurrence
[2] http://rs.tdwg.org/dwc/terms/coordinateUncertaintyInMeters
[3] http://rs.tdwg.org/dwc/terms/coordinatePrecision
GBIF Issue tracking reference: http://dev.gbif.org/issues/browse/POR-2795
Hi all,
I am trying to download all occurrences inside the CAFF boundary area
following a request from the CAFF focal point in Norway. I have
converted the polygon to a Well Known Text object for use with the
GBIF API. (The WKT polygon looks fine when I test to open in QGIS).
http://www.gbif.org/developer/summary#authenticationhttp://www.gbif.org/developer/occurrence#predicateshttp://www.gbif.org/developer/occurrence#p_geometry
My filter.json file is attached and looks like this (the polygon
definition is truncated here at (...) for the purpose as example):
{
"creator":"dag.endresen",
"notification_address": ["dag.endresen(a)gmail.com"],
"predicate":
{
"type":"within",
"geometry":"POLYGON((179.285633734761433
50.81429697072722,179.600130309538514 50.798132663162107,180.0
50.825202656741141,-179.985731034706419
50.826168623278733,-179.642658093259286
50.834515997684633,-179.213664117412264 (...)
50.826278190103068,179.014229185979531
50.811745655072343,179.285633734761433 50.81429697072722))"
}
}
Error message:
Instantiation of [simple type, class
org.gbif.api.model.occurrence.predicate.WithinPredicate] value failed:
null (through reference chain:
org.gbif.api.model.occurrence.predicate.WithinPredicate["geometry"])
It might possible to download all occurrence data north of 50 degrees
(southernmost edge of the CAFF area) - and cut to CAFF area offline.
But because this is more than 200 million records, I am very
interested to check if it is possible to filter using the CAFF
boundary polygon.
http://www.gbif.org/occurrence/search?HAS_COORDINATE=true&decimalLatitude=5…
Best wishes
Dag
--
Dag Endresen
Node manager for GBIF Norway
ORCID: http://orcid.org/0000-0002-2352-5497
Hi,
A verbatim record of a sugenus
http://api.gbif.org/v1/species/100969508/verbatim
results in a name usage record
http://api.gbif.org/v1/species/100969508
where genus name, instead of subgenus name, treated
as the canonical name.
I suspect it is issue at the data sorurce, because Ficus (Diconoficus)
is the generic part of species name under the subgenus such as
Ficus (Diconoficus) gayana but never a subgenus name itself.
Looking at species record under the subgenus, however, e.g.
http://api.gbif.org/v1/species/100969511/verbatimhttp://api.gbif.org/v1/species/100969511
gives Ficus gayana as the canonical name.
This interpretation, i.e. omitting subgenus part from a canonical name,
might be issue of data parsing.
Or, is it an extpected client task to check verbatim records also?
Regards,
James
Hi,
Though it is not API issue per se, I found misinterpreted names such as
http://api.gbif.org/v1/species/114606608
where species epithet is interpreted as authority of the name.
I suspect that the crawler code assumes second or later word starting with
a capital letter as authority. I tried verbatim also but it is not successful.
Regerds,
James
I try to implement a lazy-loading taxonomy tree (as a demo for a open source javascript tree plugin).
See here for an example:
http://rawgit.com/mar10/fancytree/master/demo/taxonomy-browser/index.html#k…
What JSON API should use to get the top level nodes (i.e. Kingdoms)?
Currently I call
http://api.gbif.org/v1/species/search?rank=kingdom <http://api.gbif.org/v1/species/search?rank=kingdom>
but this returns much more than the ~7 entries I expect (Animalia, Plantae, Fungi, …)
I seem to get reasonable results, if I only display nodes with key == nubKey.
But the search results retrieved by `species/search?q=homo sapiens` returns multiple hits, and some of them have keys different from nubKey.
Those matches seem to be descendants of an `Animals` kingdom that also has nubKey != key.
I guess my mental model of the data structure is too naïve:
- why are there different ‚Animals‘ kingdoms with different keys but identical nubKey?
- does it make sense at all to display a tree (with only one ‚animals‘ node)?
- when I restrict the search results to entries that have a kingdom with key == nubKey, what will the user miss?
Thanks
Martin Wendt
