March 15, 2010 PDS release Options

[peter59]

Finally, the data are here:
http://lroc.sese.asu.edu/data/LRO-L-LROC-2....0/LROLRC_0001/
Unfortunately, the server is running terribly slow.

[JohnVV]

IMG2PNG might not work for them

i have found that not just the *.lbl BUT the .img files for the
LDEM_4.LBL
LDEM_4.IMG
LDEM_16.LBL
LDEM_16.IMG
LDEM_64.LBL
LDEM_64.IMG

all of the lbl's are F-'ed up ( this is NOT an exaggeration)

the headers state 3 different bit formats and as 16 bit
the IMG files ARE 32 bit
however ther really are 16 bit images saved as 32 bit ???
also the "SCALING_FACTOR" and "OFFSET" are off
yes this is messed up
this is the LBL for the LDEM_64.IMG
that i just made , and WORKS
this opens it as a 16 bit image

CODE

PDS_VERSION_ID            = "PDS3"
/*** FILE FORMAT ***/
FILE_RECORDS              = 11520
RECORD_TYPE               = FIXED_LENGTH
RECORD_BYTES              = 46080
^IMAGE                    = "LDEM_64.IMG"
/*** GENERAL DATA DESCRIPTION PARAMETERS ***/
PRODUCT_VERSION_ID        = "V1 revision F"                                        
DATA_SET_ID               = "LRO-L-LOLA-64-GDR-V1.0"
PRODUCT_ID                = "LDEM_64.IMG"
INSTRUMENT_HOST_NAME      = "LUNAR RECONNAISSANCE ORBITER"              
INSTRUMENT_NAME           = "LUNAR ORBITER LASER ALTIMETER"              
INSTRUMENT_ID             = "LOLA"
COORDINATE_SYSTEM_NAME    = "MEAN EARTH/POLAR AXIS OF DE421"
MISSION_PHASE_NAME        = {"COMMISSIONING","NOMINAL MISSION"}
TARGET_NAME               = MOON
START_TIME                = 2009-07-13T17:33:17.246
STOP_TIME                 = 2009-12-17T19:42:52.026                      
PRODUCT_CREATION_TIME     = 2010-03-01T00:00:00
PRODUCER_ID               = LRO_LOLA_TEAM
PRODUCER_FULL_NAME        = "DAVID E. SMITH"
PRODUCER_INSTITUTION_NAME = "GODDARD SPACE FLIGHT CENTER"
DESCRIPTION               = "This data product is a shape map (radius)
   of the Moon at a resolution of 64 pixels per degree"

OBJECT                    = IMAGE
  NAME                    = HEIGHT
  DESCRIPTION             = ""
  LINES                   = 11520
  LINE_SAMPLES            = 23040
  SAMPLE_TYPE             = LSB_UNSIGNED_INTEGER
  SAMPLE_BITS             = 16
  UNIT                    = METER
  SCALING_FACTOR          = 1.0
  OFFSET                  = 0
END_OBJECT                = IMAGE

OBJECT                    = IMAGE_MAP_PROJECTION
^DATA_SET_MAP_PROJECTION = "DSMAP.CAT"
MAP_PROJECTION_TYPE      = "SIMPLE CYLINDRICAL"
A_AXIS_RADIUS            = 1737.4 <KM>
B_AXIS_RADIUS            = 1737.4 <KM>
C_AXIS_RADIUS            = 1737.4 <KM>
FIRST_STANDARD_PARALLEL  = "N/A"
SECOND_STANDARD_PARALLEL = "N/A"
POSITIVE_LONGITUDE_DIRECTION = "EAST"
CENTER_LATITUDE          = 0.0 <DEGREE>
CENTER_LONGITUDE         = 180.0 <DEGREE>
REFERENCE_LATITUDE       = "N/A"
REFERENCE_LONGITUDE      = "N/A"
LINE_FIRST_PIXEL         = 1
LINE_LAST_PIXEL          = 11520
SAMPLE_FIRST_PIXEL       = 1
SAMPLE_LAST_PIXEL        = 23040
MAP_PROJECTION_ROTATION  = 0.0
MAP_RESOLUTION           = 64.0 <PIXEL/DEGREE>
MAP_SCALE                = 0.47375 <KM/PIXEL>
MAXIMUM_LATITUDE         = 90.0 <DEGREE>
MINIMUM_LATITUDE         = -90.0 <DEGREE>
WESTERNMOST_LONGITUDE    = 0.0 <DEGREE>
EASTERNMOST_LONGITUDE    = 360.0 <DEGREE>
LINE_PROJECTION_OFFSET   = 0.0
SAMPLE_PROJECTION_OFFSET = 0.0
COORDINATE_SYSTEM_TYPE   = "BODY-FIXED ROTATING"
COORDINATE_SYSTEM_NAME   = "MEAN EARTH/POLAR AXIS OF DE421"
END_OBJECT                = IMAGE_MAP_PROJECTION

END

however you will find that in isis the map projection is off .It is in sym cyl BUT the lat/long are way off
you will need to run maplab on it

[zeBeamer]

all of the lbl's are F-'ed up ( this is NOT an exaggeration)

the headers state 3 different bit formats and as 16 bit
the IMG files ARE 32 bit
however ther really are 16 bit images saved as 32 bit ???
also the "SCALING_FACTOR" and "OFFSET" are off
yes this is messed up

John...
as I noted earlier in response to mhoward, there was an issue with the cylindrical IMGs being unsigned instead of signed. This was corrected. Did you see that, and are talking about the IMGs currently on the website?

