tdwg
TG2-VALIDATION_GEODETICDATUM_STANDARD
| TestField | Value |
|---|---|
| GUID | 7e0c0418-fe16-4a39-98bd-80e19d95b9d1 |
| Label | VALIDATION_GEODETICDATUM_STANDARD |
| Description | Is the value of dwc:geodeticDatum valid according to the bdq:sourceAuthority? |
| TestType | Validation |
| Darwin Core Class | dcterms:Location |
| Information Elements ActedUpon | dwc:geodeticDatum |
| Information Elements Consulted | |
| Expected Response | EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is bdq:Empty; COMPLIANT if the value of dwc:geodeticDatum is a valid according to the bdq:sourceAuthority; otherwise NOT_COMPLIANT |
| Data Quality Dimension | Conformance |
| Term-Actions | GEODETICDATUM_STANDARD |
| Parameter(s) | |
| Source Authority | bdq:sourceAuthority = "GBIF GeodeticDatum Vocabulary" {[https://registry.gbif.org/vocabulary/GeodeticDatum/concepts]} |
| Specification Last Updated | 2024-11-11 |
| Examples | [dwc:geodeticDatum="EPSG:4326": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:geodeticDatum matches an unambiguous alphanumeric CRS or datum code value in the bdq:sourceAuthority"] |
| [dwc:geodeticDatum="7030": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:geodeticDatum doesn't match values in the bdq:sourceAuthority, 1730 (EPSG:1730) is an ellipsoid not a datum"] | |
| Source | ALA, GBIF |
| References |
|
| Example Implementations (Mechanisms) | |
| Link to Specification Source Code | |
| Notes | Darwin Core recommends best practice is to use a controlled vocabulary. This test must return NOT_COMPLIANT if there is leading or trailing whitespace or there are leading or trailing non-printing characters. Chapman and Wieczorek (2020) recommend best practice is to use EPSG geographic CRS or Datum codes (https://epsg.io/) as a controlled vocabulary. Ideally, amend to the EPSG code for the geographic coordinate reference system (CRS), if known. Otherwise use the EPSG code for the geodetic datum, if known. Otherwise use the EPSG code of the ellipsoid, if known. If none of these is known, use the explicit value "not recorded". While "not recorded" is not a valid EPSG code, it is a valid value according to Darwin Core. The reference vocabularies of values for geodetic datums and ellipsoids needs to be made available should map alternative representations of dwc:geodeticDatum strings to EPSG codes, such as "WGS84", "WGS_84", "WGS:84", "WGS 84" all with standard value "EPSG:4326". |
Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: 200 meters refers to only a few datums (Australia?) - In NAD27-WGS84 can be as high as 480 meters (from memory) in Aleutian Islands, and greatest distance is around 3,520 meters with an Indian Datum (again from memory)
Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: For NOTES Column
Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: Should we change name to GEODETIC_DATUM_AMBIGUOUS and make warning type Ambiguous?
Parameter is not needed for this test, the vocabulary expected by dwc;geodeticDatum is the EPSG vocabulary. Parameter might be needed to specify if the expected values are in the form https://epsg.io/4326, EPSG:4326, or WGS84, but the EPSG vocabulary is the one that everyone converges on, and different user communities are not likely to want different vocabularies for this test. The specification of the vocabulary should go into the specification or into the notes, not a parameter.
Agreed. Just accept https://epsg.io/ as the bdq:sourceAuthority and a value is valid if it is in that vocabulary. Perhaps we should format it as being a valid EPSG Code (as opposed to a Datum Code)
I have added "epsg:4326" to the examples, but shouldn't we delete WGS:84 and GD66 as valid examples when in #60 we suggest an amendment of WGS84 to epsg:4326?
This one is a tough one in that epsg isn't actually a standard either. But it is the closest we have and it is what Darwin Core recommends to use, if possible. Nevertheless, the EXPECTED_RESPONSE says, "or an unambiguous alphanumeric CRS or datum code", which makes all the examples in the Darwin Core definition valid, namely: EPSG:4326, WGS84, NAD27, Campo Inchauspe, European 1950, Clarke 1866, unknown. I think that all of those should trigger a COMPLIANT response. I would use all those examples and add, epsg:4326, and 4326.
Added to Notes: "This test will fail if there are leading or trailing white space or non-printing characters."
This is a 'test' where we reference bdq:sourceAuthority under INTERNAL_PREREQUISITES_NOT_MET but then use "is a valid EPSG CRS Code (with or without the "epsg" namespace prepended), or an unambiguous alphanumeric CRS or datum code;" subsequently. Should we reword it to something like
EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is EMPTY; COMPLIANT if the value of dwc:geodeticDatum is a valid EPSG CRS Code (with or without the "epsg" namespace prepended) in bdq:sourceAuthority, or an unambiguous alphanumeric CRS or datum code in bdq:sourceAuthority; otherwise NOT_COMPLIANT
or is that overkill?
@Tasilee Reading the rewrite struck me as odd. Made me pause. It doesn't seem wrong on inspection, but I am not sure it adds to the clarity of the test.
On advice from EPSG - changed in References: "https://www.epsg.org/" to "https://epsg.org/"
Changed Expected Response (and Specification Last Updated) from
EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is EMPTY; COMPLIANT if the value of dwc:geodeticDatum is a valid EPSG code; otherwise NOT_COMPLIANT
to
EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is EMPTY; COMPLIANT if the value of dwc:geodeticDatum is a valid EPSG CRS or datum code; otherwise NOT_COMPLIANT
Changed Expected Response from
EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is EMPTY; COMPLIANT if the value of dwc:geodeticDatum is a valid EPSG CRS or Datum code applicable to geographic coordinates in degrees; otherwise NOT_COMPLIANT
EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available, INTERNAL_PREREQUISITES_NOT_MET if dwc:geodeticDatum is EMPTY; COMPLIANT if the value of dwc:geodeticDatum is a valid EPSG CRS or Datum code applicable to geographic coordinates in degrees; otherwise NOT_COMPLIANT
Following ZOOM discussion, updated Expected Response, Description and Specification Last Updated to restrict application of the test to Datums applicable to geographic coordinates etc.
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField" and "Output Type" to "TestType".
Updated comment from "fail" to more specific "This test must return NOT_COMPLIANT if there is leading or trailing whitespace or there are leading or trailing non-printing characters. "
Changed Source Authority from
bdq:sourceAuthority = "EPSG" {[https://epsg.org]} {API for EPSG codes [https://apps.epsg.org/api/swagger/ui/index#/Datum]}
to
bdq:sourceAuthority default = "GBIF GeodeticDatum Vocabulary" [https://api.gbif.org/v1/vocabularies/GeodeticDatum]} {"dwc:lifeStage vocabulary API" [https://api.gbif.org/v1/vocabularies/GeodeticDatum/concepts]}
@Tasilee - some errors in that - in the second part you mention Life Stage - I thought we were following EPSG and not GBIF for GeodeticDatum - or have I missed something @tucotuco ?
Might be worth a note that
bdq:sourceAuthority = "EPSG" {[https://epsg.org]} [https://api.gbif.org/v1/vocabularies/GeodeticDatum]} {"GBIF GeodeticDatum API" [https://api.gbif.org/v1/vocabularies/GeodeticDatum/concepts]}
May be a viable alternative sourceAuthority, as the GBIF GeodeticDatum API appears to have name values that match EPSG codes. Still, since the authority EPSG themselves provide and API, we should definitely use that in the default.
@chicoreus - I agree. EPSG will always be up to date as it is the authority - GBIF may try to keep up to date, but could lag.