[Gdal-dev] Recommendations for vertical data in GDAL

[Frank Warmerdam]

Ray Gardener wrote:
> Further to exploring vertical data in GDAL, I went back to basics.
> 
> GDAL basically follows the OpenGIS Grid Coverages spec. This spec has 
> some shortcomings, however:
> 
> - It has a heavy assumption that datasets are color images.
> - It talks a lot about color image processing (filtering, etc.) when
>   this is outside the domain of data access.
> - Elevation data is mentioned but has no explicit band type.
> - The CS_Units type is undefined (it's called "CS_Units" but that's it).
>   So even if linear measure types indicate elevations, there's no way
>   to be sure what to test the unit type ID against.
> - GeoTIFF is highlighted as a well known binary georaster
>   representation. But OGC does not support GeoTIFF completely
>   since GeoTIFF has explicit elevation typing.
> - It has offset/scale attributes which would be presumed used
>   for conversion of elevation data between real units and pixel values.
>   This is erroneous; nothing short of a procedurally definable transform
>   is sufficiently flexible to generally support this conversion. Most
>   HDRI images, e.g., have nonlinear pixel mappings.
> 
> Overall, elevations are mentioned and anticipated, but they are given 
> "lip service" half-defined interfaces.
> 
> So... if we want GDAL to follow OGC (and that is generally a good 
> thing), then OGC needs to be updated (or it needs to finish what it 
> starts). But then I wouldn't expect anything to happen anytime soon, you 
> know how standards bodies are.

Ray,

Good summary!  I don't mind going past the existing grid coverage
specification as needed in GDAL.  But where applicable I do like to
build on it.   I don't forsee much work on grid coverages at OGC
in the near future though I am a bit disconnected from efforts there
these days.  To some extent, well thought out handling of these
issues in GDAL could provide guidance for future standards efforts.
In my opinion standards efforts do best when the peg down established
practice.

On a few specific points:
  o I'm not too keen on encoding procedural relationships between raw
    pixels values and elevation values.  But the "raster attribute table"
    could potentially be used to encode descrete mappings for a limited
    number of pixel values.

  o umm, well, I guess that's the only specific point I'll address today!

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org