It's June - Better LOLA? Options

[Mars3D]

Thanks for the replies.

I think I'll have a go at writing some code to process the rdrs. I have the code to do the gridding and bad data removal from the work I did with the MOLA data.

[James Fincannon]

How are you guys processing the RDRs? I have found RDR2TAB and RDR2XYZ but they are for MAC only, has anyone found a win32 version? I have the fortran source code but no compiler.

Thanks for any help.

Sorry, I do not know of a win32 version. I wrote my own FORTRAN RDR reader based on the description of the RDR file. Erwan M. described to me a lot of conversions needed to create a DEM. I skip those because I need to use the raw data points for my work. Also, I found I needed to examine segments carefully with a viewer to make sure no erroneous data points were included (they are not flagged yet, perhaps in future versions).

Anyone heard when the WAC LRO stereo DEM is going to be published?

[mhoward]

I think I'll have a go at writing some code to process the rdrs. I have the code to do the gridding and bad data removal from the work I did with the MOLA data.

Interesting. I've done the work and gotten results but haven't had time to release anything yet. At the moment I exclude bad LOLA data on a file-by-file basis. Fortunately they have cleaned up a lot of the data, just not quite all of it.

[JohnVV]

it should build in MinGW on windows but you would need to spend a week or two setting up MinGW ( unless you have done that a lot -- then a day or two )
However i have not done this for the rdr FORTRAN files , so it is a guess .

MinGW runs much faster than CygWin

[Mars3D]

I briefly tried MinGW but I was getting lots of compiler errors so I gave up. I have now written some c code to process the rdrs and it looks like its working ok. Now I just need to download all the rdrs which looks like its going to take a very long time.

[JohnVV]

those errors are from mingw needing to be configured BY HAND for EVERY AND ALL text based files
that is why a new person to mingw will take 1 two 2 weeks to find all of the hard coded " c:\PROG~\????" hard links in it
every one needs to be reset to c:\Gnuwin32\Minjgw

the gnuwin32 project for some very odd and bad reason lies windows install everything to c\Program Files\ Program name
with ALL the spaces --- not good

then the paths c\GnuWin32\MinGW and c:\GnuWin32\Msys need to be added to the Microsoft system path
and Msys needs to be set up

a bunch of work

[mhoward]

Now I just need to download all the rdrs which looks like its going to take a very long time.

Took me literally weeks to download it all over a typical DSL connection. And every time I finished, they would be updated

[Mars3D]

Took me literally weeks to download it all over a typical DSL connection. And every time I finished, they would be updated

I've worked out if it will take me 2 weeks of continuous downloading. So I should be finished about the time of the December update

[JohnVV]

seeing as the labels are the ones being updated
http://imbrium.mit.edu/DATA/LOLA_RDR/LRO_NO_10/
*.DAT Aug 17
*.LBL Nov 5

and the LBL's are 5.8 K each
very small to update

[mhoward]

seeing as the labels are the ones being updated

Not correct - in the past most of the data has been updated, extensively.

Whether all the data will be updated in the next round, well - for the sake of our poor Internet connections it might be nice if it weren't, but it might also be good if it was. So far it's been improving over time.

[ValterVB]

I think to have found an error on LDEM 256 download from imbrium.mit.edu
In the LBL file, MAP_RESOLUTION and MAP_SCALE are reversed, I Have checked on pds-geosciences

Wrong
MAP_RESOLUTION = 118.451 <m/pix>
MAP_SCALE = 256 <pix/degree>

Correct
MAP_RESOLUTION = 256 <pix/degree>
MAP_SCALE = 118.451 <m/pix>

Someone can correct it?

[Phil Stooke]

In the old days this was straightforward. Resolution was always given as so many meters (or kilometers, or your unit of choice) per pixel (or line pair... OK, maybe it wasn't so straightforward)... anyway, resolution = m/pixel or some equivalent. And map scale was given as 1:500,000, or 1:1 million, or "1 cm represents 10 km" or words to that effect.

Digital maps messed this up a bit because a digital file could be printed at any physical size. So the idea developed that digital map scales should be defined as the number of pixels across a standard distance unit - pixels per degree of latitude for instance. These things are not really universal and strictly speaking they are ambiguous, but that is common usage. So I have to say, actually, there is no mistake.

Phil

[ValterVB]

Thanks for the answer Phil, but it is strange, because now I can't found the wrong file. Now all the LBL file have MAP_RESOLUTION with <pix/deg>.
I have an old file (PRODUCT_CREATION_TIME = 2010-09-15T00:00:00) with MAP_RESOLUTION in m/pix and MAP_SCALE in pix/degree, the file name is
LDEM_256_0_180_0N_90N.LBL.
Perhaps is changed from September

Ciao
VB

[JohnVV]

Perhaps is changed from September

the date for the 256 dem is Nov 30 and for the 256 LBL is Dec 2
the labels were updated

[mhoward]

Here's a little something to show how good the LOLA data is getting. This is a map generated from the LOLA data only, as if the moon were a uniformly-colored surface, with each point illuminated from a 45 degree angle to the left right. I use this kind of image to identify problem sections in the LOLA RDR data for what I'm doing, but I thought the result was kind of interesting in itself, so I put together a whole mosaic. Before pressing the link, please note that this is a big image - you might want to view it outside the browser. (And this is actually the half-size version.)

LOLA_diagnostic_illumination_whole_11K.jpg (11520x5760 pixel JPG image; 27MB)

Edit: and if you really want the full-size version, it's here: 23040x11520 pixel JPG image; 71MB