extents not easily extensible as the connections to the reference systems are not clear #168

m-mohr · 2018-09-21T09:38:02Z

I am struggling a bit with the extent in WFS collections. Currently, it has basically fours fields:

temporal
spatial
crs
trs

To me this looks a bit dirty as the crs and trs are not closely bound to the corresponding fields. For example, one could think about adding more extents, for example temperature or another temporal extent, which (I think) happens in Meteorology. How would that work?

Example:

{
      "extent": {
        "spatial": [
          180,
          -56,
          -180,
          83
        ],
        "temporal": [
          "2015-06-23T00:00:00Z",
          "2015-06-24T00:00:00Z",
        ],
        "temporal2": [
          "2015-06-24T00:00:00Z",
          "2015-06-25T00:00:00Z",
        ],
        "temperature": [0, 273.15],
        "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
        "trs": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
        "trs2": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
        "temperature_rs": "http://www.opengis.net/def/uom/SI/kelvin"
      }
}

In this case one could argue that the temporal ref system is just the same, but you probably get the point here. It is also not easy to map the fields of the ref systems to the actual fields for the values.

Also, you can't easily go through all extents because crs and trs are no extents. You can separate them by data types (array/string), but that doesn't feel right.

So I'd think there should be a consistent way to add the reference systems to the actual extents and it should be considered that there are more extents to be added to the object of extents. I think that's why the extents are actually combined and not just a separate spatial_extent and temporal extent field, right?

This could be resolved like this:

{
      "extent": {
        "spatial": [
          180,
          -56,
          -180,
          83
        ],
        "temporal": [
          "2015-06-23T00:00:00Z",
          "2015-06-24T00:00:00Z",
        ],
        "temporal2": [
          "2015-06-24T00:00:00Z",
          "2015-06-25T00:00:00Z",
        ],
        "temperature": [0, 273.15]
      },
      "refsys": {
        "spatial": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
        "temporal": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
        "temporal2": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
        "temperature": "http://www.opengis.net/def/uom/SI/kelvin"
      }
}

There are other ways to structure that and I am not saying that we should do exactly what the example shows, but it's should be more an inspiration.

The text was updated successfully, but these errors were encountered:

pvretano · 2018-09-21T11:27:30Z

I think I would prefer something that follows OWS common more closely. Something like this:
"extent": {
"spatial": [
{
"ndims": 2,
"lower": [10, 10],
"upper": [20, 20],
"crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
},
{
"ndims": 2,
"lower": [40, 40],
"upper": [40, 50],
"crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
}],
"temporal": [
{
"lower": "2015-06-23T00:00:00Z",
"upper": "2015-06-24T00:00:00Z",
"trs": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
},
{
"lower": "2015-06-23T00:00:00Z",
"upper": "2015-06-24T00:00:00Z",
"trs": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
}],
"thermal": [
{
"lower": 0,
"upper": 273.15,
"uom": "http://www.opengis.net/def/uom/SI/kelvin"
}]
}

Some notes ...
(1) The "extent" structure should be extensible.
(2) Only the "spatial" and "temporal" extent structures should be defined in the core
(3) The "thermal" (or any other) extent would be defined is some extension.

Just my $0.25 worth ...

m-mohr · 2018-10-05T13:26:14Z

I fully agree with your three notes. Not sure what the ndims is useful for - this can be determined by the lower/upper element count. Why is the "trs" not simply also "uom"?

This looks a bit better to me:

{
  "extent":{
    "spatial":[
      {
        "lower":[10,10],
        "upper":[20,20],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      },
      {
        "lower":[40,40],
        "upper":[40,50],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      }
    ],
    "temporal":[
      {
        "lower":"2015-06-23T00:00:00Z",
        "upper":"2015-06-24T00:00:00Z",
        "uom":"http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
      },
      {
        "lower":"2015-06-23T00:00:00Z",
        "upper":"2015-06-24T00:00:00Z",
        "uom":"http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
      }
    ],
    "thermal":[
      {
        "lower":0,
        "upper":273.15,
        "uom":"http://www.opengis.net/def/uom/SI/kelvin"
      }
    ]
  }
}

pvretano · 2018-10-05T13:29:36Z

@m-mohr Sure ... looks good to me!

rcoup · 2018-10-05T14:02:19Z

@pvretano @m-mohr Can you explain what spatial extent this actually describes?

"spatial":[
      {
        "lower":[10,10],
        "upper":[20,20],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      },
      {
        "lower":[40,40],
        "upper":[40,50],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      }
    ],

