[Java-collab] Multidimensional coverage and vertical extent

[Daniele Romagnoli]

Hi lists (sorry for cross posting)

I'm working on refactoring the multidimensional coverages support in
imageio-ext  (and then I am willing to wrap this for geotools)  and
now I need some help/advice/guidance :)
Basically we work on top of a class called "SliceDescriptor" (name is
temporary) which should describe completely a 2d data slice within a
5D coverage. As an instance,
a datasource containing Temperatures measured withing a certain area,
at various depths ( 50m, 100m, 200m ) each one at 12.00, 15.00, 18.00
(of TODAY), allows to identify 3x3 == 9 different 2D data slices.
Hence, a single SliceDescriptor may be referred to a specific 4D
spatio-temporal "position" within a bigger 4D domain expressed in
terms of 2D GeographicExtent + Vertical Extent + Temporal Extent (As
defined in ISO 19115).
In such a context, Vertical Extent may provide a list of values, or a
Vertical Range defined by a minimun, a maximum and, optionally, a
resolution value. Furthermore it should be related to a Vertical CRS.

Let's take GRIB1 datasets to better explain my issue.
GRIB1 data are stored as different records each one containing data
and additional information contained within a proper GRIB1 section.
Basically, the Product Definition Section (PDS) of a GRIB1 record
allows to retrieve information about the represented variable (as an
instance, Temperature), the geographical area covered by the data, and
information about the date/time and vertical level/layer for which
such a data has been collected. This information may be used to
properly refer the 4D spatio-temporal domain of the coverage (by
collecting and properly exposing all time/vertical levels information
available for several GRIB1 records referring to the same Variable).
The GRIB1 documentation provides information about the available types
and values of vertical levels.
(http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html )
Table 3 provides a set of definitions which allow to describe the
vertical level in terms of, as an instance, height in meters above the
ground, depth in meters below sea level, isobaric level (pressure in
Pascals),... Basically, it allows to define a wide set of numeric
values for a vertical level.Table 3a provides instead a set of special
levels which allow to define vertical level in terms of "symbolic
entities" like, as an instance, Ground or water surface, Sea Bottom,
Cloud base level, Cloud Top Level and other special elements without
numeric definition.

Now my question is:
How can I handle this special vertical level? (Since, I need to define
a Vertical CRS... which vertical datum?)
I'm biased towards not threating them as bands since:
- Some Variables may have different real bands (as an instance, Wind
Velocity, having U-component and V-component)
- Some multi-bands variables may have data for different "special"
vertical levels (as an instance, Wind velocity at Cloud base level and
Wind velocity at Cloud top level).
For this reason, I think mixing "concepts" (bands/vertical levels) is
not a good solution.

Moreover ISO 19111 offers several types of "Vertical Datum"s.
VerticalDatumType may be "other surface". The CD_VerticalDatum section
provides as description of the VerticalDatum:
"A textual description and/or a set of parameters identifying a
particular reference level surface used as a zero-height or zero-depth
surface, including its position with respect to the Earth"
In the case of a level such as "Cloud Top Level" or "Cloud Base Level"
is there a special way to define "its position with respect to the
Earth"?

Anyway, did someone already encountered a similar "problem"? Any ideas
about how to handle this case?

Thank you very much.

Best Regards,
Daniele

-- 
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267


http://www.geo-solutions.it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/java-collab/attachments/20080528/7de4129f/attachment.html