July 2015 - API-users - lists.gbif.org

204 response
by Scott Chamberlain 31 Jul '15

31 Jul '15

Hi all, I am curious as to the reasoning behind the 204 response for some API requests. For example: curl -v ' http://api.gbif.org/v1/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/metrics' < HTTP/1.1 204 No Content < Content-Type: application/json < Access-Control-Allow-Origin: * * Server Jetty(9.2.z-SNAPSHOT) is not blacklisted < Server: Jetty(9.2.z-SNAPSHOT) < x-api-url: /v1/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/metrics < Accept-Ranges: bytes < Date: Fri, 31 Jul 2015 17:46:32 GMT < X-Varnish: 1108784184 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive I assume this means that that dataset ID is not found? If so, I would have expected a 404 perhaps. There's no other info in the headers, so I'm not sure what other reason there is for no data returned (I realize a 204 should not return a body). I know this dataset ID used to return data, as I used it in examples for hitting the /dataset/*/metrics route In other APIs I get a 204 on a successful DELETE request - that's the only context I'm familiar with wrt 204's Thanks! Scott

2 2

Patch to fix Deserialisation failure of BoundingBox
by Nozomi James Ytow 30 Jul '15

30 Jul '15

Hi, I might report it previously, the Java web service client code fails to deserialise Dataset because of BoundingBox code. org.gbif.api.model.registry.eml.geospatial.BoundingBox does not have setGlobalCoverage(boolean) method while JSON response has globalCoverage of boolean. Here is a fix patch. James --- org/gbif/api/model/registry/eml/geospatial/BoundingBox.java.orig 2014-06-27 00:00:00.000000000 +0900 +++ org/gbif/api/model/registry/eml/geospatial/BoundingBox.java 2015-07-30 23:22:18.962696356 +0900 @@ -18,6 +18,7 @@ import java.io.Serializable; import java.util.Locale; +import org.codehaus.jackson.annotate.JsonIgnore; /** * Geographic coverage geometry in the form of 4 sided bounding box. @@ -103,6 +104,15 @@ } /** + * Set whether this binding box represents global coverage or not. + * + * @param globalCoverage global coverage status to set + */ + public void setGlobalCoverage(boolean globalCoverage) { + isGlobalCoverage = globalCoverage; + } + + /** * Set whether this binding box represents global coverage or not. Setter ensures all 4 required params are provided. * * @param minLatitude min latitude @@ -110,6 +120,7 @@ * @param minLongitude min longitude * @param maxLongitude max longitude */ + @JsonIgnore public void setGlobalCoverage(double minLatitude, double maxLatitude, double minLongitude, double maxLongitude) { isGlobalCoverage = checkIsGlobalCoverage(minLatitude, maxLatitude, minLongitude, maxLongitude); }

1 0

numDescendants in species/?name response
by Nozomi James Ytow 30 Jul '15

30 Jul '15

Hi, is there any modification made in numDescendants in species/?name response? For example, http://api.gbif.org/v1/species/?name=Lembus returened one record with 2 descendants (I remember it as http://api.gbif.org/v1/species/102321492 ) and two records with 16 descendatns arournt 2015-07-29 04:00 UTC (ish) but now only one record of GBIF Backborn Taxonomy with 16 descendants and others have no descendants. http://api.gbif.org/v1/species/?name=Lembus%20infusionum was shered lower name in there three records. http://api.gbif.org/v1/species/102321493 is one of Lembus infusionum which has parentKey 102321492. The parent key is the record had two descandants. The modified implementation requires to try /species/{int}/children even if numDescendants is zero, because there may be descendants. I prefer to the previous implementation to navigate classifications. James

2 5

coordinateAccurracy field
by Scott Chamberlain 21 Jul '15

21 Jul '15

Hi all, Did the coordinateAccurracy used to exist and was removed at some point? I can see mention of it e.g., here http://dev.gbif.org/issues/browse/POR-1804?jql=text%20~%20%22coordinateAccu… - but perhaps it has been removed? I can see that the elevationAccuracy field is returned with many records, but haven't seen coordinateAccurracy in any records. Thanks! Scott

3 5

mediaType parameter not working anymore
by Scott Chamberlain 10 Jul '15

10 Jul '15

Is anyone else having this problem, e.g., http://api.gbif.org/v1/occurrence/search?mediaType=StillImage returns { - offset: 0, - limit: 20, - endOfRecords: true, - count: 0, - results: [ ] } Thanks, Scott

3 3