[gdal-dev] ENVI Rotation Bug Fix

[Brown, Taylor Alexander]

Damian,

I agree that it would be preferable to use a predefined constant. However,
I was under the impression that M_PI is a compiler extension and not part
of standard C++, so I wanted to make sure it was compatible. If using M_PI
is acceptable, I would be happy to change it. I will be submitting my pull
request shortly.


Taylor

On Mon, Feb 27, 2017 at 5:01 AM, Damian Dixon <damian.dixon at gmail.com>
wrote:

> Hi Taylor,
>
> I'm just lurking on the mailing list myself.
>
> I had a look at the code changes, as this is one of the formats I'm
> interested in, and one point springs out at me:
>
> const double PI = atan(1.0) * 4;
>
> I find this line potentially a confusing way to define PI, particularly
> when you combine it with (PI/180) later.
>
> Personally I would use M_PI.
>
> Regards
> Damian
>
>
>
> On 27 February 2017 at 11:55, Taylor Alexander Brown <
> browtayl at oregonstate.edu> wrote:
>
>> Greetings GDAL Community,
>>
>> I am developing an application [0] to process georeferenced raster
>> hyperspectral imagery in ENVI format from NASA's Airborne
>> Visual/Infrared Imaging Spectrometer (AVIRIS) [1].
>>
>> The `map info` section of the header files contain an undocumented [2]
>> rotation field which is currently ignored by GDAL. As a result, the
>> image is rotated incorrectly when I process it with `gdalwarp` or the
>> GDAL Python API. Furthermore, the image is scaled incorrectly when I try
>> to override the geotransform.
>>
>> I documented my experiences on the GIS Stack Exchange [3]. It has
>> previously been described on the GDAL mailing list [4] and bug tracker
>> [5]. I believe this issue also affects ASTER imagery [6][7].
>>
>> I have implemented a fix based off of branch `tags/2.1.3` and shared my
>> code on GitHub [8]. It reads the `units` and `rotation` parameter from
>> the `map info` section and uses these to calculate the geotransform. The
>> scaling was off because the code expected the `units` parameter to be
>> the last element in the list, when in my case it was the second to last.
>> You can verify this behavior with the single-band image I have been
>> using for testing [9].
>>
>> You are welcome to evaluate my code and contribute it back to the
>> library. I am a novice at both GDAL and GIS, so there may well be
>> problems. I would be willing to submit a pull request against your
>> GitHub mirror if desired.
>>
>>
>> Peace,
>>
>> Taylor Alexander Brown
>>
>>
>> [0] https://github.com/capstone-coal/pycoal
>> [1] https://aviris.jpl.nasa.gov/
>> [2] http://www.harrisgeospatial.com/docs/enviheaderfiles.html
>> [3]
>> http://gis.stackexchange.com/questions/229952/rotate-envi-hy
>> perspectral-imagery-with-gdal
>> [4] https://lists.osgeo.org/pipermail/gdal-dev/2013-January/035146.html
>> [5] https://trac.osgeo.org/gdal/ticket/1778
>> [6] http://yceo.yale.edu/opening-aster-files-envi
>> [7] http://yceo.yale.edu/faq-page#t2n504
>> [8]
>> https://github.com/OSGeo/gdal/compare/tags/2.1.3...browtayl:
>> fix-envi-rotation?expand=1
>> [9] https://drive.google.com/open?id=0BxysdOuBmaIGalY5dVhCa1Y5M0k
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170227/b788e0e6/attachment.html>