<div dir="ltr">Ramiro,<div>  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.</div><div><br></div><div>> gdal_translate -ot Float32 -unscale in_16bit.lbl out_32bit.tif</div><div>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:</div><div><br></div><div>first rename:</div><div>> mv ldem_85n_10m_aux.xml ldem_85n_10m.jp2.aux.xml</div><div>now convert to 32bit Tiff (please see tip below):</div><div>> gdal_translate -ot Float32 -unscale ldem_85n_10m.jp2 ldem_85n_10m_32bit.tif</div><div><br></div><div>example data from: <a href="http://pds-geosciences.wustl.edu/lro/lro-l-lola-3-rdr-v1/lrolol_1xxx/data/lola_gdr/polar/jp2">http://pds-geosciences.wustl.edu/lro/lro-l-lola-3-rdr-v1/lrolol_1xxx/data/lola_gdr/polar/jp2</a></div><div><br></div><div>Regards,</div><div>Trent</div><div><br></div><div>Tip: I have been warned by the LOLA team to be cautious using anything higher-res than 20m for polar analysis.</div><div><br></div><div>-----------------------------------</div><div><br></div><div>P.S. Just to muddy the water for LOLA:</div><div><br></div><div>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:</div><div><br></div><div>for gdalinfo:</div><div><div>> gdalinfo  --config PDS_SampleProjOffset_Shift 0.5 --config PDS_LineProjOffset_Shift 0.5  in.lbl out.tif</div></div><div>For LOLA polar files  the <b>center should be perfectly 0.0, 0.0 meters</b> in Cartesian space</div><div><br></div><div>for conversion:</div><div><div>> gdal_translate -ot Float32 -unscale  --config PDS_SampleProjOffset_Shift 0.5 --config PDS_LineProjOffset_Shift 0.5  in.lbl out_32bit.tif</div></div><div><br></div><div><b>note: </b>you <b>don't</b> 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).<br></div><div><br></div><div><u>History</u>: There are several known <a href="https://trac.osgeo.org/gdal/ticket/3940">offset issues</a> 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 <b>actually correct</b> 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 <a href="https://trac.osgeo.org/gdal/ticket/5941">fixed for GDAL</a>. 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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 23, 2015 at 2:31 AM, Ramiro Marco Figuera <span dir="ltr"><<a href="mailto:r.marcofiguera@jacobs-university.de" target="_blank">r.marcofiguera@jacobs-university.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
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?<br>
<br>
Cheers<span class=""><font color="#888888"><br>
<br>
Ramiro<br>
<br>
-- <br>
Ramiro Marco Figuera<br>
Department of Physics and Earth Sciences<br>
Jacobs University Bremen<br>
Campus Ring 1, 28759 Bremen, Germany<br>
Office: Research III, Room 99b<br>
Tel: +49 (0)421 200 3226<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</font></span></blockquote></div><br></div></div>