This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
=============================================================================== 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.