On lundi 27 février 2017 14:12:46 CET Brown, Taylor Alexander wrote: > 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.
M_PI is #define'd in port/cpl_port.h if not already defined. > > > 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 -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
