<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Stephen,<br>
<br>
I've never tried it but the TDS offers apparently WMS services just
as OpenDAP AFAICT (that info is in the web.xml)<br>
Have you tried it?<br>
<br>
Thanks,<br>
Estani<br>
<br>
Am 20.03.2012 12:47, schrieb <a class="moz-txt-link-abbreviated" href="mailto:stephen.pascoe@stfc.ac.uk:">stephen.pascoe@stfc.ac.uk:</a>
<blockquote
cite="mid:4C353E6E4A08AE4792B350DAA392B5212676A6D6@EXCHMBX01.fed.cclrc.ac.uk"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi
Roland,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,
that's very helpful. Separating aggregations into
contiguous portions is completely sensible. I'll roll this
info into the THREDDS spec.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Incidentally,
Marten and I recently prototyped bringing a CMIP5 dataset
into KNMI's WMS visualisation portal that we are using in
our IS-ENES project. This picks up the OPeNDAP aggregation
endpoints and res-serves them as WMS. We managed to get
this working through the ESGF security layer.
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The
repercussions of this are:
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> 1)
down the road there will be visualisation options that don't
rely on explicit declarations in THREDDS ( the visualisation
will read the THREDDS XML and know what to do)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">2)
Marten needs to know how the aggregations are laid-out in
THREDDS and what the subsets are for.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Stephen.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Consolas;color:#1F497D">---<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Consolas;color:#1F497D">Stephen
Pascoe +44 (0)1235 445980<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Consolas;color:#1F497D">Centre
of Environmental Data Archival<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Consolas;color:#1F497D">STFC
Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11
0QX, UK<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> Roland Schweitzer
[<a class="moz-txt-link-freetext" href="mailto:roland.schweitzer@noaa.gov">mailto:roland.schweitzer@noaa.gov</a>]
<br>
<b>Sent:</b> 19 March 2012 14:40<br>
<b>To:</b> Pascoe, Stephen (STFC,RAL,RALSP)<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>; <a class="moz-txt-link-abbreviated" href="mailto:drach1@llnl.gov">drach1@llnl.gov</a>;
<a class="moz-txt-link-abbreviated" href="mailto:plieger@knmi.nl">plieger@knmi.nl</a><br>
<b>Subject:</b> Re: Aggregations and LAS in THREDDS
catalogs<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stephan,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sorry for the delay. I've been away from
the office. I'll do my best here to fill you in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Mar 9, 2012 at 3:14 AM, <<a
moz-do-not-send="true"
href="mailto:stephen.pascoe@stfc.ac.uk">stephen.pascoe@stfc.ac.uk</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
I'd like to understand better why aggregations are
described as they are in ESGF THREDDS catalogs and what
LAS expects from them.<br>
<br>
Modern datanodes have 2 levels of nested dataset elements
describing aggregations. E.g. [1]. In some cases there
are multiple leaf datasets "subset 1" "subset 2" etc.
What's the reason for this? Is it to split the field
into manageable chunks for TDS or LAS?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I believe the reasoning is as
follows. Some data sets have large gaps. For example, a
run might write out data for a period of 100 years, skip
100 years and then write additional data for 100 years.
This makes for challenging user interface issues in LAS
since it expects data to be more or less regular and
contiguous. So, I suggested that the publisher create
separate aggregations where there are these know large
gaps in the data. This will allow LAS to think of these
things as two separate data sets in the UI and thus
guarantee that the UI is presenting only time ranges for
which data exists.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><br>
There are LAS access elements for the dataset at 3
levels of the dataset hierarchy: top-level dataset,
first-level aggregation and "subset" aggregation. Are
all three of these used by LAS?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In the end, no they are not.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Originally LAS would only load the
single variable when that URL of the "subset" was
selected and would load all the variables in the data
set when the top-level URL was selected. I subsequently
changed how the LAS used in the ESGF organized the data
sets internally, so that the "top-level" url is the only
one that matters and it loads all of the variables in
the data set into the interface.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Luca and I were working on this
recently and concluded that the publisher should only
insert the "top-level" LAS URLs. We could in a
subsequent release create URLs at the "subset" level
that would load all of the variable into the interface
and then select that variable as the active variable.
The "first-level" URL seems less useful since we can't
determine which subset the user wants. However, neither
of these last two options seems pressing or necessary
since the search UI does not expose the links to
individual variables.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Roland<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Thanks,<br>
Stephen.<br>
<br>
[1] -----------<br>
<br>
<dataset
name="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation"
ID="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation"
restrictAccess="esg-user"><br>
<property name="aggregation_id"
value="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation"/><br>
<!-- ... --><br>
<access
urlPath="?catid=D9C519D5A310E197819B7197215FD574_ns_cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation"
serviceName="LASatPCMDI9" dataFormat="NetCDF"/><br>
<dataset
name="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation
- Subset 1"
ID="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation.1"
urlPath="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation.1"
restrictAccess="esg-user"><br>
<serviceName>gridded</serviceName><br>
<property name="aggregation_id"
value="cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation.1"/><br>
<property name="time_delta" value="1
month"/><br>
<property name="calendar" value="365_day"/><br>
<property name="start" value="2090-1-1
0:0:0.0"/><br>
<property name="time_length" value="1680"/><br>
<access
urlPath="?catid=D9C519D5A310E197819B7197215FD574_ns_cmip5.output1.INM.inmcm4.1pctCO2.mon.landIce.LImon.r1i1p1.sbl.20110323.aggregation.1"
serviceName="LASatPCMDI9" dataFormat="NetCDF"/><br>
</dataset><br>
</dataset>--<br>
Scanned by iCritical.<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<p>-- <br>
Scanned by iCritical.
</p>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
GO-ESSP-TECH mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
</body>
</html>