[Go-essp-tech] Extending the DRS syntax to observations
Steve Hankin
Steven.C.Hankin at noaa.gov
Mon Jan 31 11:20:56 MST 2011
Hi Luca,
Just below is a version of your email of this morning which has minor
editorial changes (*in red*) to reflect a broader outlook on the term
"observations", and an initial proposal for gridded /in situ/
observations. I think if we adopt language like this we will be glad
of it in the long term:
- Steve
*Open Questions*
* Agree on basic DRS-like structure for observations and meaning
of each field
o Use activity="cmip5" or activity="cmip54obs", "obs4models" ?
o DRS hierarchy for models (partial): "institute" >
"model" > "experiment" > "ensemble"
o Current proposed hierarchy for *gridded* *remote sensed*
observations (partial): "institute" (="agency") >
"mission" > "instrument" > ("processing level" + "other
specifiers")
o Alternative proposal for *gridded remote sensed*
observations (partial): "institute" (="agency") >
"instrument" > "processing level" > ?
o Need a proposal for *gridded in situ observations*,
say: "institute" (="agency") > "program" >
"resolution"> "variant" ?
+ e.g. NOAA/NCAR / ICOADS / 1degree / equatorial /
o Should we even attempt to describe in situ (point and
trajectory) observations through DRS? (can we succeed
at this?)
* Decide on whether to have one single CMOR table for
observations (currently "obsSites"), or more than one
depending on types of observational data:
o remote sensed (grids and swaths)
o in-situ stations (time series and profiles)
o trajectory-based observations
o in-situ gridded products
* Decide on whether to encode global attributes for data source
in netcdf files ("source", "source_datastream", "source_url",
"source_reference")
*Action Items*
* Populate CV for observations (decide on upper/lower case)
* Produce some reference datasets
* Develop snippet of "esg.ini" (ESG publisher) configuration for
processing observations
On 1/31/2011 6:58 AM, Cinquini, Luca (3880) wrote:
> Hi all,
> thanks to everybody for the lively discussion... I just wanted to
> summarize what I think is the status so far - I posted this also on
> the wiki. Please keep the discussion going...
> thanks, Luca
>
> *Open Questions*
>
> * Agree on basic DRS-like structure for observations and meaning
> of each field
> o Use activity="cmip5" or activity="cmip54obs", "obs4models" ?
> o DRS hierarchy for models (partial): "institute" > "model"
> > "experiment" > "ensemble"
> o Current proposed hierarchy for observations (partial):
> "institute" (="agency") > "mission" > "instrument" >
> ("processing level" + "other specifiers")
> o Alternative proposal for observations
> (partial): "institute" (="agency") > "instrument" >
> "processing level" > ?
> * Decide on wether to have one single CMOR table for observations
> (currently "obsSites"), or more than one depending on types of
> observational data:
> o remote sensed (grids and swaths)
> o in-situ stations (time series and profiles)
> o trajectory-based observations
> o in-situ gridded products
> * Decide on wether to encode global attributes for data source in
> netcdf files ("source", "source_datastream", "source_url",
> "source_reference")
>
> *Action Items*
>
> * Populate CV for observations (decide on upper/lower case)
> * Produce some reference datasets
> * Develop snippet of "esg.ini" (ESG publisher) configuration for
> processing observations
>
>
> On Jan 31, 2011, at 2:42 AM, Bryan Lawrence wrote:
>
>>
>> Hi Folks
>>
>> Sorry I've come late to this discussion.
>>
>> I've got just two simple points to make (for now).
>>
>> Firstly, I think this activity (organising observational data to support
>> CMIP5) is not the same as cmip5 itself. Sooner or later things break in
>> the DRS heirarchy doing this, and so I think it would be helpful to all
>> consumers if this was dealt with at the top level of the DRS.
>> Additionally, remember obs are timeless, models are not. This data will
>> be useful beyond cmip5 (e.g. cordex). So I recommend *not* shoehorning
>> all the obs data under cmip5 in the DRS.
>>
>> The DRS allows you to define new activiites, and I'd do so, something
>> like obs4models or (if you must) cmip5obs ....
>>
>> Otherwise I'm fine with the approach.
>>
>> Secondly, wrt to Steve's list below: there is of course swath data as
>> well ... but otherwise I rather agree that 3 and 1 can be handled the
>> same.
>>
>> Cheers
>> Bryan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110131/3ccbb1e9/attachment-0001.html
More information about the GO-ESSP-TECH
mailing list