commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Lucas (Jira)" <j...@apache.org>
Subject [jira] [Updated] (IMAGING-266) Read integer data from GeoTIFFS
Date Tue, 22 Sep 2020 09:29:00 GMT

     [ https://issues.apache.org/jira/browse/IMAGING-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Lucas updated IMAGING-266:
-------------------------------
    Description: 
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|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. 

 

 

  was:
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|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. 

 

 


> 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
>            Priority: Major
>
> 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|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)

Mime
View raw message