cportele · 2018-10-05T14:19:01Z

In addition to @rcoup's question:

I would be in favour of keeping it in the Core to a single spatial and temporal extent. We can agree that it may be extended with multiple items in the array (which I assume is a "multi-bbox"), or other aspects like "thermal" in extensions, but that should be extensions. Simple client would then just pick the first extent and ignore the additional ones.
Instead of { "lower":"2015-06-23T00:00:00Z", "upper":"2015-06-24T00:00:00Z" } maybe we should use the same notation as in the time parameter: 2015-06-23T00:00:00Z/2015-06-24T00:00:00Z?
In the temporal case, it should be "trs" or "crs", not "uom". I would prefer "crs" as spatial CRS and temporal CRS are still both CRSs, but could live with both. But the Gregorian calendar is not a unit, it is a reference system.

pvretano · 2018-10-05T15:40:45Z

@rcoup The data is concentrated in two different areas. Gives a more precise idea where clients should query to have a better chance of finding data.

m-mohr · 2018-10-05T16:05:20Z

Please let me note that I was just requesting changes to the proposal of @pvretano - that was no vote to really adopt that proposal! I actually tend to prefer another (the current?) notation.

@cportele
Regarding your second bullet point: I think that is not a good idea to merge the bounds as it would make searching really hard as you need to split the string beforehand. I think separating them as it is right now is the better idea.
Regarding the third bullet point: That suggestion basically originates from OGC itself: So why is the Gregorian calender grouped into uom: http://www.opengis.net/def/uom/ISO-8601/0/Gregorian ?

cportele · 2018-10-05T17:38:45Z

@m-mohr

Second bullet: Fair point. Then I would prefer to keep the array notation as it currently is.
Third bullet: I never noticed that. I see that the W3C time ontology uses the URI as the value of the hasTRS property (see figure 3), which just adds to the confusion. I will check with some time experts why it was associated with uom in the URI definition.

cportele · 2018-10-06T12:51:04Z

On the use of uom: I reached out to Simon Cox (chair of the OGC Naming Authority when the URI was registered and co-author of the W3C Time ontology). He confirmed that it should not have been registered under "uom". It is a reference system, not a unit of measurement (which can be considered a sub-class of "reference system"). I would suggest we use trs to be consistent with the Time ontology.

pvretano · 2018-10-06T14:52:24Z

@cportele

Just to be clear ... are you proposing that we modify the extent schema in the core to follow what is being discussed here (i.e. spatial and temporal array values) with that caveat that in the core only the first spatial and temporal extents are required? If yes, that I agree with that approach. If no, then I think we should consider doing it to pave the way for extensions. I know that my WFS, for example, will try to find the islands of data in a collection and report multiple BBOXes.
For the time parameter, using lower-time/upper-time notation is good with me.
Yes, I used trs in my example because I remembered that Simon said (no pun intended) that it should be trs so I am good with that.

cportele · 2018-10-06T15:32:03Z

@pvretano

Just to be clear ... are you proposing that we modify the extent schema in the core to follow what is being discussed here (i.e. spatial and temporal array values) with that caveat that in the core only the first spatial and temporal extents are required? If yes, that I agree with that approach. If no, then I think we should consider doing it to pave the way for extensions. I know that my WFS, for example, will try to find the islands of data in a collection and report multiple BBOXes.

That was the idea. If we expect that extensions will want to use multiple bboxes then we need to make sure this is supported by the Core.

I would just not use lower/upper, but a single array for the bbox with 4/6 coordinates.

rcoup · 2018-10-08T20:53:18Z

@pvretano uh huh, but I'm obviously not getting it. Can you convert that specific example to WKT?

cportele · 2018-10-09T05:11:14Z

@rcoup - I do not see how WKT would make it more clear than the lower/upper notation? This is just about a set of bboxes instead of a single one. Say, a bbox for the continental US, one for Alaska and one for Hawaii instead of a single one for the US that includes larger areas with no data.

