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.di...@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 < > browt...@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@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
