[
https://issues.apache.org/jira/browse/IMAGING-266?focusedWorklogId=649642&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649642
]
ASF GitHub Bot logged work on IMAGING-266:
------------------------------------------
Author: ASF GitHub Bot
Created on: 11/Sep/21 23:48
Start Date: 11/Sep/21 23:48
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #165:
URL: https://github.com/apache/commons-imaging/pull/165#issuecomment-917504233
@gwlucastrig here's what I've done in the last commit.
1. Renamed `scansize` to `scanSize` in `ImageDataReader.java`
2. `git commit -am 'f'` (just so I know I need to squash it)
3. `git rebase -i HEAD~2` and I replace `pick f` by `f f`
4. Added an entry in `changes.xml`. This file is used to generate the
changelog and in the site and in the `RELEASE-NOTES.txt` file (I think,
although can't recall if we use JIRA export tool in release process?). I added
an entry with myself as dev, and you as due-to. The dev is always an ASF
committer, and due-to the person responsible for work (it's not always
present). I didn't put your user as dev as you are still not a committer (only
pending you accept & submit the form :)
5. Pushed force a commit with the squashed commit and the `changes.xml` (I
can push to your branch as you allowed it when creating the PR)
6. Waited for CI to confirm I didn't mess it up, then merged the PR
7. Updated the JIRA (fix version, status, etc).
This is the whole process for a ticket in Imaging, but applies to pretty
much every Apache Commons projects too.
Cheers
Bruno
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 649642)
Time Spent: 5h 10m (was: 5h)
> 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
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> 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)
