Interpret coordinateAccurracy from dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision
15032
Reporter: mdoering
Assignee: mdoering
Type: NewFeature
Summary: Interpret coordinateAccurracy from dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision
Description: The interpreted coordinateAccuracy field is a double representing the accuracy in decimal degrees. Interpret this field based on either the dwc:coordinateUncertaintyInMeters or the dwc:coordinatePrecision. If only precision is given (in decimal degrees) the precision can be copied to the interpreted accuracy. If uncertainty in meters is given it needs to be converted to decimal degrees based on the latitude the point is in.
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2014-02-10 12:46:15.075
Updated: 2016-03-17 14:22:29.368
Resolved: 2016-02-10 23:12:32.622
Author: trobertson@gbif.org
Created: 2015-11-30 11:46:18.748
Updated: 2015-11-30 11:46:18.748
Moreover, dwc:coordinateUncertaintyInMeters is not interpreted at all.
http://api.gbif.org/v1/occurrence/1088909149/verbatim has
"http://rs.tdwg.org/dwc/terms/coordinateUncertaintyInMeters": "10014"
while there is no coordinateUncertaintyInMeteres in http://api.gbif.org/v1/occurrence/1088909149
Author: dschigel
Created: 2015-11-30 12:17:10.516
Updated: 2015-11-30 12:18:43.204
As I understand, several modelling users, especially Townsend Peterson are very interested in seeing this as part of the interpreted data, esp. as this information is available at VertNet, but is lost somewhere on the way from VertNet to GBIF.
More, if the issues is fixed as in the description, do we need to indicate what is primary, what is secondary, i.e. decimal -> meters or meters -> decimal?
Author: mdoering@gbif.org
Created: 2015-11-30 12:34:36.954
Updated: 2015-11-30 12:35:10.263
When we interpret terms we remove redundant terms if they are used for interpretation. This is to avoid contradictory values in the interpretated view. For example all date terms are removed to interpret the single colleciton date or all coordinate terms for the lat/lon values.
The problem here is that we lack the interpretation code, but already have listed the term coordinateUncertaintyInMeters in the set of terms that act as an interpretation source and therefore are removed: https://github.com/gbif/occurrence/blob/master/occurrence-common/src/main/java/org/gbif/occurrence/common/TermUtils.java#L87
Author: dagendresen
Created: 2015-12-03 12:22:21.535
Updated: 2015-12-03 12:22:21.535
Providing the coordinateUncertaintyInMeters in the data download (and API) is more useful than coordinatePrecision (given as decimal degree) -- in particular on higher latitudes such as e.g. Denmark and Norway.
Latitude 0, equator: 1 degree = 111 120 meter
Latitude 50N, Denmark: 1 degree = 71 696 meter
Latitude 58N, South of Norway: 1 degree = 59 133 meter
Latitude 71N, North of Norway: 1 degree = 36 351 meter
So at least for modelling occurrence data for Norway, making the calulation of all coordinatePrecision into coordinateUncertaintyInMeters would provide a much more useful attribute to filter occurrence data fit for use than only providing this attribute calculated into a decimal degree that have very variable actual length in real SI units...
Availability of coordinateUncertaintyInMeters is in high demand from Norwegian species distribution modellers we have contact with at the Norwegian GBIF node. We try to prioritize to calculate/provide this attribute for datasets published from Norway.
Author: mdoering@gbif.org
Created: 2016-02-02 12:37:07.175
Updated: 2016-02-02 14:50:18.038
Initial implementation using the magic number of 1843m per lat degree minute to convert meters into latitudinal degrees. These do not change much with distance to the equator, only the -latitudinal- *longitudinal* degrees changes with the latitude: https://en.wikipedia.org/wiki/Geographic_coordinate_system#Expressing_latitude_and_longitude_as_linear_units
We consider offering a read only property coordinateAccurracyInMeters if it indeed is of public interest
Author: dagendresen
Comment: I guess you mean: "only the --longitudinal-- degrees changes with the latitude". (The distance east-west is smaller per longitudinal degree when moving north to higher latitudes, or south. The distance north-south per latitudinal degree remains the same).
Created: 2016-02-02 12:54:56.584
Updated: 2016-02-02 12:54:56.584
Author: mdoering@gbif.org
Comment: err, of course Dag.
Created: 2016-02-02 14:49:29.802
Updated: 2016-02-02 14:49:29.802
Author: cgendreau
Comment: I have received more than one request to provide interpreted uncertaintyInMeters directly.
Created: 2016-03-16 14:24:13.086
Updated: 2016-03-16 14:24:13.086
Author: mdoering@gbif.org
Comment: Christian, isn't that covered with the commit above? We would only need to interpret all records for it to become visible
Created: 2016-03-16 22:49:18.76
Updated: 2016-03-16 22:49:18.76
Author: cgendreau
Created: 2016-03-17 09:00:39.512
Updated: 2016-03-17 10:12:58.906
Not exactly, I would expose coordinateUncertaintyInMeters directly (and keep the property name coordinateUncertaintyInMeters), without the round-trip conversion.
We will also have to discuss how we deal with 'coordinateAccuracy' because the word accuracy here is problematic but that's for later.