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

[m-mohr]

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.

[pvretano]

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]

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]

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

[rcoup]

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

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]

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

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]

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

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]

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