[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

---------- Forwarded message ----------
Date: Tue, 10 May 2005 12:05:24 -0700
From: Sean Forde <address@hidden>
To: address@hidden, address@hidden, address@hidden
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 <address@hidden> 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.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.