Upgrading the test suite's Features standard from version 1.0.0 to 1.0.1

[code-akki]

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:

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

Screenshots

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

[cportele]

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.

[dstenger]

@code-akki Are your questions clarified? If yes, can you please close this issue?
#204 is covering the support of version 1.0.1.

[code-akki]

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?

[dstenger]

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

[code-akki]

@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,

ets-ogcapi-features10/src/main/java/org/opengis/cite/ogcapifeatures10/util/JsonUtils.java

Line 88 in 0e54b40

List<Object> coords = (List<Object>) spatial;

only populates the value for coordinates by looking at key 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.

[dstenger]

Thanks for responding. We will check this.

[dstenger]

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.

[code-akki]

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]

@mbrachman reply to this