[Java-collab] Multidimensional coverage and vertical extent

[Sunburned Surveyor]

Daniele,

Your problem seems like a complicated one, and I don't know that I
fully understand it. However, it is an interesting problem, and I
wanted to comment on a couple of things that you said in your post
since no one else has responded.

Daniele wrote: "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."

It sounds to me like you want to specify different vertical datums,
although they are not vertical datums in the traditional sense.

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

I need to understand the context of your question. Are you asking how
to handle the vertical component of your data in a specific program or
application, or are you asking how this might be made to comply with a
certian standard like ISO 19111? I would point out that trying to get
a solution to a unique domain problem like this might be like trying
to get a square peg in a round hole.

Daniele wrote: "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"?"

You could easily do this with a one-point shift or other formula that
relates each instance of the special vertical datum to the "earth".
For example, how do you get from elevation "zero" on some traditional
vertical datum to your "sea bottom = 0" datum? That would depend on
each site where you were using the special vertical datum, wouldn't
it? So you would end up with a relationship like this:

(real world elevation of "data point" in the special data set) =
(local elevation of data point in the special data set) + (real world
elevation of sea bottom at this site)

I hope that helps some. Let me know if you produce any Java
classes/interfaces to handle this situation, as I'd be interested in
seeing how you design them.

The Sunburned Surveyor


On Wed, May 28, 2008 at 10:39 AM, Daniele Romagnoli
<daniele.romagnoli at geo-solutions.it> wrote:
> 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
>
> -------------------------------------------------------
>
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab
>
>