New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to identify the meaning of a time axis? #45

Open
letmaik opened this Issue Jan 26, 2016 · 12 comments

Comments

Projects
None yet
3 participants
@letmaik
Member

letmaik commented Jan 26, 2016

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

This comment has been minimized.

Member

letmaik commented Jun 26, 2016

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

This comment has been minimized.

Member

jonblower commented Jun 27, 2016

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

This comment has been minimized.

Member

letmaik commented Jun 27, 2016

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

This comment has been minimized.

Member

jonblower commented Jun 27, 2016

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

This comment has been minimized.

Member

letmaik commented Jun 27, 2016

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.

@letmaik letmaik added this to the 1.0 milestone Jun 28, 2016

@jonblower

This comment has been minimized.

Member

jonblower commented Jun 30, 2016

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

This comment has been minimized.

Member

letmaik commented Jun 30, 2016

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

This comment has been minimized.

Member

jonblower commented Jul 3, 2016

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

This comment has been minimized.

adamml commented Jul 3, 2016

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" notifications@github.com 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

This comment has been minimized.

adamml commented Jul 3, 2016

Apologies"covjson" and not "Cousin" (replying on Android, and autocorrect
got me there...)
On 3 Jul 2016 21:24, "Adam Leadbetter" aleadbetter9@gmail.com 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" notifications@github.com 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

This comment has been minimized.

Member

jonblower commented Jul 12, 2016

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

@letmaik

This comment has been minimized.

Member

letmaik commented Jul 15, 2016

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>.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment