[gdal-dev] decimal truncation when gdal_translate/gdalwarp

[Hare, Trent]

Ramiro,
  I believe all 16bit LOLA DEMs have a scale in the header of 0.5 (they do
release 32bit files also). Check to make sure the scale parameter exists
using gdalinfo. To apply this value during conversion you have be explicit
and specify "-ot Float32" AND "-unscale". So something like this.

> gdal_translate -ot Float32 -unscale in_16bit.lbl out_32bit.tif
If you are converting the Jpeg2000 files, and you don't see this scale, you
also need to download the GDAL *.xml file within the LOLA archive and
rename. They were not allow to archive with more than one extension (silly
constraint for this day-and-age). For example for their geoJpeg2000s:

first rename:
> mv ldem_85n_10m_aux.xml ldem_85n_10m.jp2.aux.xml
now convert to 32bit Tiff (please see tip below):
> gdal_translate -ot Float32
-unscale ldem_85n_10m.jp2 ldem_85n_10m_32bit.tif

example data from:
http://pds-geosciences.wustl.edu/lro/lro-l-lola-3-rdr-v1/lrolol_1xxx/data/lola_gdr/polar/jp2

Regards,
Trent

Tip: I have been warned by the LOLA team to be cautious using anything
higher-res than 20m for polar analysis.

-----------------------------------

P.S. Just to muddy the water for LOLA:

Currently for LOLA PDS (*.lbl) labels, you will need to override the OFFSET
defaults. Thus for any PDS LOLA *.lbl label to remove an incorrect 1 pixel
shift you need to also include these command-line --config options:

for gdalinfo:
> gdalinfo  --config PDS_SampleProjOffset_Shift 0.5 --config
PDS_LineProjOffset_Shift 0.5  in.lbl out.tif
For LOLA polar files  the *center should be perfectly 0.0, 0.0 meters* in
Cartesian space

for conversion:
> gdal_translate -ot Float32 -unscale  --config PDS_SampleProjOffset_Shift
0.5 --config PDS_LineProjOffset_Shift 0.5  in.lbl out_32bit.tif

*note: *you *don't* need to use this for the LOLA the *.jp2 files (with
renamed *.xml file). The *.jp2 internal headers use the more standard
Offsets in meters which are correct (not the odd PDS's scaled pixel-space
offsets - at least odd to me).

*History*: There are several known offset issues
<https://trac.osgeo.org/gdal/ticket/3940> for many PDS archives. For GDAL's
PDS support, LOLA currently has this issue for PDS labels (again not the
*.jp2). It was recently determined that the LOLA PDS *.lbl Offset are *actually
correct* but GDAL and ISIS3 have had a 1 pixel PDS offset read error since
they were written. This actually is born from a unfortunate series of
events, where our initial test case, MOLA was (and still is) released with
incorrect offsets. This PDS offset issue is slated to be fixed for GDAL
<https://trac.osgeo.org/gdal/ticket/5941>. Now once this update gets pushed
in, archives that had happened to be incorrect (but worked correctly, e.g.
MOLA) will need to use these overrides.

I am hoping during the transition from PDS3 to PDS4 most of these offset
issues can be dealt with (plenty of other issues to also deal with for
various archives though). Support for a PDS4 driver will start once the
format solidifies. Lastly, since ISIS3 also uses Offsets in meters, there
has never been this issue within GDAL's ISIS3 driver.


On Thu, Jul 23, 2015 at 2:31 AM, Ramiro Marco Figuera <
r.marcofiguera at jacobs-university.de> wrote:

> Hi all,
>
> I'm creating polar gnomonic DEMs using the LOLA DEMs as input files in
> gdal. My end product is an ascii file with X Y Z values. The original LOLA
> DEM is data type integer16 and I'm trying to transform it to a float32. I
> use -ot Float32 in gdal_translate and -wt Float32 in gdalwarp to be sure
> that the data type doesn't changes during the process. The problem is that
> when I open my XYZ file, the Z column has only 3 decimal positions. Is
> there anything I'm doing wrong or am I completely wrong trying to do this?
>
> Cheers
>
> Ramiro
>
> --
> Ramiro Marco Figuera
> Department of Physics and Earth Sciences
> Jacobs University Bremen
> Campus Ring 1, 28759 Bremen, Germany
> Office: Research III, Room 99b
> Tel: +49 (0)421 200 3226
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150723/66c4d03e/attachment.html>