How to identify the meaning of a time axis?

[letmaik]

In forecast data, there are two time dimensions, one for the forecast time and one for the model time. Depending on use cases, one might expose data via two variants of grid coverages:

1. For a fixed forecast time, the model time varies and these are the time steps in the grid coverage.
2. For a fixed model time, the forecast time varies and these are the time steps in the grid coverage.

That means there has to be some metadata to give some kind of meaning to the time values, apart from the fact that they are times (which the reference system would equally assert in both cases). I'm not sure at which level this information should go.

We should discuss this even if it can be implemented in a future CoverageJSON version, just to make sure nothing bad will break.

Related: http://cf-trac.llnl.gov/trac/ticket/117

[letmaik]

Just had an idea on this one. How about adding an optional "concepts" field in the domain for disambiguating/specializing domain components which represent the same basic thing like time:

{
  "type": "Domain",
  "domainType": "Grid",
  "axes": {
    "x": { "start": -179.5, "stop": 179.5, "num": 360 },
    "y": { "start": -89.5, "stop": 89.5, "num": 180 },
    "t": { "values": ["2013-01-13T00:00:00Z","2013-01-14T00:00:00Z"] },
    "tref": { "values": ["2013-01-10T00:00:00Z"] }
  },
  "concepts": {
    "tref": {
      "id": "http://vocab.nerc.ac.uk/standard_name/forecast_reference_time/",
      "label": {
        "en": "Forecast reference time"
      }
    }
  },
  "referencing": [{
    "components": ["x","y"],
    "system": {
      "type": "GeodeticCRS",
      "id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"        
    }
  }, {
    "components": ["t"],
    "system": {
      "type": "TemporalRS",
      "calendar": "Gregorian"
    }
  }, {
    "components": ["tref"],
    "system": {
      "type": "TemporalRS",
      "calendar": "Gregorian"
    }
  }]
}

In this case clients may choose to use the more concrete concept name as UI label (for plot axis labels, dropdown titles etc).

[jonblower]

Since this is effectively referencing information, could it go in the "referencing" object? E.g.

{
    "components": ["tref"],
    "system": {
      "type": "TemporalRS",
      "calendar": "Gregorian"
    },
    "concepts": {
      "id": "http://vocab.nerc.ac.uk/standard_name/forecast_reference_time/",
      "label": {
        "en": "Forecast reference time"
       }
   }
}

or something like that?

[letmaik]

I was thinking about that but the problem is that there can be multiple
components that you reference, and then a single concept is not enough.
But I agree, somehow it belongs in there.

[jonblower]

Would it be useful to have a place to record "concepts" for all of the axes? For example, if someone just wants a title for the axis, or wants to know what sort of axis it is (longitude, geoX etc), they might not want to dereference the CRS object. Maybe this could attach to the axis objects themselves?

[letmaik]

The trouble is always that we don't just have axes, but also components if an axis is made up of tuples etc. So it will be tricky to find a simple structure that goes into the axis objects I think. That's why I had put the "concepts" (or "roles"?) at the same level as referencing so that you can refer to axis as well as component names in a uniform way.
And yes, I also thought about having concepts for just "longitude" etc. but somehow I have a feeling that doing/suggesting this by default blows it up unnecessarily. Not sure.

[jonblower]

Oh yeah, I forgot about the axis/component thing… I don’t think that having a “concept” for longitude should be compulsory, but it could be allowed. I guess there’s a question of consistency with the external CRS database.

[letmaik]

What I don't like about having "longitude" as a concept is that you then
decide to intentionally ignore the actual CRS information, which may say
that it is a spherical or ellipsoidal datum. I know that it doesn't
matter for mapping purposes in most cases anyway, but let's not make it
too dumb... clients should have a certain level of cleverness I think.

[jonblower]

One strength of CF is that it "degrades gracefully" to the case where all you want to do is to create a plot. Hence (nearly) everything in a CF-NetCDF file is spelled out explicitly. If the information about the axes is hidden behind a URI you can't create a sensible plot (with axis labels) without resolving the URI against an internal or external database.

Maybe we could recommend that CRS axes are "spelled out" unless they are one of the very common cases (CRS:84, EPSG:3857 or whatever Web Mercator is). I guess this might belong in "referencing" instead of "concepts".

