HI all,
Not sure where is best to ask this... so here goes. Let me know if there's
a better place.
The following are examples some users have highlighted for me as leading to
confusion when searching for taxa.
1. Macrozamia platyrachis (http://www.gbif.org/species/4928834) vs.
Macrozamia platyrhachis (http://www.gbif.org/species/2683551)
Here, the two spellings (with/without h) are accepted, and exact matches.
The sci. authority seems to differ with F. M. Bailey vs. F.M.Bailey. The
first is from GRIN taxonomy and the second from COL.
Anyway, for users e.g., of the R client, this is a bit confusing. I had
thought the backbone taxonomy would only have one master taxon key and name
for each real taxon, but here it seems like there's two?
2. Cycas circinalis (http://www.gbif.org/species/2683264 ) vs. Cycas
circinnalis (http://www.gbif.org/species/3594916 )
Here, the two spellings (with 1 or 2 "n"'s) are accepted, and exact
matches. The sci. authorities here are exactly the same. The first is from
COL and the second from IPNI taxonomy.
3. Isolona perrieri (http://www.gbif.org/species/3648546 ) vs Isolona
perrierii (http://www.gbif.org/species/6308376 )
Here, the two spellings (with 1 or 2 "i"'s) are accepted, and exact
matches. The sci. authorities here are exactly the same. The first is from
TPL and the second from COL
--------
Should I advise users to when searching on the backbone taxonomy to limit
to COL to avoid any confusion about names?
Best,
Scott Chamberlain
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
