[Java-collab] Multidimensional coverage and vertical extent

Thu May 29 11:40:52 EDT 2008

Hi Landon,
thank for your reply.

Please, read below...

On Thu, May 29, 2008 at 4:54 PM, Sunburned Surveyor <
sunburned.surveyor at gmail.com> wrote:

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

The second one :)
Basically, we would like to follow ISO19111 (and ISO19115) specifications
when leveraging on and exposing metadata/CRS info of these elements.

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 guess I have understood your tip but I'm not sure if I can "easily" apply
it. I need to think a bit more on it :-)... Basically, my Grib datasource
contains Grib records having a PDS which simply states "This record is
defined for a "Top Cloud Level"" without any knowledge about the elevation
of that level, an offset from a reference surface, or something similar.
Moreover I guess I need to know from an external datasource/database, some
elevation data for several different points...
More info afterwards :-)

Regards,
Daniele

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

-- 
-------------------------------------------------------
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/20080529/cc095c52/attachment-0001.html