<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Trent,<br>
    <br>
    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.<br>
    <br>
    About the offset, Thanks for the explanation. I will apply the code
    to correct this issue.<br>
    <br>
    Again, thanks a lot!<br>
    <br>
    Cheers,<br>
    <br>
    Ramiro<br>
    <br>
    <div class="moz-cite-prefix">On 07/23/2015 04:57 PM, Hare, Trent
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAB6t5t-x3EJU1F0vN8hH-+0w5JU6jmfnWAq_D89nL53WKhD09Q@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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 moz-do-not-send="true"
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
            moz-do-not-send="true"
            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 moz-do-not-send="true"
            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
                moz-do-not-send="true"
                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 moz-do-not-send="true"
                    href="mailto:gdal-dev@lists.osgeo.org"
                    target="_blank">gdal-dev@lists.osgeo.org</a><br>
                  <a moz-do-not-send="true"
                    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>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
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
</pre>
  </body>
</html>