-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
Comment by Paula Zermoglio (@pzermoglio) migrated from spreadsheet: |
Comments from Gainesville: Need to split into two tests |
'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. |
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 |
@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? |
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? |
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 |
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. |
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. |
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 |
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 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". |
As we are providing elevation limits, the result either conforms to this range or it does not. There is no likeliness about it. |
Added "of bdq:minimumValidElevationInMeters to bdq:maximumValidElevationInMeters inclusive" in COMPLIANT for consistency with other related tests |
…ATION_INRANGE to match current specification. Moving default method to defaults class.
Edited Parameter(s) and Source authority to align with proposed structure and format |
…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.
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted" |
…ed to implementation.
The text was updated successfully, but these errors were encountered: