Ticket #435 (new task)

Opened 13 years ago

Last modified 11 years ago

[M][DS] Phenomenon needs to be fully described (cell methods problem)

Reported by: selatham Owned by: domlowe
Priority: blocker Milestone: NDG3
Component: CSML Version:
Keywords: Cc: awoolf

Description (last modified by selatham) (diff)

see also #464

Change History

comment:1 Changed 13 years ago by selatham

Also affects CSML as well as MOLES.

comment:2 Changed 13 years ago by selatham

  • Owner changed from rkl to domlowe

MOLES strategy agreed. CSML required.

comment:3 Changed 12 years ago by domlowe

  • Owner changed from domlowe to awoolf

Reassigning to Andrew.

comment:4 Changed 12 years ago by awoolf

  • Status changed from new to assigned
  • Milestone changed from System Integration to PROD Step1

Two parts to this - defining 19108 profile for 'climatological reference system' (under preparation), using this within a SWE ConstrainedPhenomenon? definition. Logically the latter is a dictionary entry, practically it is embedded within a particular dataset.

comment:5 Changed 12 years ago by selatham

  • Cc awoolf added
  • Priority changed from required to blocker

This is now a blocker.

comment:6 Changed 12 years ago by rkl

For information this could be addressed by the CF ontology project that is just starting to spin up. The idea I have for this is that the phenomenon will be represented by a URI that is translated by the ontology into a combination of fields. For example, we could have a URI represented by a label 'Maximum 2m temperature', which would translate into standard_name='air_temperature', cell_method='maximum', 'standard_name_value='height=2'. Either the label or (preferably) the URI could be stored as a phenomenon label in the CSML. Problem is timescale as this unlikely to be operational before the end of the year.

In the meantime I would suggest to Andrew to think about a URN-based approach to the phenomenon description with a resolver as part of the CSML API.

comment:7 Changed 12 years ago by lawrence

But from a population point of view we start with netcdf content, which we parse using the parser to produce csml, so the parser needs to be able to start with the cell methods and cell bounds and populate the phenomenon description (which can of course then be mapped to something in an ontology).

comment:8 Changed 12 years ago by lawrence

Another thing to think about in this context. If the cell_methods is populated in netcdf, then what should the gml bounding box be for a grid which is say, from 87.5N to 87.5S in 5 degree intervals, with the cell representing an average? I think the gml bounding box should be 90N to 90S etc ... this may be a parser issue ???? but probably CSML should say something about this for grid series ...

comment:9 Changed 12 years ago by selatham

  • Milestone changed from PROD Step1 to PROD Final

comment:10 Changed 12 years ago by selatham

  • Description modified (diff)

comment:11 Changed 11 years ago by lawrence

  • Owner changed from awoolf to domlowe
  • Status changed from assigned to new
  • Component changed from Vocab to CSML
  • Milestone changed from NDG2 Cleanup to NDG3

This is still very much a live issue, and expected in a version of CSML 2!!!!! That is, we don't expect to wait to CSML3 to see this. Reassigning to Dom as we have a draft that could be implemented now, in anticipation of a final decision implemented in CSML3.

Note: See TracTickets for help on using tickets.