Upgrading the test suite's Features standard from version 1.0.0 to 1.0.1
Opened this issue · 9 comments
Describe the bug
The datetime related tests are being skipped since the test suite is based on/supports 1.0.0 and it is observed that it differs greatly from the latest 1.0.1 version.
To Reproduce
Steps to reproduce the behavior:
- Test against our test server
It contains a feature collection (id: 6dbcd15f-b497-42cd-8468-e3ecdf2daf7d) that has datetime properties defined in the extent property.
Expected behavior
Should run datetime related tests instead of completely skipping.
Additional context
The temporal extent is defined in 1.0.0 as the temporal field as a child of the extent object, as an array of two values (startTime, endTime).
Here is an example of an extent object as per version 1.0.0-
"extent": {
"spatial": [
5.61272621360749,
50.2373512077239,
9.58963433710139,
52.5286304537795
],
"temporal": [
"2018-05-18T14:45:44Z",
"2024-04-24T07:24:52Z"
]
}
whereas in 1.0.1, it is defined under an additional child field called interval under extent/temporal object as an array of array of time values.
Here’s an example of an extent object in version 1.0.1-
"spatial": {
"bbox": [
[
-180,
-90,
180,
90
]
],
},
"temporal": {
"interval": [
[
"2004-01",
"2004-12"
]
],
}
}
- Demo ldproxy server used in the feature compliance test suite based on 1.0.0 for testing the test code
https://www.ldproxy.nrw.de/kataster/collections/flurstueck?f=json - Demo Pygeoapi server implementing the latest 1.0.1 features standard
https://demo.pygeoapi.io/master/collections?f=json
This description contains incorrect statements:
- The schema of the "extent" member is unchanged between 1.0.0 and 1.0.1. 1.0.1 is a bugfix and it does not "differ greatly" from 1.0.0.
- The API at https://www.ldproxy.nrw.de/kataster is from 2018 or so. It does not implement v1.0.0 (as it is also obvious from the conformance declaration https://www.ldproxy.nrw.de/kataster/conformance?f=json). This is an unmaintained API. A newer API with the data (supporting version 1.0.1) is at https://ogc-api.nrw.de/lika/v1/collections/flurstueck?f=json.
It is, however, true that the CITE tests currently support v1.0.0, not v1.0.1. See #204. But I do not think that this impacts the "extent"-related tests.
@code-akki Are your questions clarified? If yes, can you please close this issue?
#204 is covering the support of version 1.0.1.
Thank you for the quick response and I understand the versioning semantics for the bug fix. According to the Feature standard v1.0.1 the extent
object contains spatial
and temporal
but within nested arrays, with temporal
object with an addtional interval
field, refer here, under Requirement 17 but the CITE implementation code is doing the temporal check omitting the interval
field expecting a single array instead of a nested array, refer here.
Another clarification is, if the temporal property for the feature collection only has single range, is it advised to omit the interval
field and put define the range under temporal
field?
@code-akki Tests time Parameter Definition
are passed on both environments, Production and Beta.
Can you please specify which test is skipped exactly?
Also, we realized that there are some additional failures on Beta which do not occur on Production. As Beta contains the more recent version of the test suite, it might be worth for you to check this. Please create new issues if you have any questions regarding the additional failures.
@dstenger Sorry for such a delayed response, I agree to the fact that timeParameter definition tests
are getting passed but none of the other time/temporal related compliance tests are executed as opposed to some other filtering for example, bbox
where there are extensive tests being run.
Except the timeParameterDefinition
test, none of the other tests such as validateFeaturesWithDateTimeOperation
, validateFeaturesWithDateTimeResponse
and so on are executed, which as pointed out in the compliance code,
temporal
as opposed to looking for the key interval
as defined in , OGC Features- Part I: Core v1.0.1, Feature Collections, Requirement 17.C.Thanks for responding. We will check this.
Please be aware that the test suite was implemented against version 1.0 of the specification.
It seems that the referenced Requirement 17 /req/core/fc-md-extent-multi
was introduced in version 1.0.1.
Is the test suite going to be upgraded with respect to new version 1.0.1 standard some time in the future? If so, what is the expected timeline?
@mbrachman reply to this