TG2-AMENDMENT_COORDINATES_CONVERTED

[iDigBioBot]

TestField	Value
GUID	620749b9-7d9c-4890-97d2-be3d1cde6da8
Label	AMENDMENT_COORDINATES_CONVERTED
Description	Propose amendment to the value of dwc:geodeticDatum and potentially to dwc:decimalLatitude and/or dwc:decimalLongitude based on a conversion between coordinate reference systems.
TestType	Amendment
Darwin Core Class	dcterms:Location
Information Elements ActedUpon	dwc:decimalLatitude
	dwc:decimalLongitude
	dwc:geodeticDatum
	dwc:coordinateUncertaintyInMeters
	dwc:coordinatePrecision
Information Elements Consulted
Expected Response	INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is bdq:Empty or does not have a valid value, or dwc:decimalLongitude is bdq:Empty or does not have a valid value, or dwc:geodeticDatum is bdq:Empty or does not contain an interpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between the coordinate reference systems as specified by dwc:geodeticDatum and bdq:targetCRS, and, if dwc:coordinateUncertaintyInMeters is an interpretable value, the uncertainty from the conversion is added to it, and the value of dwc:coordinatePrecision is provided from the conversion result; otherwise NOT_AMENDED.
Data Quality Dimension	Conformance
Term-Actions	COORDINATES_CONVERTED
Parameter(s)	bdq:targetCRS
Source Authority	bdq:targetCRS default = "EPSG:4326" {[https://epsg.org]} {EPSG Endpoint for translations [https://epsg.io/transform]}
Specification Last Updated	2023-09-18
Examples	[dwc:decimalLatitude="-23.712", dwc:decimalLongitude="139.923", dwc:geodeticDatum="AGD66", dwc:coordinateUncertaintyInMeters="", dwc:coordinatePrecision="": Response.status=AMENDED, Response.result=dwc:decimalLatitude="-23.7105001", dwc:decimalLongitude="139.924185", dwc:geodeticDatum="EPSG:4326", dwc:coordinateUncertaintyInMeters="", dwc:coordinatePrecision="6", Response.comment="Input fields contain interpretable values: xform using "https://epsg.io/transform#s_srs=4202&t_srs=4326&x=139.9230000&y=-23.7120000" "]
	[dwc:decimalLatitude="-93.712", dwc:decimalLongitude="139.923", dwc:geodeticDatum="GDA94", dwc:coordinateUncertaintyInMeters="", dwc:coordinatePrecision="": Response.status=NOT_AMENDED, Response.result=, Response.comment="dwc:decimalLatitude was out of range"]
Source	ALA, GBIF
References	Chapman, AD and Wieczorek, JR (2020). Georeferencing Best Practices. Copenhagen: GBIF Secretariat (https://doi.org/10.15468/doc-gg7h-s853) EPSG.io: Transform coordinates (https://epsg.io/transform)
Example Implementations (Mechanisms)
Link to Specification Source Code
Notes	This test relates only to EPSG codes applying to coordinate reference systems where the coordinate system is EPSG:6422 (Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: north, east. UoM: degree), or EPSG:6423 (Ellipsoidal 3D CS. Axes: latitude, longitude, ellipsoidal height. Orientations: north, east, up. UoM: degree, degree, metre.). Any amendment has implications for dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision. If the dwc:coordinateUncertaintyInMeters is EMPTY or is not interpretable, this amendment should not provide a dwc:coordinateUncertaintyInMeters. If the dwc:coordinateUncertaintyInMeters is not EMPTY and is valid, this amendment should add the uncertainty contributed by the conversion to the value of dwc:coordinateUncertaintyInMeters. The amended dwc:coordinatePrecision should be the precision of coordinates as provided after the conversion, ideally this should be 0.0000001, reflecting the seven digits of precision required to reverse a coordinate transformation without loss of information at the scale of one meter. If dwc:geodeticDatum specifies the same CRS for dwc:decimalLatitude and dwc:decimalLongitude as bdq:targetCRS (e.g., if dwc:geodeticDatum has either the value "WGS84" or "EPSG:4326" and the bdq:targetCRS is "EPSG:4326"), then the coordinates are assumed to be in the target CRS and the Response.status is NOT_AMENDED.

[iDigBioBot]

Comment by Anonymous migrated from spreadsheet:
None

[ArthurChapman]

Comments from Gainesville and previous discussions: (ANON)Amounts to a recommendation that aggregators should flag all coordinates that had to be converted to be used. Might also imply saying something about the datum and uncertainty as a result. Potentially drop the WGS84 datum requirement. (/ANON) (JW)Caution indeed. Conversion without careful consideration has implications for obfuscating coordinatePrecision and coordinateUncertaintyInMeters.(/JW) (AT)Might need to modify the georeference remarks (/AT) (AC)Need to nail down Best Practices here (/AC) (AC) Some of above to be added to NOTES Column(/AC) (PJM)Mindfull of JW's comment "Caution Needed" (/PJM)

[ArthurChapman]

Discussion at Gainesville: This one needs more work with respect to Notes and how to deal with Uncertainty. Should NOT define a coordinateUncertaintyInMeters if one not already defined as one may be introducing a false value/uncertainty.

If an AMENDMENT is made, then all steps carried out should be documented as part of the ANNOTATION.

[tucotuco]

Agreed at TDWG 2018 DQIG meeting that the name TG2-AMENDMENT_COORDINATES_CONVERTED is satisfactory.

[Tasilee]

Going through the test data, I am assuming that the input data can only contain values among the Information Elements and that the Expected Response should include explicitly (or implicitly?) all those elements?

In this AMENDMENT, we make no direct reference to dwc:coordinateUncertaintyInMeters or dwc:coordinatePrecision in the Expected Response but we do in the notes. Currently, the test data doesn't reference either term.

Also from the Notes, "NOTIFICATION_COORDINATES_CONVERSIONFAILED" doesn't match the Expected Response.

[Tasilee]

I would also suggest modifying

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude and dwc:decimalLongitude were EMPTY or the value of dwc:geodeticDatum was not interpretable; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude, and dwc:geodeticDatum were changed based on a conversion between spatial reference systems; otherwise NOT_CHANGED

to

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude or dwc:geodeticDatum are EMPTY or not interpretable; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude, and dwc:geodeticDatum were changed based on a conversion between spatial reference systems; otherwise NOT_CHANGED

[tucotuco]

I would recommend a slight further modification to the modification:
INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude or dwc:geodeticDatum are EMPTY or not interpretable; AMENDED if the values of dwc:decimalLatitude or dwc:decimalLongitude or dwc:geodeticDatum were changed based on a conversion between spatial reference systems; otherwise NOT_CHANGED

An amendment can perfectly reasonably leave one of two of the fields unchanged in a conversion.

[Tasilee]

Thanks @tucotuco. I'll amend now.

[tucotuco]

I suggest the Description:

'Propose amendment to the value of dwc:geodeticDatum and potentially to dwc:decimalLatitude and/or dwc:decimalLongitude based on a conversion between spatial reference systems.'

in place of:

'Propose amendment to the values of dwc:decimalLatitude or dwc:decimalLongitude or dwc:geodeticDatum based on a conversion between spatial reference systems.'

[ArthurChapman]

I have updated the Expected Response (in line with modified last comment), the Specification Last Updated and the Notes, Parameter and Source Authority to change SRS to CRS in line with ZOOM discussion of 2023-06-23.

Also added Parameterized to this test as it now requires a Parameter for bdq:targetCRS

Please check this before I remove NEEDS WORK

[Tasilee]

Thanks @ArthurChapman. I'd suggest a minor change from

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is EMPTY or does not have a valid value, or dwc:decimalLongitude is EMPTY or does not have a valid value, or dwc:geodeticDatum is EMPTY or does not contain an uninterpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between their coordinate reference systems as specified by dwc:geodeticDatum, and bdq:targetCRS, and in consequence, the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) has uncertainty of the conversion added to it, and the value of dwc:coordinatePrecision is given as provided from the conversion result; otherwise NOT_AMENDED.

to

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is EMPTY or does not have a valid value, or dwc:decimalLongitude is EMPTY or does not have a valid value, or dwc:geodeticDatum is EMPTY or does not contain an uninterpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between the coordinate reference systems as specified by dwc:geodeticDatum and bdq:targetCRS, and if dwc:coordinateUncertaintyInMeters was an interpretable value, the uncertainty of the conversion is added to it, and the value of dwc:coordinatePrecision is provided from the conversion result; otherwise NOT_AMENDED.

[ArthurChapman]

Another suggested slight modification to

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is EMPTY or does not have a valid value, or dwc:decimalLongitude is EMPTY or does not have a valid value, or dwc:geodeticDatum is EMPTY or does not contain an uninterpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between the coordinate reference systems as specified by dwc:geodeticDatum and bdq:targetCRS, and, if dwc:coordinateUncertaintyInMeters was an interpretable value, the uncertainty from the conversion is added to it, and the value of dwc:coordinatePrecision is FILLED_IN as provided from the conversion result; otherwise NOT_AMENDED.

[Tasilee]

Agreed @ArthurChapman and updated. NEEDS WORK?

[ArthurChapman]

Would still like @chicoreus and @tucotuco to check

[ArthurChapman]

Added additional Reference to the EPSG Transform Coordinates

[Tasilee]

Updated examples in the light of missing dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision in test data

[chicoreus]

@ArthurChapman FILLED_IN is a constant value for Response.status, and can't be applied separately to individual information elements.

s/or does not contain an uninterpretable value/or does not contain an interpretable value/

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is EMPTY or does not have a valid value, or dwc:decimalLongitude is EMPTY or does not have a valid value, or dwc:geodeticDatum is EMPTY or does not contain an interpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between the coordinate reference systems as specified by dwc:geodeticDatum and bdq:targetCRS, and, if dwc:coordinateUncertaintyInMeters was an interpretable value, the uncertainty from the conversion is added to it, and the value of dwc:coordinatePrecision is provided from the conversion result; otherwise NOT_AMENDED.

[Tasilee]

I have updated the Expected response as above, and in the light of email comments about EPSG codes (thanks @chicoreus and @tucotuco), I have amended the Notes to..

This test relates only to EPSG codes applying to spatial reference systems where the coordinate system is EPSG:6422 (EPSG:Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: north, east. UoM: degree). Any amendment has implications for dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision. If the dwc:coordinateUncertaintyInMeters is EMPTY or is not interpretable, this amendment should not provide a dwc:coordinateUncertaintyInMeters. If the dwc:coordinateUncertaintyInMeters is not EMPTY and is valid, this amendment should add the uncertainty contributed by the conversion to the value of dwc:coordinateUncertaintyInMeters. The amended dwc:coordinatePrecision should be the precision of coordinates as provided after the conversion, ideally this should be 0.0000001, reflecting the seven digits of precision required to reverse a coordinate transformation without loss of information at the scale of one meter. If dwc:geodeticDatum specifies the same CRS for dwc:decimalLatitude and dwc:decimalLongitude as bdq:targetCRS (e.g. if dwc:geodeticDatum has the value WGS84 rather than the EPSG code for the CRS that uses WGS84 for geographic coordinates), then the coordinates are assumed to be in the target CRS and the Response.status is NOT_AMENDED.

OK?

[tucotuco]

Looks mostly good. One thing could be slightly more specific. I suggest changing "(e.g. if dwc:geodeticDatum has the value WGS84 rather than the EPSG code for the CRS that uses WGS84 for geographic coordinates)" to '(e.g., if dwc:geodeticDatum has either the value "WGS84" or "EPSG:4326" and the bdq:targetCRS is "EPSG:4326")'.

[Tasilee]

Thanks @tucotuco: Done.

[ArthurChapman]

Changes "spatial reference system" to "coordinate reference system" in description

[Tasilee]

Updates Source Authority from

bdq:targetCRS default = "EPSG:4326" {[https://epsg.org]}

to

bdq:targetCRS default = "EPSG:4326" {[https://epsg.org]} {EPSG Endpoint for translations [https://epsg.io/transform]}

[chicoreus]

Updated notes to include EPSG:6423, 3D lat/long

[Tasilee]

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Fields" to "TestFields" and "Output Type" to "TestType".

This one will be confusing in relation to "ActedUpon" and "Consulted": What is the consensus on how we handle this? All Information Elements are optionally ActedUpon.

[tucotuco]

I would say that dwc:decimalLatitude, dwc:decimalLongitude, dwc:geodeticDatum, and dwc:coordinatePrecisionInMeters are the ones that would be consulted.

An aside, the first example does not follow best practices. Though there might be an error of up to 3 meters associated with that transformation, it would be incorrect to set dwc:coordinateUncertaintyInMeters if the original was EMPTY. The only thing that should be done is to add the transformation error to an already valid dwc:coordinateUncertaintyInMeters. Otherwise dwc:coordinateUncertaintyInMeters should be left EMPTY.

[Tasilee]

Thanks @tucotuco. Logically, all Information Elements are indeed Consulted, and also ActedUpon in the sense here of being potentially altered.

Point taken on the Example. I will fix in the Validation Data and here.

[tucotuco]

This test has been moved from CORE to Immature/Incomplete based on the realization that there are numerous cases of datum transformations that would require an assessment of a large number of distinct coordinate reference system transformation algorithms each with potentially distinct resulting transformed coordinates. This happens when there are multiple specifications of coordinate reference systems for a given datum (e.g., AGD66, NAD27, ED50, etc.). One would have to run all possible transformations and analyze the differences in the results, rather than getting a simple single result to use for the transformed coordinates. It is possible to implement this test, but Task Group 2 does not have the resources to provide a rigorous implementation.

[tucotuco]

Closing as Immature/Incomplete, not to be included in the standard submission.