Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TG2-VALIDATION_MINELEVATION_INRANGE #39

Open
iDigBioBot opened this issue Jan 5, 2018 · 17 comments
Open

TG2-VALIDATION_MINELEVATION_INRANGE #39

iDigBioBot opened this issue Jan 5, 2018 · 17 comments
Labels
CODED Conformance CORE TG2 CORE tests Parameterized Test requires a parameter SPACE Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT TG2 Validation

Comments

@iDigBioBot
Copy link
Collaborator

iDigBioBot commented Jan 5, 2018

TestField Value
GUID 0bb8297d-8f8a-42d2-80c1-558f29efe798
Label VALIDATION_MINELEVATION_INRANGE
Description Is the value of dwc:minimumElevationInMeters within the Parameter range?
TestType Validation
Darwin Core Class dcterms:Location
Information Elements ActedUpon dwc:minimumElevationInMeters
Information Elements Consulted
Expected Response INTERNAL_PREREQUISITES_NOT_MET if dwc:minimumElevationInMeters is bdq:Empty or the value is not a number; COMPLIANT if the value of dwc:minimumElevationInMeters is within the range of bdq:minimumValidElevationInMeters to bdq:maximumValidElevationInMeters inclusive; otherwise NOT_COMPLIANT
Data Quality Dimension Conformance
Term-Actions MINELEVATION_INRANGE
Parameter(s) bdq:minimumValidElevationInMeters
bdq:maximumValidElevationInMeters
Source Authority bdq:minimumValidElevationInMeters default = "-430"
bdq:maximumValidElevationInMeters default = "8850"
Specification Last Updated 2023-09-17
Examples [dwc:minimumElevationInMeters="0": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:minimumElevationInMeters is IN_RANGE"]
[dwc:minimumElevationInMeters="-500": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:minimumElevationInMeters is NOT_IN_RANGE (<-430)"]
Source ALA, GBIF
References
Example Implementations (Mechanisms) Kurator/FilteredPush geo_ref_qc Library DOI: 10.5281/zenodo.14064324
Link to Specification Source Code https://github.com/FilteredPush/geo_ref_qc/blob/v2.0.1/src/main/java/org/filteredpush/qc/georeference/DwCGeoRefDQ.java#L582
Notes We have rounded up the Parameter values. We are aware of sub-ice elevations in Antarctica to -3,500m and possible sampling in the atmosphere above the elevation of the top of Mt Everest that would fail this test but we support the odd false positive.
@iDigBioBot
Copy link
Collaborator Author

Comment by Paula Zermoglio (@pzermoglio) migrated from spreadsheet:
Elevation CAN be less than 0, and I would not expect it to be more than 8,848m (Mt. Everist summit)

@ArthurChapman ArthurChapman added the Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT label Jan 16, 2018
@tucotuco tucotuco changed the title TG2-VALIDATION_MINELEVATIONMAXELEVATION_OUTOFRANGE TG2-VALIDATION_MINELEVATION_OUTOFRANGE Jan 16, 2018
@ArthurChapman
Copy link
Collaborator

Comments from Gainesville: Need to split into two tests

@ianengelbrecht
Copy link
Collaborator

'if the value of the field dwc:maximumElevationInMeters is number between -423 and 8850 inclusive' -should that be dwc:minimumElevationInMeters? Also is there a reason for -423 as lower bound? I understand, possibly incorrectly, that the lowest is the Dead Sea shore at -413m.

@ArthurChapman
Copy link
Collaborator

Thanks @ianengelbrecht - yes should be minimum and not maximum (I have fixed). Thanks for picking that up. I see that the reference we cite https://en.wikipedia.org/wiki/List_of_elevation_extremes_by_country has been updated and the Dead Sea has been changed from -423 to -428 (perhaps other references give different values). I have corrected that in the expected response above. Should we alter this to -430 (-450) or something to allow rounding. What do you think @tucotuco

@ArthurChapman
Copy link
Collaborator

ArthurChapman commented Mar 11, 2019

@tucotuco I see that the reference we cite has Mt Everest at 8848 m. We seem to have rounded that to 8850, so perhaps we should round the minimum to -430 especially as the Wikipedia footnote (34) states that it falls about 1 m per year and gives -428 as the 2014 level. I am also wondering if Wikipedia is the best reference here, or a more permanent reference?

@Tasilee
Copy link
Collaborator

Tasilee commented Mar 14, 2019

Just back on deck. Thanks @ianengelbrecht and @ArthurChapman. I agree that we should round these limits out to -430 to +8850, but I wonder then if this one is 'Parameterized' so that installers/implementers could provide their own min/max?

@ArthurChapman
Copy link
Collaborator

Interesting suggestion, @Tasilee. If it was parameterized (for example if someone was working in Australia and wanted to set the maximum and minimum for Australia) that would make sense. We would then default to -430 to +8850 as the default if parameter not set. Would need to rewrite and put a note to the effect that if the parameter is not set it reverts to -430 to +8850

@Tasilee Tasilee added the Parameterized Test requires a parameter label Mar 17, 2019
@tucotuco
Copy link
Member

I like the idea of rounding a bit beyond the extremes. It will avoid discussions (hopefully) of what different sources have to say.

I really like the idea of a parametrized test. We could create a reference data set of extremes by country code as well.

@chicoreus
Copy link
Collaborator

Data Quality Dimension isn't correct. This is a test of Likelihood, not Conformance, as there is no standard to conform to, just the distribution of likelyhood of occurrences against elevations within some region of interest.

We should check all tests that assert a data quality dimension of Conformance to make sure that they do actually involve the data conforming to some standard rather than being a test of likely values in the real world.

@ArthurChapman
Copy link
Collaborator

I notice that the Expected Response doesn't include the possibility of Paramaterization as discussed in comments above. Probably needs rewriting to allow for Paramaterization

@Tasilee
Copy link
Collaborator

Tasilee commented Aug 12, 2019

I agree with @chicoreus and amended Dimension and will check Conformance on others next.

@ArthurChapman: How do we refer to Parameters? Maybe like this: INTERNAL_PREREQUISITES_NOT_MET if the field dwc:minimumElevationInMeters is not present, is EMPTY or is not a number; COMPLIANT if the value of the field dwc:minimumElevationInMeters conforms to Parameters; otherwise NOT_COMPLIANT ? This would reduce edits.

@Tasilee
Copy link
Collaborator

Tasilee commented Aug 12, 2019

Do all agree that #24, #107 (and this one) should be Data Quality Dimension = Likelihood?

What about #108? I presume Conformance.

@ArthurChapman
Copy link
Collaborator

ArthurChapman commented Aug 12, 2019

@Tasilee I think your wording makes sense and would lead to consistency throughout - especially if we then use a namespace for the Parameters. How does this fit with the coding @chicoreus

Not sure about #24 and #108 being Likelihood - it is Conformance - because the minimum elevation cannot ever be greater than maximum elevation and same for depth. @chicoreus? I am not sure you are correct wrt to Conformance and Range - definition of Conformance "From the FFU Framework: A Data Quality Dimension (q.v.) - conforms to a format, syntax, type, range, standard, or to the own nature of the Information Element (q.v.)." NB "range" in the definition. Likelliness: From the FFU Framework: "A Data Quality Dimension (q.v.) - probability of data having the expected value; the likelihood of a data having true values rather than having false values".

@Tasilee
Copy link
Collaborator

Tasilee commented Aug 16, 2019

As we are providing elevation limits, the result either conforms to this range or it does not. There is no likeliness about it.

@Tasilee Tasilee changed the title TG2-VALIDATION_MINELEVATION_OUTOFRANGE TG2-VALIDATION_MINELEVATION_INRANGE Mar 22, 2022
@ArthurChapman
Copy link
Collaborator

Added "of bdq:minimumValidElevationInMeters to bdq:maximumValidElevationInMeters inclusive" in COMPLIANT for consistency with other related tests

chicoreus added a commit to FilteredPush/geo_ref_qc that referenced this issue Jun 5, 2023
…ATION_INRANGE to match current specification. Moving default method to defaults class.
@Tasilee
Copy link
Collaborator

Tasilee commented Jun 13, 2023

Edited Parameter(s) and Source authority to align with proposed structure and format

chicoreus added a commit to FilteredPush/geo_ref_qc that referenced this issue Jun 20, 2023
…st current (2023-06-12) test descriptions. Addressed implementation of tdwg/bdq#39 VALIDATION_MINELEVATION_INRANGE Adding ProvidesVersion annotations. Added to unit test.  Removing now empty file stubs for checked methods.
@Tasilee
Copy link
Collaborator

Tasilee commented Sep 16, 2023

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted"

@chicoreus chicoreus added the CORE TG2 CORE tests label Sep 18, 2023
chicoreus added a commit to FilteredPush/geo_ref_qc that referenced this issue Aug 19, 2024
@chicoreus chicoreus added the CODED label Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CODED Conformance CORE TG2 CORE tests Parameterized Test requires a parameter SPACE Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT TG2 Validation
Projects
None yet
Development

No branches or pull requests

6 participants