[Geoserver-devel] Multidimensional coverage and vertical extent

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 :slight_smile:
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


Daniele Romagnoli a écrit :

How can I handle this special vertical level? (Since, I need to define
a Vertical CRS... which vertical datum?)

For stuff like "depth in meters below sea level" and "isobaric level", there is existing VerticalDatumType that can be used for creating VerticalDatum instances:

http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#DEPTH

For heights relative to cloud level, an application needs to defines new VerticalDatumType using the static valueOf(String) method.

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"?

Not at this time. ISO 19111 do not suggests any programmatic way, only textual way, probably because the relationship is often quite complex. For example defining the position of VerticalDatumType.GEOIDAL with respect to VerticalDatumType.ELLIPSOIDAL is the subject of a whole GeoTools module on its own: modules/unsupported/referencing3D.

GeoTools referencing module lacks a way to plugin vertical transformations at this time.

  Martin

Hi Martin,

On Fri, May 30, 2008 at 1:14 PM, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

Daniele Romagnoli a écrit :

How can I handle this special vertical level? (Since, I need to define
a Vertical CRS… which vertical datum?)

For stuff like “depth in meters below sea level” and “isobaric level”, there is
existing VerticalDatumType that can be used for creating VerticalDatum instances:

http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#DEPTH

Yes, I noticed that. But in these specials GRIB records there is no knowledge about an “offset” from a reference level.

For heights relative to cloud level, an application needs to defines new
VerticalDatumType using the static valueOf(String) method.

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”?

Not at this time. ISO 19111 do not suggests any programmatic way, only textual
way, probably because the relationship is often quite complex. For example
defining the position of VerticalDatumType.GEOIDAL with respect to
VerticalDatumType.ELLIPSOIDAL is the subject of a whole GeoTools module on its
own: modules/unsupported/referencing3D.

Yeah, I looked at this on the nice VerticalTransform class + its subclass :slight_smile:

GeoTools referencing module lacks a way to plugin vertical transformations at
this time.

Martin

Daniele


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Geotools-devel mailing list
Geotools-devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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