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	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 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.
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.'

[chicoreus]

Implicit, but needs to be made explicit that the input CRS is the presented value of dwc:geodeticDatum, and that the output CRS (and the proposed amended value for dwc:geodeticDatum is EPSG:4326.

This test likely also needs to be parameterised for the output CRS, with EPSG:4326 as a default, but allowing other users to convert the decimalLatitude/decimalLongitude/geodeticDatum/coordinateUncertaintyInMeters/coordinatePrecision to a specified national datum.

Notes also refer to non-existant NOTIFICATION_COORDINATES_CONVERSIONFAILED, where this should be INTERNAL_PREREQUSITES_NOT_MET (or external, if the failure cause is in a lookup phase of the conversion).

[Tasilee]

This test certainly needs a rethink as dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision are Information elements that are not in the Expected response (but are in the Notes), and I agree with @chicoreus about it needing to be Parameterised. How about a straw persons:

Description: Propose an amendment to the value of dwc:geodeticDatum and potentially to dwc:decimalLatitude, dwc:decimalLongitude, dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision based on a conversion between spatial reference systems.

The Expected response will have to be complex to accommodate the issues. I am not sure of the logic of how the NOT_AMENDED will apply:

Expected response: INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude or dwc:geodeticDatum are EMPTY or not interpretable; AMENDED the values of dwc:decimalLatitude, dwc:decimalLongitude, and dwc:geodeticDatum based on a conversion between spatial reference systems; AMENDED the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion; AMENDED the value of dwc:coordinatePrecision provided from the conversion; otherwise NOT_AMENDED.

Parameter(s): bdq:defaultGeodeticDatum

Source Authority: bdq:defaultGeodeticDatum="EPSG:4326"

Notes: The Coordinate Reference System is being represented by dwc:geodeticDatum. 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.

I am unsure about how to handle a conversion failure or error. I can't see it being an INTERNAL_PREREQUISITES_NOT_MET

[tucotuco]

How about...?

Expected response: INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid, or if dwc:geodeticDatum is EMPTY or not interpretable, or if the value of bdq:defaultGeodeticDatum is not interpretable; AMENDED the values of dwc:decimalLatitude, dwc:decimalLongitude, and dwc:geodeticDatum based on a conversion between spatial reference systems; AMENDED the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion; AMENDED the value of dwc:coordinatePrecision provided from the conversion; otherwise NOT_AMENDED.

[Tasilee]

Thanks @tucotuco. I am uncomfortable about the structure of the three AMENDED, but how you would deal separately with the three components under a single.

[tucotuco]

Maybe something like this?

Expected response: INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid, or if dwc:geodeticDatum is EMPTY or not interpretable, or if the value of bdq:defaultGeodeticDatum is not interpretable; AMENDED a) the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum based on a conversion between spatial reference systems, b) the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion, and c) the value of dwc:coordinatePrecision provided from the conversion result; otherwise NOT_AMENDED.

[Tasilee]

Yes, that fits better with other similar responses, but the reference to bdq:defaultGeodeticDatum seems odd. We have not done this elsewhere.

[chicoreus]

@Tasilee yes, right to be uncomfortable with the phrasing of three AMENDED. @tucotuco easy for us to not quite get it right, as AMENDED is a constant that represents a value that Response.status can take, all too easy for us to read it as a verb rather than a value. Thus "AMENDED a), needs some verb about the proposed change, e.g. "AMENDED a) propose new values for", similarly for the other clauses.

@tucotuco with the phrasing change above, and the suggestion below, I like the logic of your proposal https://github.com/tdwg/bdq/issues/43#issuecomment-1593884907

Suggestion, add bit to the internal prerequisites not met clause to indicate that a supplied code for an coordinate refference system must be applicable to dwc:decimalLatitude/decimalLongitude, e.g. changing "if the value of bdq:defaultGeodeticDatum is not interpretable;" to "if the value of bdq:defaultGeodeticDatum is not interpretable as the CRS for a geographic coordinate system;"

with bdq:defaultGeodeticDatum given as a parameter, and the default value for this parameter being EPSG:4326. @ArthurChapman may suggest a a different name for the parameter based on other parameters we are using, or not, it feels reasonable for me.

