Gary Lucas created IMAGING-266:
----------------------------------
Summary: Read integer data from GeoTIFFS
Key: IMAGING-266
URL: https://issues.apache.org/jira/browse/IMAGING-266
Project: Commons Imaging
Issue Type: New Feature
Components: Format: TIFF
Affects Versions: 1.0-alpha3
Reporter: Gary Lucas
I recently discovered that there is a large amount of digital elevation data
available in the form of 16-bit integer coded data in GeoTIFF files (TIFF files
with geographic tags). I propose to enhance the Commons Imaging API to read
these files. This work will be similar to the work I did for reading
floating-point raster data under ISSUE-251.
Available data include the nearly-global coverage of one-second of arc
elevation data produced from the Shuttle Radar Topography Mission (SRTM) and
other sources. These products give grids of elevation data with a 30 meter cell
spacing for most of the world's land masses. They are available at NASA
Earthdata and Japan Space Systems websites, see
[https://asterweb.jpl.nasa.gov/gdem.asp.] There is also a ocean bathymetry data
set available in this format at [http://www.shadedrelief.com/blue-earth/]
This new feature will continue to expand the usefulness of the Commons Imaging
API in accessing GeoTIFF products.
Request for Feedback
So far, the data products I've found (ASTER and Blue Earth Bathymetry) give
elevation and ocean depth data in meters recorded as a short integer. I
haven't found an example of where the 32-bit integer format is used. For now,
I am planning on only coding the 16-bit integer variation. Does anyone know if
the 32-bit version is worth supporting? My criteria for determining that would
be based on whether there is a significant number of projects using that format
(life is too short to chase rarely used data formats).
Currently, one of the code-analysis operations conducted by the Commons Imaging
build process is coverage by JUnit tests. Lacking any test data for the 32-bit
case, I am reluctant to include it in the code base because it would mean
putting uncovered code into the distribution.
Also, I am wondering about the best design for the access API. The current
TiffImageParser class has a method called getFloatingPointRasterData() that
returns an instance of TiffRasterData. TiffRasterData is pretty much
hard-wired to floating point data. I am thinking of creating a new method
called getIntegerRasterData() that would return an instance of a new class
called TiffIntegerRasterData. Does this seem reasonable? I considered trying
to combine both kinds of results into a unified class and method, but it seems
more unwieldy than useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
