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

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

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

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.

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?

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

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

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

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

Well worth the wait! Thanks!

lighting from 45 deg up ( the basic "emboss" filter ) is the best way to view 16 bit height data
it was the only way i could find to easily show it
soon i am going to have to update my normal map

what did you use to destrip it

Fantastic image! Thanks. This is going to be a fantastic dataset.

Phil

I'm not positive what you mean by destrip, but if you mean removing the vertical banding artifacts, that's why I went back to the source, the RDRs - to generate the map using a modified kriging technique with some different parameters. The image above is the resulting surface normal map cross-produced dot-producted with a 45 degree lighting vector, with no post-processing.

Also - and for me this is the "neato" part - I'm generating the surface normal map directly from the RDRs, which gives a more precise result than generating it from the gridded height map. I was pleased - and more than a little surprised - to see how precisely the resulting surface normal map matches up with the Clementine version 2 base map, in most areas. Computationally expensive to do - and took quite a long time to work out - but worth it.

It's a real pleasure watching the map fill in over the months. I'm already looking forward to the next release.

"I was pleased - and more than a little surprised - to see how precisely the resulting surface normal map matches up with the Clementine version 2 base map, in most areas."

And remember that it's the Clementine map that is wrong if there's a difference. Clementine control, based on a patchwork quilt of thousands of images, will be greatly inferior to this dataset. LOLA is going to be our ultimate lunar control system.

Phil

Yes, I've kind of discovered that the hard way Except: I suspect now that some of the surface normal maps that have been generated may have slight but problematic offsets, because of the way they're derived from the gridded height map. My previous ones certainly did.

For fun, here is the illumination map from above generated from LOLA data, combined with the Clementine map. So basically: the Clementine map with the lighting synthetically shifted to the right to bring out the topography more. The image comes in two three sizes: Preview-size, Large and Extra Large, all generously hosted by UMSF (your donation dollars at work).

LOLA + Clementine lunar map - Preview Size (5760x2880 pixel JPG; 8.9MB)

LOLA + Clementine lunar map - Large (11520x5760 pixel JPG; 30.8MB)

LOLA + Clementine lunar map - Extra Large (23040x11520 pixel JPG; 92.5MB)

that is what i meant .
the processing of the rdr data

the gdr is very banded


i found that out with the kaguya data .Kaguya lines up well with LOLA. But most of the Clementine map is "predictably " off .An over all warp brings most of it
into alignment. However some small areas are just off by what looks like a random amount ( +- 5 to 20 pixels )

I'll probably get around to posting my own version of the GDR, so you can see if it's any better. I'm not quite ready yet, as I usually bypass that step now. Also, it's a very big file.

no kidding it is a big file
the *.dat's alone would be a bit much
then rdr2csv and filter that to the required data
I was looking in to doing that but the overall drive space required is more than i could do