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
<[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
