[gdal-dev] decimal truncation when gdal_translate/gdalwarp

Fri Jul 24 04:09:12 PDT 2015

Trent,

Thanks a lot for the quick answer. I am using the img files so, I guess 
I will have to apply the offset correction. When using gdal_translate I 
already use "gdal_translate -ot Float32 -unscale in_16bit.lbl 
out_32bit.tif". I think the problem might be when I use gdal_translate 
-of XYZ in.tif out.xyz to get a readable file for my code. I am afraid 
that the decimal truncation is happening in this step.

About the offset, Thanks for the explanation. I will apply the code to 
correct this issue.

Again, thanks a lot!

Cheers,

Ramiro

On 07/23/2015 04:57 PM, Hare, Trent wrote:
> 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 
> <mailto: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 <mailto:gdal-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>

-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150724/29fe6a20/attachment.html>