[adamml]

Just a thought, have you read this

http://link.springer.com/chapter/10.1007%2F978-3-319-15994-2_9

It's be nice if there was some consistency or harmonisation with the NetCDF
and Cousin ideas.

I might be able to find a PDF, but not for a week.
On 3 Jul 2016 21:19, "Jon Blower" [email protected] wrote:

One strength of CF is that it "degrades gracefully" to the case where all
you want to do is to create a plot. Hence (nearly) everything in a
CF-NetCDF file is spelled out explicitly. If the information about the axes
is hidden behind a URI you can't create a sensible plot (with axis labels)
without resolving the URI against an internal or external database.

Maybe we could recommend that CRS axes are "spelled out" unless they are
one of the very common cases (CRS:84, EPSG:3857 or whatever Web Mercator
is). I guess this might belong in "referencing" instead of "concepts".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADNjWwx6vAjBqV7tLpTKPlH242wnbr_xks5qSBlEgaJpZM4HMmeK
.

[adamml]

Apologies"covjson" and not "Cousin" (replying on Android, and autocorrect
got me there...)
On 3 Jul 2016 21:24, "Adam Leadbetter" [email protected] wrote:

Just a thought, have you read this

http://link.springer.com/chapter/10.1007%2F978-3-319-15994-2_9

It's be nice if there was some consistency or harmonisation with the
NetCDF and Cousin ideas.

I might be able to find a PDF, but not for a week.
On 3 Jul 2016 21:19, "Jon Blower" [email protected] wrote:

One strength of CF is that it "degrades gracefully" to the case where all
you want to do is to create a plot. Hence (nearly) everything in a
CF-NetCDF file is spelled out explicitly. If the information about the axes
is hidden behind a URI you can't create a sensible plot (with axis labels)
without resolving the URI against an internal or external database.

Maybe we could recommend that CRS axes are "spelled out" unless they are
one of the very common cases (CRS:84, EPSG:3857 or whatever Web Mercator
is). I guess this might belong in "referencing" instead of "concepts".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADNjWwx6vAjBqV7tLpTKPlH242wnbr_xks5qSBlEgaJpZM4HMmeK
.

[jonblower]

I think @letmaik read that paper - any comment, Maik?

[letmaik]

I've read it, but some of it I find a bit forced, probably resulting from the flat structure requirement of netcdf. For example, it doesn't make any sense to me to attach rdf:value with the latitude etc coordinates to the standard name URI, feels a bit hacky. The same when you attach units to the standard name URI. The units are different for each dataset, only the canonical units are the same for a standard name. So if you actually construct RDF graphs out of that and ingest several netcdf files in some rdf store, then this will be a mess, wouldn't it? I also wonder how all of that is linked to the actual measurement variables (which are then >1D), couldn't find an example for that.

Ignoring all these things, I guess the main idea, associating standard name URIs (or similar) to a variable (or in covjson an axis/component) is the same in both suggested approaches (netCDF-LD and the "concepts" mapping a few comments above). I won't map ad-hoc via JSON-LD, but there's probably not a strong requirement for it to be like that. I think the main question would be: How easy is it to transform a netCDF-LD file to similar constructs in CovJSON? And this shouldn't be too hard I think.

For reference (copied from the paper), this is what the "lat" variable turns into in netCDF-LD:

<http://vocab.nerc.ac.uk/collection/P07/current/CFSN0600/>
a op:ScaledQuantityKind;
qudt:unit unit:DegreeAngle;
dcterms:isPartOf <http://foo.bar/linked_netCDF_example>;
rdf:value "{0, 10, 20, 30, 40, 50, 60, 70, 80, 90}"^^xsd:integer .

(why is the rdf:value an xsd:integer? would be a parse error)

And this is what a variable without standard name turns into:

_:z qudt:unit unit:Meter;
a op:ScaledQuantityKind;
dcterms:isPartOf <http://foo.bar/linked_netCDF_example>.

[letmaik]

Note from the future: it seems this can be added reasonably well in a backwards-compatible way in a future CovJSON version, e.g. with the "concepts" approach.