(The second bbox in Peter's example was probably meant to be (40,40)-(50,50) or something similar).

rcoup · 2018-10-09T09:54:29Z

I wasn't asking to use WKT, I just wanted to know what actual spatial extents this example describes: 😄

"spatial":[
      {
        "lower":[10,10],
        "upper":[20,20],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      },
      {
        "lower":[40,40],
        "upper":[40,50],
        "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      }
    ],

It's not at all obvious. Bounding Boxes have 4x coordinates, not two lines. I'm really not understanding where the terms "lower" and "upper" come from?

W,S + E,N?
S,W + N,E?
MinX,MinY + MaxX,MaxY?
MinY,MinX + MaxY,MaxX?
SW crs-axis1,srs-axis2 + NE crs-axis1,crs-axis2?
Min crs-axis1,srs-axis2 + Max crs-axis1,crs-axis2?
Plus 3D combinations I guess?
(TBC Min,Max is a terrible approach)

IME spatial stuff is confusing enough to many people, without trying to abstract-away 2D+ extents using the same words we use for linear time/temperature/etc ranges.

Additional questions:

Can multiple spatial extents use different CRS'?
Can we have polygon/multipolygon extents (via an extension maybe), or just boxes?
Are 'M' coordinate values filtered via spatial or something else?

cportele · 2018-10-09T10:14:23Z

lower and upper are frequently used. See e.g. ISO 19107, OWS Common, GML, etc. In fact, req 21 also uses lower/upper in the requirement text.

That said, as I mentioned in an earlier comment, I would prefer to keep the current array notation for a bbox, i.e. [10, 10, 20, 20] with the current semantics what lower and upper means.

On the additional questions:

I would say only one CRS for all bboxes.
Sure, there could be an extension. I just wonder, if it is useful for clients to have such detail in the metadata?
I do not understand the question. We discuss only 2D + optional height/depth coordinates. 'M' coordinates are out-of-scope, at least for the Core (and all extensions that have I have seen so far). That is, there are no requirements for server behaviour wrt 'M' coordinates.

m-mohr · 2018-10-10T14:44:15Z

So from my side, I am looking for a way to describe all extents (dimensions) of a collection in a unified way. Best would be to actually make it with lower and upper bounds, optional reference system and optional unit. So that in the end all extents share the same structure, but I do see that this is counter-intuitive for spatial extents.

As far as I understand it, currently it is defined as follows:
spatial extent: [lower x, lower y, optional lower z, upper x, upper y, optional upper z] + crs
temporal extent: [lower datetime, upper datetime] + trs

So the rule you could derive from this is that the first half of the extent describes the lower values and the second half describes the upper values plus a reference system each. All additional extents could share this approach, but it seems spatial extent is under discussion and may need special treatment. So what I'd like to come up with, is a recommendation on how further extents could be specified generally with exceptions for the spatial extent if requested.

So generally (exceptions allowed, e.g. for spatial extents) the fields would be:

lower: Lower bound of the extent
upper: Upper bound of the extent
ref_sys: Optional, reference system if applicable.
uom: Optional, unit of measurement if applicable.

The names, structure and details are to be discussed. I'll just post this here for discussions and inspiration of the basic structure and recommendation to unify things.

Example:

{
  "extent":{
    "spatial": {
      "bbox": [180, -56, -180, 83],
      "ref_sys":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal":{
      "lower": "2015-06-23T00:00:00Z",
      "upper": "2015-06-24T00:00:00Z",
      "ref_sys": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
    },
    "temporal_2":{
      "lower": "2015-06-23T00:00:00Z",
      "upper": "2015-06-24T00:00:00Z",
      "ref_sys": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
    },
    "thermal":{
      "lower": 0,
      "upper": 273.15,
      "uom": "http://www.opengis.net/def/uom/SI/kelvin"
    }
  }
}

pvretano · 2018-10-10T14:49:35Z

@m-mohr the WFS 3.0 core uses "crs" instead of "ref_sys". Are you OK with that?

m-mohr · 2018-10-10T14:55:07Z

Well, crs doesnt work for temporal or other reference systems as the c is in there so you always need to know how the key is named to get reference system information. But that's just my point of view and I may "over-unify" things here. We could say spatial and temporal are exceptions, use crs and trs, and just make a recommendation for all extensions. Would probably be fine, just trying to also show other options and see how WFS people would like to have additional extents added in (from extensions).

pvretano · 2018-10-10T22:16:12Z

@m-mohr For the sake of consistency my preference would be to use lower, upper and ref_sys for spatial and temporal extents and then make recommendations for extensions (i.e use lower, upper and uom for example). However, as @rcoup pointed out, that may confusing to the casual geo-spatial user so perhaps we should stick with whatever is thought to be common practice (i.e. array notation with crs for bbox and lower/upper with trs for temporal).

m-mohr · 2018-10-11T13:38:34Z

I think we can go with exceptions for at least the spatial extent as we already have a representation of the extents in the features, i.e. the GeoJSON bbox. So that should align and therefore should not be confusing to anybody. For all the others lower/upper values will probably make sense. Doesn't really care whether it is a two element array or an object with lower/upper keys.

Regarding reference systems: What other reference systems could there be? Or is it mostly coordinates and time?

As long as there are recommendations for extensions and these are followed as closely as useful for spatial and temporal, I'm fine. We just need to come up with a proposal that answers the questions raised in this issue.

nmtoken · 2018-10-11T14:43:10Z

Regarding reference systems: What other reference systems could there be? Or is it mostly coordinates and time?

Looking at Default Coordinate Reference Systems, from Annex D.4 of the INSPIRE Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007, other than 2D geo spatial coordinates we have CRS for depth and also height and also pressure. If you look at the WMS specification other than geographic, vertical, and temporal coordinate systems we have examples of other coordinate systems that include temperature and wavelength.

…

-----Original Message----- From: Matthias Mohr <notifications@github.com> Sent: 11 October 2018 14:40 To: opengeospatial/WFS_FES <WFS_FES@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [opengeospatial/WFS_FES] extents not easily extensible as the connections to the reference systems are not clear (#168) I think we can go with exceptions for at least the spatial extent as we already have a representation of the extents in the features, i.e. the GeoJSON bbox. So that should align and therefore should not be confusing to anybody. For all the others lower/upper values will probably make sense. Doesn't really care whether it is a two element array or an object with lower/upper keys. Regarding reference systems: What other reference systems could there be? Or is it mostly coordinates and time? As long as there are recommendations for extensions and these are followed as closely as useful for spatial and temporal, I'm fine. We just need to come up with a proposal that answers the questions raised in this issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnU2xYn4QRrtukjTQ-e1-eUq-ZNiPC2ks5uj0omgaJpZM4WzytI> . <https://github.com/notifications/beacon/ABnU21B4ydT2Nm5wr0Ewsxw8YBUHkK3qks5uj0omgaJpZM4WzytI.gif>

________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

________________________________

m-mohr · 2018-11-16T08:55:33Z

We don't have a complete consensus yet. A result I'd like to get from this discussion is that at least we get a recommendation how other extents than spatial and temporal should be described. I'm okay with making exceptions for spatial and maybe temporal extents. Spatial extents are somehow special and should align with the bbox from GeoJSON.

Other than that, I think the keys (spatial, temporal, ...) should just be descriptive (or removed at all) but not determine what type of object it is as this is a problem with two temporal extents for example. More logical would be to determine it by reference system or unit.

Making an exception for space and defining a general rule for all other extents, this could be an example:

{
  "extent":{
    "spatial": {
      "bbox": [180, -56, -180, 83],
      "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal_1":{
      "lower": "2015-06-23T00:00:00Z",
      "upper": "2015-06-24T00:00:00Z",
      "ref_sys": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
    },
    "temporal_2":{
      "lower": "2015-06-23T00:00:00Z",
      "upper": "2015-06-24T00:00:00Z",
      "ref_sys": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
    },
    "thermal":{
      "lower": 0,
      "upper": 273.15,
      "uom": "http://www.opengis.net/def/uom/SI/kelvin"
    }
  }
}

The recommended fields would be:

lower (mixed): Lower bound of the extent
upper (mixed): Upper bound of the extent
ref_sys (string/url): Optional, reference system if applicable.
uom (string/url): Optional, unit of measurement if applicable.

This example to start discussions again as I wish we could reach some consensus for this issue soon.

pvretano · 2019-04-08T14:31:12Z

08-APR-2019: Teleconference notes ... Clemens will create a pull request for this issue. The element of the proposal are (1) Only spatial and temporal extents will be define. (2) Both spatial and temporal extents will be arrays to accommodate extents that closely isolate where the data actually lies. (3) The proposed structure will be some synthesis/extension of the proposals in this issue.

Resolves #168 The text in Core does not have examples for the more complete cases that extensions may use. This would be how an example from the discussion in the issue would be represented: ``` { "extent":{ "spatial": { "bbox": [[180, -56, -180, 83]], "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84" }, "temporal":{ "interval": [["2015-06-23T00:00:00Z", "2015-06-24T00:00:00Z"], ["2015-06-23T00:00:00Z", "2015-06-24T00:00:00Z"]], "trs": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian" }, "thermal":{ "range": [0, 273.15], "uom": "http://www.opengis.net/def/uom/SI/kelvin" } } } ```

Resolves #168 (Extents not easily extensible as the connections to the reference systems are not clear)

m-mohr changed the title ~~extents not easily extensible~~ extents not easily extensible as the connections to the reference systems are not clear Sep 21, 2018

m-mohr mentioned this issue Sep 21, 2018

[WIP] Dimensions extension radiantearth/stac-spec#227

Closed

cportele added the Part 1: Core Issue related to Part 1 - Core label Sep 21, 2018

cportele added this to the Part 1, Second Draft Release milestone Sep 21, 2018

m-mohr mentioned this issue Oct 5, 2018

Create a generic 'dataset' / 'collection' specification, and use that to replace 'root catalog' concept. radiantearth/stac-spec#194

Closed

m-mohr mentioned this issue Oct 8, 2018

Dataset -> Collection radiantearth/stac-spec#260

Closed

m-mohr mentioned this issue Jan 18, 2019

STAC for generic netCDF-type data? radiantearth/stac-spec#366

Closed

cportele added the OGC API: Common Issue related to general resources or requirements (see #190) label Mar 5, 2019

cportele mentioned this issue Apr 11, 2019

Extents not easily extensible as the connections to the reference systems are not clear #168 #196

Merged

cportele added the progress: pull request available label Apr 15, 2019

cportele closed this as completed in #196 May 2, 2019

cportele added a commit that referenced this issue May 2, 2019

Merge pull request #196 from opengeospatial/issue-168

a0e97cb

Resolves #168 (Extents not easily extensible as the connections to the reference systems are not clear)

joanma747 mentioned this issue May 4, 2020

Spatial extent / Temporal interval one vs. multiple array issues, and an interoperable approach to extensibility opengeospatial/ogcapi-common#91

Open

This was referenced Mar 15, 2021

Clarification on multiple bounding boxes in an extent #518

Closed

Clarification on multiple bounding boxes in an extent #519

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

extents not easily extensible as the connections to the reference systems are not clear #168

extents not easily extensible as the connections to the reference systems are not clear #168

m-mohr commented Sep 21, 2018 •

edited

Loading

pvretano commented Sep 21, 2018 •

edited

Loading

m-mohr commented Oct 5, 2018

pvretano commented Oct 5, 2018

rcoup commented Oct 5, 2018

cportele commented Oct 5, 2018

pvretano commented Oct 5, 2018 •

edited

Loading

m-mohr commented Oct 5, 2018 •

edited

Loading

cportele commented Oct 5, 2018

cportele commented Oct 6, 2018

pvretano commented Oct 6, 2018 •

edited

Loading

cportele commented Oct 6, 2018

rcoup commented Oct 8, 2018

cportele commented Oct 9, 2018

rcoup commented Oct 9, 2018

cportele commented Oct 9, 2018

m-mohr commented Oct 10, 2018

pvretano commented Oct 10, 2018

m-mohr commented Oct 10, 2018 •

edited

Loading

pvretano commented Oct 10, 2018

m-mohr commented Oct 11, 2018

nmtoken commented Oct 11, 2018 via email

m-mohr commented Nov 16, 2018

pvretano commented Apr 8, 2019

extents not easily extensible as the connections to the reference systems are not clear #168

extents not easily extensible as the connections to the reference systems are not clear #168

Comments

m-mohr commented Sep 21, 2018 • edited Loading

pvretano commented Sep 21, 2018 • edited Loading

m-mohr commented Oct 5, 2018

pvretano commented Oct 5, 2018

rcoup commented Oct 5, 2018

cportele commented Oct 5, 2018

pvretano commented Oct 5, 2018 • edited Loading

m-mohr commented Oct 5, 2018 • edited Loading

cportele commented Oct 5, 2018

cportele commented Oct 6, 2018

pvretano commented Oct 6, 2018 • edited Loading

cportele commented Oct 6, 2018

rcoup commented Oct 8, 2018

cportele commented Oct 9, 2018

rcoup commented Oct 9, 2018

cportele commented Oct 9, 2018

m-mohr commented Oct 10, 2018

pvretano commented Oct 10, 2018

m-mohr commented Oct 10, 2018 • edited Loading

pvretano commented Oct 10, 2018

m-mohr commented Oct 11, 2018

nmtoken commented Oct 11, 2018 via email

m-mohr commented Nov 16, 2018

pvretano commented Apr 8, 2019

m-mohr commented Sep 21, 2018 •

edited

Loading

pvretano commented Sep 21, 2018 •

edited

Loading

pvretano commented Oct 5, 2018 •

edited

Loading

m-mohr commented Oct 5, 2018 •

edited

Loading

pvretano commented Oct 6, 2018 •

edited

Loading

m-mohr commented Oct 10, 2018 •

edited

Loading