NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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.
galeon archives: