Hi Landon,<br>thank for your reply.<br><br>Please, read below...<br><br><div class="gmail_quote">On Thu, May 29, 2008 at 4:54 PM, Sunburned Surveyor <<a href="mailto:sunburned.surveyor@gmail.com">sunburned.surveyor@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Daniele,<br>
<br>
Your problem seems like a complicated one, and I don't know that I<br>
fully understand it. However, it is an interesting problem, and I<br>
wanted to comment on a couple of things that you said in your post<br>
since no one else has responded.<br>
<br>
Daniele wrote: "Basically, it allows to define a wide set of numeric<br>
<div class="Ih2E3d">values for a vertical level.Table 3a provides instead a set of special<br>
levels which allow to define vertical level in terms of "symbolic<br>
entities" like, as an instance, Ground or water surface, Sea Bottom,<br>
Cloud base level, Cloud Top Level and other special elements without<br>
numeric definition."<br>
<br>
</div>It sounds to me like you want to specify different vertical datums,<br>
although they are not vertical datums in the traditional sense.<br>
<br>
Daniele wrote: "How can I handle this special vertical level? (Since,<br>
<div class="Ih2E3d">I need to define<br>
a Vertical CRS... which vertical datum?)"<br>
<br>
</div>I need to understand the context of your question. Are you asking how<br>
to handle the vertical component of your data in a specific program or<br>
application, or are you asking how this might be made to comply with a<br>
certian standard like ISO 19111? </blockquote><div><br>The second one :) <br>Basically, we would like to follow ISO19111 (and ISO19115) specifications when leveraging on and exposing metadata/CRS info of these elements.<br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Daniele wrote: "In the case of a level such as "Cloud Top Level" or<br>
<div class="Ih2E3d">"Cloud Base Level"<br>
is there a special way to define "its position with respect to the<br>
Earth"?"<br>
<br>
</div>You could easily do this with a one-point shift or other formula that<br>
relates each instance of the special vertical datum to the "earth".<br>
For example, how do you get from elevation "zero" on some traditional<br>
vertical datum to your "sea bottom = 0" datum? That would depend on<br>
each site where you were using the special vertical datum, wouldn't<br>
it? So you would end up with a relationship like this:<br>
<br>
(real world elevation of "data point" in the special data set) =<br>
(local elevation of data point in the special data set) + (real world<br>
elevation of sea bottom at this site)</blockquote><div><br>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... <br>
More info afterwards :-)<br><br>Regards,<br>Daniele<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I hope that helps some. Let me know if you produce any Java<br>
classes/interfaces to handle this situation, as I'd be interested in<br>
seeing how you design them.<br>
<br>
The Sunburned Surveyor<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Wed, May 28, 2008 at 10:39 AM, Daniele Romagnoli<br>
<<a href="mailto:daniele.romagnoli@geo-solutions.it">daniele.romagnoli@geo-solutions.it</a>> wrote:<br>
> Hi lists (sorry for cross posting)<br>
><br>
> I'm working on refactoring the multidimensional coverages support in<br>
> imageio-ext (and then I am willing to wrap this for geotools) and<br>
> now I need some help/advice/guidance :)<br>
> Basically we work on top of a class called "SliceDescriptor" (name is<br>
> temporary) which should describe completely a 2d data slice within a<br>
> 5D coverage. As an instance,<br>
> a datasource containing Temperatures measured withing a certain area,<br>
> at various depths ( 50m, 100m, 200m ) each one at 12.00, 15.00, 18.00<br>
> (of TODAY), allows to identify 3x3 == 9 different 2D data slices.<br>
> Hence, a single SliceDescriptor may be referred to a specific 4D<br>
> spatio-temporal "position" within a bigger 4D domain expressed in<br>
> terms of 2D GeographicExtent + Vertical Extent + Temporal Extent (As<br>
> defined in ISO 19115).<br>
> In such a context, Vertical Extent may provide a list of values, or a<br>
> Vertical Range defined by a minimun, a maximum and, optionally, a<br>
> resolution value. Furthermore it should be related to a Vertical CRS.<br>
><br>
> Let's take GRIB1 datasets to better explain my issue.<br>
> GRIB1 data are stored as different records each one containing data<br>
> and additional information contained within a proper GRIB1 section.<br>
> Basically, the Product Definition Section (PDS) of a GRIB1 record<br>
> allows to retrieve information about the represented variable (as an<br>
> instance, Temperature), the geographical area covered by the data, and<br>
> information about the date/time and vertical level/layer for which<br>
> such a data has been collected. This information may be used to<br>
> properly refer the 4D spatio-temporal domain of the coverage (by<br>
> collecting and properly exposing all time/vertical levels information<br>
> available for several GRIB1 records referring to the same Variable).<br>
> The GRIB1 documentation provides information about the available types<br>
> and values of vertical levels.<br>
> (<a href="http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html" target="_blank">http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html</a> )<br>
> Table 3 provides a set of definitions which allow to describe the<br>
> vertical level in terms of, as an instance, height in meters above the<br>
> ground, depth in meters below sea level, isobaric level (pressure in<br>
> Pascals),... Basically, it allows to define a wide set of numeric<br>
> values for a vertical level.Table 3a provides instead a set of special<br>
> levels which allow to define vertical level in terms of "symbolic<br>
> entities" like, as an instance, Ground or water surface, Sea Bottom,<br>
> Cloud base level, Cloud Top Level and other special elements without<br>
> numeric definition.<br>
><br>
> Now my question is:<br>
> How can I handle this special vertical level? (Since, I need to define<br>
> a Vertical CRS... which vertical datum?)<br>
> I'm biased towards not threating them as bands since:<br>
> - Some Variables may have different real bands (as an instance, Wind<br>
> Velocity, having U-component and V-component)<br>
> - Some multi-bands variables may have data for different "special"<br>
> vertical levels (as an instance, Wind velocity at Cloud base level and<br>
> Wind velocity at Cloud top level).<br>
> For this reason, I think mixing "concepts" (bands/vertical levels) is<br>
> not a good solution.<br>
><br>
> Moreover ISO 19111 offers several types of "Vertical Datum"s.<br>
> VerticalDatumType may be "other surface". The CD_VerticalDatum section<br>
> provides as description of the VerticalDatum:<br>
> "A textual description and/or a set of parameters identifying a<br>
> particular reference level surface used as a zero-height or zero-depth<br>
> surface, including its position with respect to the Earth"<br>
> In the case of a level such as "Cloud Top Level" or "Cloud Base Level"<br>
> is there a special way to define "its position with respect to the<br>
> Earth"?<br>
><br>
> Anyway, did someone already encountered a similar "problem"? Any ideas<br>
> about how to handle this case?<br>
><br>
> Thank you very much.<br>
><br>
> Best Regards,<br>
> Daniele<br>
><br>
> --<br>
> -------------------------------------------------------<br>
> Eng. Daniele Romagnoli<br>
> Software Engineer<br>
><br>
> GeoSolutions S.A.S.<br>
> Via Carignoni 51<br>
> 55041 Camaiore (LU)<br>
> Italy<br>
><br>
> phone: +39 0584983027<br>
> fax: +39 0584983027<br>
> mob: +39 328 0559267<br>
><br>
><br>
> <a href="http://www.geo-solutions.it" target="_blank">http://www.geo-solutions.it</a><br>
><br>
> -------------------------------------------------------<br>
><br>
</div></div>> _______________________________________________<br>
> Java-collab mailing list<br>
> <a href="mailto:Java-collab@lists.osgeo.org">Java-collab@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/java-collab" target="_blank">http://lists.osgeo.org/mailman/listinfo/java-collab</a><br>
><br>
><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>-------------------------------------------------------<br>Eng. Daniele Romagnoli <br>Software Engineer<br><br>GeoSolutions S.A.S.<br>Via Carignoni 51<br>55041 Camaiore (LU)<br>
Italy<br><br>phone: +39 0584983027<br>fax: +39 0584983027<br>mob: +39 328 0559267<br><br><br><a href="http://www.geo-solutions.it">http://www.geo-solutions.it</a><br><br>-------------------------------------------------------<br>