[Tasilee]

I agree with most of the suggestions except for adding references in the Expected response to testing a bdq term. If we do it here, why are we not doing it everywhere? For example #112: bdq:minimumValidElevationInMeters is a valid numeral, etc etc?

[chicoreus]

@Tasilee good catch. "or if the value of bdq:defaultGeodeticDatum is not interpretable" is not something we do elsewhere. We implicitly assume that the values of parameters provided to tests are valid, and if they are not, the behavior of an implementation is undefined.

The value supplied for the parameter for the test is not an attribute of the data, it is an attribute of the Mechanism (of the system assessing the data quality). If we included assertions about the validity values of parameters, they should only return external prerequisites not met, as they are assertions about externalities to the data and will change if the same data are run on the same test with a different configuration.

I would advocate just discussing that assessing the validity of parameter values is out of scope for the tests, and that when presented with invalid parameters, the results of tests are undefined.

[ArthurChapman]

Perhaps need something said in the Standards doc about Parameters and setting Parameters?

[Tasilee]

I would leave the expected response as something like

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values, or if dwc:geodeticDatum is EMPTY or contains an uninterpretable value; AMENDED a) the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum based on a conversion between spatial reference systems, b) the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion, and c) the value of dwc:coordinatePrecision provided from the conversion result; otherwise NOT_AMENDED.

and I agree that we include a statement in the standards document about our assumptions for "bdq: parameters" and I've put in a PLACEHOLDER in a new section 2.3 for now.

[ArthurChapman]

@Tasilee Not sure that works. we only want b) and c) if a) happens - the way it is written that is not explicit. I think it works without the "a)", "b)", "c)"

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values, or if dwc:geodeticDatum is EMPTY or contains an uninterpretable value; AMENDED the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum based on a conversion between spatial reference systems; the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion; and the value of dwc:coordinatePrecision provided from the conversion result; otherwise NOT_AMENDED.

BTW - where do we use (1), (2), (3) and where a), b), c)?

[Tasilee]

I'm unsure of the logic implied by the structure. With the 1) (or a), we are structuring it as

AMENDED 1)......2)......3)

so the use of ";' doesn't fit as we use those as a separator between EXTERNAL, INTERNAL, AMENDED, NOT_AMENDED.

We use a), b) etc on #125

We use use 1), 2) etc on #57, #67, #70, #76, #121

I will edit #125 accordingly. Another nice pickup @ArthurChapman and yet another "again!"

[ArthurChapman]

Note some have (1) and some 1) Note #67 has both!!! #57, #67, #70, #76 and #121 have (1), (2), etc.

[Tasilee]

Yep, now all standardized.

[Tasilee]

So, are we happy with

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values, or if dwc:geodeticDatum is EMPTY or contains an uninterpretable value; AMENDED (1) the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum based on a conversion between spatial reference systems, (2) the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion, and (3) the value of dwc:coordinatePrecision provided from the conversion result; otherwise NOT_AMENDED.

[chicoreus]

Perhaps need something said in the Standards doc about Parameters and setting Parameters?

Definitely.

[chicoreus]

@Tasilee not happy yet. "based on a conversion between spatial reference systems," doesn't tell us which SRS we are converting from and which SRS we are converting to.

This test needs to have a parameter with a default value, and needs to state that the conversion is from dwc:geodeticDatum to the SRS specified in the parameter.

Given a parameter bdq:targetSRS with default value EPSG:4326

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values, or if dwc:geodeticDatum is EMPTY or contains an uninterpretable value; AMENDED (1) the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum based on a conversion between their SRS specified by dwc:geodeticDatum, and bdq:targetSRS, (2) the value of dwc:coordinateUncertaintyInMeters (if it was an interpretable value) to add the uncertainty of the conversion, and (3) the value of dwc:coordinatePrecision provided from the conversion result; otherwise NOT_AMENDED.

With a note that if dwc:geodeticDatum specifies the same SRS for dwc:decimalLatitude and dwc:decimalLongitude as bdq:targetSRS (e.g. if dwc:geodeticDatum has the value WGS84 rather than the EPSG code for the SRS that uses WGS84 for geographic coordinates), then the coordinates are assumed to be in the target SRS and the Response.status is NOT_AMENDED.

