Re: [galeon] [WCS-1.2.swg] Forecast times and dimensionality (domain axes)

• To: Ethan Davis <edavis@xxxxxxxxxxxxxxxx>
• Subject: Re: [galeon] [WCS-1.2.swg] Forecast times and dimensionality (domain axes)
• From: Ben Domenico <Ben@xxxxxxxxxxxxxxxx>
• Date: Fri, 27 Mar 2009 19:23:10 -0600

Hi Ethan and Wenli,
When we get a chance, it would be good to turn your valuable email exchange
into a use case document for having two time dimensions.  This is really a
practical description of how datasets with two time dimensions are now being
served to the community.

I hope someone will help me remember this after the OGC TC meetings.'

Thanks.

-- Ben

On Fri, Mar 27, 2009 at 4:02 PM, Ethan Davis <edavis@xxxxxxxxxxxxxxxx>wrote:

> Hi Wenli,
>
> Yang, Wenli (GSFC-610.2)[GEORGE MASON UNIVERSITY] wrote:
> > Ethan,
> >
> > John's poster is very nice.  As to the 5D cubes, it looks like
> > they are conceptual rather than true 5D data arrays. If both
> > t1 and t2 are treated as independent dimensions in a 5D data
> > array, you'll have no-value cells at the bellow the diagonal
> > line in the (t1,t2) plane unless you include hindcast/nowcast
> > results in the data model.  The poster actually shows that no
> > data are available at the lower left part of the 2D (i.e.,
> > model run versus forecast time) plane.
>
> They are somewhat sparse arrays but they are not just conceptual. Here
> is an OPeNDAP data descriptor URL for one of the 5D cubes:
>
>
> http://motherlode.ucar.edu:8080/thredds/dodsC/fmrc/NCEP/GFS/Alaska_191km/NCEP-GFS-Alaska_191km_fmrc.ncd.dds
>
> All of of the data variables (coverage fields) have two time dimensions,
> "run" and "time" (or "time1"). Many, like Temperature, are 5D cubes
> though some, like Pressure, don't have a vertical dimension
>
>  Temperature[run = 243][time = 21][isobaric1 = 9][y = 39][x = 45]
>  Pressure[run = 243][time = 21][y = 39][x = 45]
>
> Because the arrays are somewhat sparse, a particular subset of the data
> may return lots of "missing values" (or NaNs).
>
> Note: We don't support WCS requests on the 5D cube but most (all?) of
> the slices do.
>
> > I also obtained a netCDF file using the netcdfsubset link,
> > with u_wind be subsetted.  The file contains a 3D (x,y,t)
> > array instead of 4D (x,y,t1,t2) array.  One of the time
> > dimension, model run, is apparently indicated by the file
> > name, i.e., NCEP-GFS-Alaska_191km_RUN_2009-03-25T12_00_00Z.nc.
>
> That is right, the data you got was from the set (one for each model
> run) of "Forecast Model Run" 4D slice datasets. This one for the 12Z run
> on the 25th.
>
> If you go up one level in the catalogs to
>
>
> http://motherlode.ucar.edu:8080/thredds/catalog/fmrc/NCEP/GFS/Alaska_191km/catalog.html
>
> and follow the "Forecast Model Run Collection (2D time coordinates)"
> link you will get to the full 5D cube. The next four links all lead to a
> single slice ("Best Time Series") or a collection of slices ("Forecast
> Model Run", "Constant Forecast Offset", and "Constant Forecast Date")
> through the 5D cube. The last link leads to the collection of underlying
> data files ("File Access").
>
> > In WCS, if you define a grid having a 5D CRS (x,y,z,t1,t2),
> > with dimension sizes being Nx,Ny,Nx,Nt1,Nt2.  A client expects
> > the returned grid to have Nx * Ny * Nx * Nt1 * Nt2 gird point
> > values, assuming no subsetting and resampling, unless the server
> > outputs multiple files (or one file with multiple variables)
> > each representing one specific time for one of the time dimension
> > (say, t1) and containing a 4D data array (say, x,y,z,t2).  In
> > this case, the server can avoid no-value points if the sizes of
> > the t2 dimension in different arrays are allowed to be different,
> > e.g., the dimension size in the first array being Nt2, in the 2nd
> > array being Nt2-1, in the 3rd array being Nt2-2, etc.
>
> That sounds correct. Though in that case, how would the server describe
> how the individual files in the response fit together. The client would
> have to do some work both to 1) understand that they aren't getting back
> all the data they requested and 2) understand how the pieces fit
> together and then fit them back together.
>
> Ethan
>
>
> > Wenli
> >
> > ________________________________________
> > From: Ethan Davis [edavis@xxxxxxxxxxxxxxxx]
> > Sent: Wednesday, March 25, 2009 11:35 AM
> > To: Yang, Wenli (GSFC-610.2)[GEORGE MASON UNIVERSITY]
> > Cc: wcs-1.2.swg@xxxxxxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [WCS-1.2.swg] Forecast times and dimensionality (domain
> axes)
> >
> > Hi all,
> >
> > Just thought I'd throw in an example where we use x/y/z/t1/t2 data.
> >
> > We serve a lot of forecast model data and John Caron has done a lot of
> > work to aggregate the data into 5D (2 time) cubes and then provide
> > various 4D slices through the 5D cube. The reason for the slices is to
> > allow tools that can't deal with a 5D(w/2t) cube to conveniently
> > interact with the data in various ways.
> >
> > Anyway, John put together a nice poster showing the "cube" and the
> > slices that I thought might be interesting input for this conversation.
> > Here's the link:
> >
> > http://www.unidata.ucar.edu/staff/caron/presentations/FmrcPoster.pdf
> >
> > Each slice is useful in a different way. For instance, the "Model Run"
> > slice is the traditional view for looking at forecasts. The "Constant
> > Valid Time" slice is useful for watching the evolution of the model
> > forecast as the forecast time gets closer.
> >
> > Also, in case anyone wants to look at some data, here is a link to all
> > the model data we serve
> >
> > http://motherlode.ucar.edu:8080/thredds/idd/models.html
> >
> > Each link leads to a 5D(w/2t) cube and the various slices.
> >
> > Ethan
>
>
>
> _______________________________________________
> WCS-1.2.swg mailing list
> WCS-1.2.swg@xxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.opengeospatial.org/mailman/listinfo/wcs-1.2.swg
>
>

• Follow-Ups:
  • Re: [galeon] [WCS-1.2.swg] Forecast times and dimensionality (domain axes)
    • From: Yang, Wenli (GSFC-610.2)[GEORGE MASON UNIVERSITY]