however you will find that in isis the map projection is off .It is in sym cyl BUT the lat/long are way off
you will need to run maplab on it

I personally haven't tried with the IMGs, but the JP2s seem fine when overlaid over a Clementine basemap. What do you mean by "way off" ?

Erwan

[Jim Mosher]

Erwan,

I don't think there are any major problems with the most recent *.LBL files, but I wonder if it would be possible to upload copies of "LDEM_4.LBL" and "LDEM_16.LBL" with the "OFFSET" parameter in "OBJECT = IMAGE" corrected to "1737400." <meters>? The text description implies this is the offset used for forming the signed integers, but it is correctly listed on the machine-readable "OFFSET" line only in "LDEM_64.LBL". The other two *.LBL files, as John points out, give "1728216.", a number which may never have been correct.

This may seem a very insignificant point -- since users can easily hand-edit these text files -- but I was writing directions on how to use the LOLA data with a program that automatically reads the *.LBL files associated with the *.IMG files, and this seems to add an unnecessary level of complication and confusion.

In LDEM_16.IMG, assuming the 0.5 m per count scaling and 1737.400 km reference radius are correct, I find minimum and maximum data values of -9.047 km (at line 2566, sample 3001) and +10.614 km (at line 1354, sample 3221); a slightly smaller range, so far, than the Kaguya values of -9.140 km and +10.716 at nearly the same positions in their 16 samples per degree grid. This would correspond to a LOLA height range, from the Moon's center, of 1724.953 (minimum) to 1744.614 km (maximum). Is that correct?

Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

One other very minor point: the *.LBL files say your grid is reported in the "MEAN EARTH/POLAR AXIS OF DE421" coordinate system. To the best of my knowledge, the Moon's Mean Earth/Polar Axis system is offset from the JPL DE421 ephemeris system by small rotations about each axis. Did you apply those corrections? If so, did you use the rotations recommended in the "IAU/IAG Working Group on Cartographic Coordinates" reports of Seidelmann et al. or some other ones?

Finally, although I find nothing materially wrong with the *.LBL files, I find the references to "planetopotential TOPOGRAPHY" and "GEOID" in the explanation of the data format slightly confusing. As I understand the explanation, the data represent "PLANETARY_RADIUS" rather than "planetopotential TOPOGRAPHY", and since no geoid is defined, and no correction for it required to use the data, the references to this additional computation seem unnecessary?

-- Jim Mosher

[zeBeamer]

John,

Nothing is 32bit except the GRDs.



Jim,

I don't think there are any major problems with the most recent *.LBL files, but I wonder if it would be possible to upload copies of "LDEM_4.LBL" and "LDEM_16.LBL" with the "OFFSET" parameter in "OBJECT = IMAGE" corrected to "1737400." <meters>? The text description implies this is the offset used for forming the signed integers, but it is correctly listed on the machine-readable "OFFSET" line only in "LDEM_64.LBL". The other two *.LBL files, as John points out, give "1728216.", a number which may never have been correct.

This seems sensible. I will double-check tomorrow and correct it.
We are working on improving the labels in general. Very soon you'll have one label file per product format (jp2,img,grd).
Bottom line, I think LDEM_64.LBL is correct.

This may seem a very insignificant point -- since users can easily hand-edit these text files -- but I was writing directions on how to use the LOLA data with a program that automatically reads the *.LBL files associated with the *.IMG files, and this seems to add an unnecessary level of complication and confusion.

Good to see people integrating the data in their program already
On that website you say "Nonetheless, LOLA gridded data covering the period 2009-07-13 through 2009-12-17 are (unofficially?) available on an MIT website." Actually, this MIT website is the official LOLA PDS data node. PDS archives/mirrors it.

Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

Emily is perfectly correct in her post. We don't want to take the Kaguya data at face value (even though they've done a good job) and simply put them in. The LOLA data are geolocated based on LRO orbit solutions, which we understand and are working on improving... And with time, we'll cover (very close) to those Kaguya tracks.

One other very minor point: the *.LBL files say your grid is reported in the "MEAN EARTH/POLAR AXIS OF DE421" coordinate system. To the best of my knowledge, the Moon's Mean Earth/Polar Axis system is offset from the JPL DE421 ephemeris system by small rotations about each axis. Did you apply those corrections? If so, did you use the rotations recommended in the "IAU/IAG Working Group on Cartographic Coordinates" reports of Seidelmann et al. or some other ones?

I think all your answers will be found in :
ftp://naif.jpl.nasa.gov/pub/naif/generic_...orientation.pdf
If you're familiar with SPICE, basically, in addition to using the "de421.bsp" kernel, we also load the following kernels, which define the "MOON_ME" frame.
moon_pa_de421_1900-2050.bpc, moon_080317.tf, moon_assoc_me.tf, also available from the NAIF website.

Finally, although I find nothing materially wrong with the *.LBL files, I find the references to "planetopotential TOPOGRAPHY" and "GEOID" in the explanation of the data format slightly confusing. As I understand the explanation, the data represent "PLANETARY_RADIUS" rather than "planetopotential TOPOGRAPHY", and since no geoid is defined, and no correction for it required to use the data, the references to this additional computation seem unnecessary?

well, you can see that as superficial; but it's just recalling what is in this dataset, so that people know it's not geoid-related ("huge discovery: lava flows going uphill!"). We may release planetopotential topography grids in the future. Plus, in the RDRs, the geoid value at each LOLA point is defined.


Erwan