[ArthurChapman]

I can accept that - note if this accepted we need to add bdq:targetSRS to Vocabularly #152. Also note that this test would then also need to be Parameterized

[Tasilee]

Thanks @chicoreus - I agree we need to be more specific. Minor point, could we use bdq:defaultSRS to align with other bdqs

[chicoreus]

@ArthurChapman "we only want b) and c) ", we can handle that by connecting the (1), (2), with and/or. The (n) separators make the clauses easier to read, but you are correct, they aren't needed here.

Thus (and does read more cleanly with words):

Given a parameter bdq:targetSRS with default value EPSG:4326

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values, or if dwc:geodeticDatum is EMPTY or contains an uninterpretable value; AMENDED if the values of dwc:decimalLatitude, dwc:decimalLongitude and dwc:geodeticDatum are changed based on a conversion between their SRS specified by dwc:geodeticDatum, and bdq:targetSRS, 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.

With a note that if dwc:geodeticDatum specifies the same SRS for dwc:decimalLatitude and dwc:decimalLongitude as bdq:targetSRS (e.g. if dwc:geodeticDatum has the value WGS84 rather than the EPSG code for the SRS that uses WGS84 for geographic coordinates), then the coordinates are assumed to be in the target SRS and the Response.status is NOT_AMENDED.

[chicoreus]

@Tasilee we could use bdq:defaultSRS, the back of my mind wants to use targetSRS in this case, probably something not fully thought through about what we are conforming the data to in what cases.

[ArthurChapman]

The only other one we use bdq:default... is bdq:defaultGeodeticDatum so bdq:defaultSRS would be OK - it is different to other bdq:... as these would have, I guess bdq:defaultSRS default=xxxx. I wouldn't like bdq:SRS default= so bdq:targetSRS would be OK and fit more with the others - but then we probably should change bdq:defaultGeodeticDatum - not sure what to as default works as in the test title. In this case, I think I am happy with bdq:targetSRS

[Tasilee]

OK, then please check the changes to the Expected response and Notes, and edit away, and remove NEEDS WORK if it doesn't.

[ArthurChapman]

43 and #87 slightly different wording for the same concept

43 INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or not valid values

87 INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude or dwc:decimalLongitude are EMPTY or either of the values are not interpretable as numbers

Which do we want?

[Tasilee]

"...not valid values.." seems slightly more generic, but we have certainly used a lot of "...interpreted as ...". I'm slightly favouring the former but happy either way. We will need to check for consistency again.

[ArthurChapman]

I'll leave it until we get more feedback before I change anything

[chicoreus]

The two statements "valid values" and "interpretable as numbers" have quite different meanings. Valid values means that not only is the data of the correct type, but it is in range for the term. A valid dwc:decimalLatitude is a number within the range -90 to 90. Inteprpretable as numbers means that the data (which are expected to be strings, can be interpreted to be of the correct data type for the term, for dwc:decimalLatitude "A" does not meet this condition, "465.23" does.

In #87 we are only identifying 0,0 coordinates, we aren't mixing this test into an assessment of whether the decimalLatitude or decimalLongitude is in range, there are other tests that address that question. Thus the only question asked of a numeric value is whether it is 0, and if it is not a numeric value, we can't assess that.

In #43, on the other hand, we are converting a coordinate to a new datum, and if the values for the cooordinate are not valid, we can't perform that transformation.

Thus the difference, and the importance of the difference.

In a few cases (e.g. dwc:month) we do (or have discussed) extend the concept of "interpreted" from the simple the string contains a number e.g. in the form (-){0,1}[0-9]+(.[0-9]*){0,1} to interpreting some roman numerals "X" as integers. Generally, however, by interpreted as a number, we mean simply a data type conversion, e.g. that code like the Java Integer.parseInt("10") will return the integer 10.

[tucotuco]

May I suggest?

INTERNAL_PREREQUISITES_NOT_MET if dwc:decimalLatitude is EMPTY or dwc:decimalLatitude does not have a valid value or dwc:decimalLongitude is EMPTY or dwc:decimalLongitude does not have a valid value, or dwc:geodeticDatum is EMPTY or dwc:geodeticDatum does not contain an uninterpretable value;

[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