RE: [GMLJP2] NetCDF <--> GML/JPEG2000 (fwd)

• To: bit-bucket <bit-bucket@xxxxxxxxxxxxxxxx>
• Subject: RE: [GMLJP2] NetCDF <--> GML/JPEG2000 (fwd)
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Tue, 10 May 2005 13:21:45 -0600 (MDT)

==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================

---------- Forwarded message ----------
Date: Tue, 10 May 2005 12:05:24 -0700
From: Sean Forde <sforde@xxxxxxxxxxxxxx>
To: caron@xxxxxxxxxxxxxxxx, galeon@xxxxxxxxxxxxxxxx, gmljp2@xxxxxxxxxxx
Subject: RE: [GMLJP2] NetCDF <--> GML/JPEG2000

John,

Well, its been a week and there have been no takers on these questions, so I 
will weigh in with my answers and ask you a few questions. My comments are 
below. First a question.

[SPF:] What sorts of relationships do you need to define between various 
coverages? How do you express them in GML? The current state of the 
GML/JPEG2000 spec mandates that the GML instance has the following structure:

        <FeatureCollection>
                <FeatureCollection>
                        <RectifiedGridCoverage>
                                <!-- this coverage is for a particular JP2 
codestream -->
                        </RectifiedGridCoverage>
                        <!--    other features and metadata associated
                                with that coverage can go here -->
                </FeatureCollection>
                <FeatureCollection>
                        <RectifiedGridCoverage>
                                <!-- this coverage is for a particular JP2 
codestream -->
                        </RectifiedGridCoverage>
                        <!--    other features and metadata associated
                                with that coverage can go here -->
                </FeatureCollection>
                ...
        <FeatureCollection>

Does this structure accomodate the needs of netCDF?


[SPF:] I hope that we can make sure that the GML/JPEG2000 specification can 
accomodate the netCDF community. In particular, I would ask members of the 
GML/JPEG2000 list to comment on some of the questions raised below.

[SPF:] NOTE: I have edited a bit for readability. Thus far, Frank W's comments 
are prefixed by [FW:],John Caron's by [JC:], mine by [SPF:]

> > On 4/12/05, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:
> > > [JC:]    1.  scientific data is typically 4D, so the client
> must know how to
> > > handle a vertical and time dimension, as well as the usual 2D
> > > horizontal. The vertical layers  and time series are the main
> > > relationships we'd like to express with multiple "images".
> >
> > [FW:] I think that the GML coverage description approach has very good
> > tools to describe addiitional dimensions, including unusual
> dimensions
> > like pressure and geopotential height.  However, I think some
> > conventions on how this should be done still need to be prepared
> > to ensure respectible interoperability.
> >


> > > [JC:]    2. the vertical dimension is often not height, more
> like pressure or
> > > "geopotential height" that can be approximately mapped to height.


> > >  [JC:]   3. We would generally prefer  to transfer the
> floating point data
> > > values as close as possible to what they are in the file,
> and let the
> > > client assign false color maps. It would be nice if the
> scientific user
> > > who is using a GIS package could access the underlying
> data values. Is
> > > that possible in JPEG2000?
> >
> > [FW:] My understanding is that internally JPEG2000 data streams
> > are integers with potentially up to 31 bits of precision
> (not exactly
> > sure about this part), so any floating point data would
> inevitably need
> > to be scaled.
> >
[SPF:] JPEG20000 is indeed integer based. There are plans to introduce floating 
point in the future, but it will be some years


> > >  [JC:]   4. The horizontal grid is not always evenly spaced in
> scientific
> > > data. I realize that resampling is an important service,
> but  it would
> > > also be useful to show the data in its native resolution. Is that
> > > possible in JPEG2000?
> >
> > [FW:] I don't think there is any standard approach to describing
> this in GML
> > coverage descriptions.  Would you essentially transmit along
> > geolocation layers (lat and long) as is done with some NASA HDF
> > products?  A set of GCPs?
> >


> > > [JC:] I wonder if you have any thoughts on the
> suitability/limitations of "GML
> > > in JPEG2000" with respect to these issues? GML still
> seems a bit green;
> > > do you think its ready for full production use? Is the
> OGC ready to add
> > > JPEG2000 to its list of WCS formats?
> >
> > [FW:] I would add that the description of user defined coordinate systems
> > (using standard projection methods like transverse mercator, but
> > custom parameters) has not yet really been addressed in the GML-in-
> > jpeg2000 IE though we hope to.  In that sense, the coordinate system
> > aspect of gmljp2 is still quite "green".
> >
> > I would add that one approach is encoding your entire dataset in
> > JPEG2000 with a GML coverage description embedded.  Another
> > might be to use the "same" GML coverage description but embedding
> > it in a netCDF attribute, and come up with a specification for a URN
> > format to refer to specific variables and dimensions in the netCDF
> > file.