Add "bbox" and "temporal" metadata

[letmaik]

I'm not sure if the specification should define something like "bbox" or "temporalExtent" etc fields since this gets complex pretty quickly (should it be in CRS84? or domain CRS? does bbox only apply to x and y axes? what if identifiers are used in new domain types? same for temporal and vertical?). But since it is possible to reference the domain by a URL, it would be good to include some metadata, especially for domains with potentially a lot of data volume like trajectories. Since we support more than basic CRS84/ISO8601/height above WGS84 I'm not sure how to model that generically.

[jonblower]

I think a bbox field in CRS84 is useful. It doesn't have to be an exact bbox, as long as all the data are contained within it (so a bbox that covers the world would be OK, if not very helpful).

A summary of temporal extent would also be good. This should be in the Gregorian calendar if possible, but if not it could be in the "native" calendar of the data. (We might have to be aware that some simple clients might assume Gregorian even if we say otherwise.)

I'm not sure that we need to summarise vertical extent in this way.

[letmaik]

Can we make the bbox field not fixed to CRS84 but saying it should be CRS84 and requiring an srs URI?

"bbox": {
  "box": [1,2,3,4],
  "srs": "http://.../CRS84"
}

Then it would fit more to the temporal extent:

"temporal": {
  "start": "2012-01-01T00:00:00Z",
  "end": "2015-01-01T00:00:00Z",
  "trs": "xsd:dateTime"
}

"temporal": {
  "start": "1000-01-01T00:00:00Z",
  "end": "1001-01-01T00:00:00Z",
  "trs": {
    "calendar": "Julian"
  }
}

Something like that.

[jonblower]

Yes, I don't see why not. I think applications would have to have a good reason for not using CRS84, since I think the point of this is to help catalogue searches and quick-views.

[letmaik]

I think we should rethink this.

• The bbox property in GeoJSON implicitly uses the same CRS as the geometry.
• The bbox property in GeoJSON represents tight bounds around the geometry coordinates.

These two properties make bounding boxes way more useful than defining them as loose as we have now. I haven't used the CovJSON bbox field at all since it doesn't give me any guarantees. But if it was essentially the actual spatial domain extent then this could be used for processing purposes as well.

I don't see that much value in having a bbox purely for discovery purposes, since this should be handled at a different level I think (DCAT metadata, CKAN etc.). I think CoverageJSON (or any coverage data format) should first of all be an accurate representation of the data. Once you're down at the level of CoverageJSON then you have to understand the used CRS anyway to make any use of the rest.

I guess then the real question to ask is, do we need bbox at all since it is restricted to a certain subset of the domain dimensions? Would it be more useful to just define dimension (not axis!) extents in general for arbitrary dimensions which have an ordering? This would live outside the domain (maybe "domainExtent") and would require referencing info to be defined outside as well, which may not be a bad idea. Then it would also be straight-forward to automatically transform such extents in case a coverage is reprojected, subsetted, etc. Or in general, just be able to derive the extents unambiguously client-side from the domain if they are not included.

[letmaik]

By the way, CIS also defines an "envelope" (CIS::EnvelopeByAxis) which for each CRS axis defines the lower and upper bound, independent of how the domain is organized.
EDIT: But of course for a point collection spanning the date line the axis extent would span nearly the whole world if this is really just the min/max and assuming the longitudes for the points stay in [-180,180]. In GeoJSON, the bbox would still be tight as it requires minx > maxx for that case.

[jonblower]

I tend to agree that we probably don't need a bbox property. Do we need a "domainExtent"? Not sure - if this can be easily calculated from the full domain definition then it would seem redundant (and hence a possible source of inconsistency) to have this as a separate property.

[letmaik]

I would say we leave it out then (both bbox and temporal) until we have some concrete use cases where it would be necessary or advantegous to have it.

[letmaik]

Just thought of a potential use case, which is curvilinear grids. For those, the domain could be quite big in terms of data volume. Having domain extents / envelope outside the domain could then be beneficial for API-based subsetting or resampling/reprojecting without loading the domain. I'm not sure though how that would work in detail in practice. However, since we postponed curvilinear grids, both features could be added at the same time in a future version. And as both are additions, I don't see any problems there.

[jonblower]

This is basically what happens in WMS. In WMS the client doesn't load the domain (except its extent). It's hard to know exactly how subsetting might work in that case in a controlled fashion, unless the client doesn't care about the exact method used for resampling or interpolation.

[letmaik]

Out of scope since it can always be easily computed from the domain itself. One use case mentioned above were curvilinear grids but since those are definitely out of scope now (see #32), this issue is a non-issue.