To follow-up on my latest email, I confirmed that GDAL is interpreting the
pixels in the augmented image file from Octave as uint16 rather than int16,
and this results in incorrect elevation values after cubic interpolation
and subsampling (e.g., a pixel elevation of -28 m is misinterpreted as
65,5
Hi,
I've written a post summarizing various enhancements done in trunk
lately regarding GDAL and cloud storage:
https://erouault.blogspot.fr/2017/10/gdal-and-cloud-storage.html
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
__
Thanks Joaquim and Even,
Per my email I augmented the original GLOBE image and created a properly
referenced image using gdal_translate as follows: I did an imread from
QGIS/GDAL into Octave, added the appropriate 24 rows and columns on each
side, and did an imwrite back to QGIS/GDAL to continue p
Hi,
I propose to remove the raster OGDI driver from trunk (the vector OGDI driver
is
still useful for VMAP/VPF/DCW)
There should be no reason to use it anymore since GDAL supports out of the box
(and probably in a more efficient way) all the raster formats the OGDI bridge
offers: ADRG, DTED a
