bdq
bdq copied to clipboard
tdwg
TG2-AMENDMENT_COORDINATES_CONVERTED
| Field | 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 spatial reference systems. |
| Output Type | Amendment |
| Darwin Core Class | Location |
| Information Elements | dwc:decimalLatitude |
| dwc:decimalLongitude | |
| dwc:geodeticDatum | |
| dwc:coordinateUncertaintyInMeters | |
| dwc:coordinatePrecision | |
| 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 by a conversion between spatial reference systems; otherwise NOT_AMENDED |
| Data Quality Dimension | Conformance |
| Term-Actions | COORDINATES_CONVERTED |
| Warning Type | Amended |
| Parameter(s) | |
| Source Authority | |
| Examples | [dwc:decimalLatitude="-23.712", dwc:decimalLongitude="139.923", dwc:geodeticDatum="AGD66" : Response.status=AMENDED, Response.result=dwc:decimalLatitude="-23.712", dwc:decimalLongitude="139.923", dwc:geodeticDatum="WGS84" , Response.comment="Input fields contain interpretable values"] |
| [dwc:decimalLatitude="-93.712", dwc:decimalLongitude="139.923", dwc:geodeticDatum="GDA94" : Response.status=NOT_AMENDED, Response.result="", Response.comment="dwc:decimalLatitude was out of range"] | |
| Source | ALA, GBIF |
| References |
|
| Example Implementations (Mechanisms) | |
| Link to Specification Source Code | |
| Notes | These amendments have 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. A result status for a failure condition in attempting a conversion is NOTIFICATION_COORDINATES_CONVERSIONFAILED |
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)
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.
Agreed at TDWG 2018 DQIG meeting that the name TG2-AMENDMENT_COORDINATES_CONVERTED is satisfactory.
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.
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
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.
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.'
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).
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
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.
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.
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.
Yes, that fits better with other similar responses, but the reference to bdq:defaultGeodeticDatum seems odd. We have not done this elsewhere.
@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.
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?
@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.
Perhaps need something said in the Standards doc about Parameters and setting Parameters?
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.
@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)?
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!"
Note some have (1) and some 1) Note #67 has both!!! #57, #67, #70, #76 and #121 have (1), (2), etc.
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.
Perhaps need something said in the Standards doc about Parameters and setting Parameters?
Definitely.
@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.
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
Thanks @chicoreus - I agree we need to be more specific. Minor point, could we use bdq:defaultSRS to align with other bdqs
@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.