[gdal-dev] ENVI Rotation Bug Fix
even.rouault at spatialys.com
Mon Feb 27 14:20:20 PST 2017
On lundi 27 février 2017 14:12:46 CET Brown, Taylor Alexander wrote:
> 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.
> On Mon, Feb 27, 2017 at 5:01 AM, Damian Dixon <damian.dixon at gmail.com>
> > 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  to process georeferenced raster
> >> hyperspectral imagery in ENVI format from NASA's Airborne
> >> Visual/Infrared Imaging Spectrometer (AVIRIS) .
> >> The `map info` section of the header files contain an undocumented 
> >> 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 . It has
> >> previously been described on the GDAL mailing list  and bug tracker
> >> . I believe this issue also affects ASTER imagery .
> >> I have implemented a fix based off of branch `tags/2.1.3` and shared my
> >> code on GitHub . 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 .
> >> 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
> >>  https://github.com/capstone-coal/pycoal
> >>  https://aviris.jpl.nasa.gov/
> >>  http://www.harrisgeospatial.com/docs/enviheaderfiles.html
> >> 
> >> http://gis.stackexchange.com/questions/229952/rotate-envi-hy
> >> perspectral-imagery-with-gdal
> >>  https://lists.osgeo.org/pipermail/gdal-dev/2013-January/035146.html
> >>  https://trac.osgeo.org/gdal/ticket/1778
> >>  http://yceo.yale.edu/opening-aster-files-envi
> >>  http://yceo.yale.edu/faq-page#t2n504
> >> 
> >> https://github.com/OSGeo/gdal/compare/tags/2.1.3...browtayl:
> >> fix-envi-rotation?expand=1
> >>  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
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev