Thanks Jim, I was pleased to see the map on LPOD. That's a fascinating story about the new possible basin.
This detail map from the Kaguya DEM shows the peak in question. Is it plausible to have a lunar peak with a slope of about 60 degrees?
This peak was the subject of discussion on the Solar Eclipse Mailing List (SEML). We are applying the Kaguya DEM to improve solar eclipse predictions. I had email with Dave Herald who pointed out that the LALT_GGT_NUM DEM data is derived from Kaguya timing data (LALT_LGT_TS) and that the timing data is superior for elevation modeling. (The timing data consists of irregularly spaced points, in contrast to the gridded interpolated points of the LALT_GGT_NUM data)
I'm attaching this detail map showing the peak from the DEM data. Dave sent me some timing data points that show that this peak does not exist in the LALT_LGT_TS data and seems to be an error of interpolation. I don't have time tonight to make a map to demonstrate this, but I'll make a map tomorrow.
regards, Michael
Full Version: First public release of Kaguya data
Jim and Michael - you're talking about two different places! Michael's crater is a wee bit north of Jim's image, on Goddard crater. (16 N, not 6 N)
Phil
Phil
My apologies, Michael...
I have always been clumsy converting degrees-minutes-seconds to decimal degrees, and in this case I inadvertently dropped the leading "1" of your degrees number, changing "16N" to "6N". Sorry!
You are, of course, completely correct about the location of this set of four bad pixels at 16d 11m N, 87d 33m E (in lines 1181 and 1182 at samples 1401 and 1402 in the global DEM). As Phil points out, they are not at all in the area I was looking at, but rather slightly outside the rim of Goddard, and just east of 12 km Goddard B (represented by the little downward wiggle in the -2000 m contour on your plot). For what little it may be worth, according to the shadows in Lunar Orbiter IV-018H, Goddard B must be 2.4 km deep -- very slightly deeper than Goddard A (which was captured much more clearly in the global DEM, near the upper right margin in your plot) -- and Lunar Orbiter IV did not see any evidence of a sharp shadow-casting peak at 16d 11m N, 87d 33m E, so this feature in the Kaguya global DEM is definitely fictitious.
And yes, 60° sounds like quite a steep slope for the Moon, especially if sustained over the ~2 km spacing between adjoining grid points near the equator.
-- Jim
I have always been clumsy converting degrees-minutes-seconds to decimal degrees, and in this case I inadvertently dropped the leading "1" of your degrees number, changing "16N" to "6N". Sorry!
You are, of course, completely correct about the location of this set of four bad pixels at 16d 11m N, 87d 33m E (in lines 1181 and 1182 at samples 1401 and 1402 in the global DEM). As Phil points out, they are not at all in the area I was looking at, but rather slightly outside the rim of Goddard, and just east of 12 km Goddard B (represented by the little downward wiggle in the -2000 m contour on your plot). For what little it may be worth, according to the shadows in Lunar Orbiter IV-018H, Goddard B must be 2.4 km deep -- very slightly deeper than Goddard A (which was captured much more clearly in the global DEM, near the upper right margin in your plot) -- and Lunar Orbiter IV did not see any evidence of a sharp shadow-casting peak at 16d 11m N, 87d 33m E, so this feature in the Kaguya global DEM is definitely fictitious.
And yes, 60° sounds like quite a steep slope for the Moon, especially if sustained over the ~2 km spacing between adjoining grid points near the equator.
-- Jim
It's interesting to speculate as to how a mistake like this gets into a raster DEM created from point data - the actual timing measurements along ground tracks. A bad data point in the raw data should be broadened or smoothed in the 'gridded' version, if it's not filtered out beforehand. But I'm not sure how good data lead to a bad spot in a raster DEM.
Phil
Phil
QUOTE (Phil Stooke @ Nov 23 2009, 02:10 PM) 
It's interesting to speculate as to how a mistake like this gets into a raster DEM created from point data - the actual timing measurements along ground tracks. A bad data point in the raw data should be broadened or smoothed in the 'gridded' version, if it's not filtered out beforehand. But I'm not sure how good data lead to a bad spot in a raster DEM.
Phil
Phil
Yes Phil, I was wondering how that happened as well. You would expect that a grid interpolation from irregularly spaced points in a triangulation would lead to a general smoothing of the surface model, not the creation of spikes. Various types of interpolation could have been employed, but you would not expect to generate such extreme peaks spanning several grid points. When you compare the timing data points to the DEM points, there is no surface trend visible that could yield that peak. When I triangulated the timing data points, I recall seeing local slope values of about 20 degrees, but nothing resembling the peak in the DEM. (I'll make a map when I get home tonight)
From the Kaguya DEM, I created a slope map which I consider to be a good filter for detecting spurious peaks or pits. In a previous post, I gave a listing of places with large slope values. When I have time later this week (with a belly full of turkey) I will re-examine these points to see whether they appear to be data artifacts or extreme but valid lunar topography.
I'm certainly no lunar expert, but I would expect that steep slopes on the Moon to be rare because of the 4 billion year rain of impacts and lack of plate tectonics. As a boy, I remember how smooth the mountains visited by the Apollo astronauts appeared to be. I wonder what is the plausible maximum slope (over a sizable distance) to be expected on the Moon.
What would also be helpful would be to know the mean error in elevation measurements for Kaguya timing data. I don't doubt that measured range distances from the Kaguya laser altimeter are very accurate, but reducing that measurement to an elevation value requires an accurate satellite position in orbit and the Moon's gravitational field is lumpy. I'm more familiar with lidar technology for terrestrial applications, but lidar has the advantage of reducing points with an accurate flight path determination from onboard GPS receivers. Unless I'm mistaken, the Moon has nothing like the GPS constellation and no geodetic control, save the retro-reflectors left by the Apollo missions.
- Michael
Right - no GPS and essentially no geodetic control (3 points, not counting Lunokhod 2 since we don't know its location very precisely in the landscape, maybe only to 100 m or thereabouts). Note that LOLA is dealing with this as much as possible using ground-based laser ranging to LRO.
Phil
Phil
Michael,
The points you listed are all DEM artifacts -- not real lunar features -- with the exception of the one at "32 26 S, 58 57 E" which is possibly a typo. Unless I am continuing to suffer from my coordinate-conversion handicap, I can find no anomaly in the global DEM at 58.95°E/32.43°S...
On the other hand, there are many digital blips not in your list (as well as real lunar features that are missing from the DEM, presumably due to a lack of laser hits). Many of the bad points stand out so much they can be spotted simply by roaming over the raw DEM in grayscale rendition. For example, in Mare Serenitatis, at 16.60°E/21.38°N, there are a couple of bad points with 4-5 km of upward relief (rendered as a fictitious crater just west of Bessel in your maps) that are definitely not present on the Moon (see the attachments for the bad points in the grayscale DEM and the false shadow it generates in the LTVT simulation for tonight's Moon).
Despite its occasional defects, the key point, I think, is that Kaguya's global LALT DEM looks remarkably accurate, overall.
Regarding "the mean error in elevation measurements for Kaguya timing data" the following is the official statement (and explanation, rather opaque to me) in the article "Lunar Global Shape from Kaguya-LALT Laser Altimetry" by H. Araki, et al. Science 323, 897 (2009) by Araki et al. Others better qualified than I can evaluate if they are saying the Kaguya surface positions and elevations are semi-independent of earlier lunar control work. If so, then the agreement of positions, at least, with ULCN2005 is impressive.
-- Jim
The points you listed are all DEM artifacts -- not real lunar features -- with the exception of the one at "32 26 S, 58 57 E" which is possibly a typo. Unless I am continuing to suffer from my coordinate-conversion handicap, I can find no anomaly in the global DEM at 58.95°E/32.43°S...
On the other hand, there are many digital blips not in your list (as well as real lunar features that are missing from the DEM, presumably due to a lack of laser hits). Many of the bad points stand out so much they can be spotted simply by roaming over the raw DEM in grayscale rendition. For example, in Mare Serenitatis, at 16.60°E/21.38°N, there are a couple of bad points with 4-5 km of upward relief (rendered as a fictitious crater just west of Bessel in your maps) that are definitely not present on the Moon (see the attachments for the bad points in the grayscale DEM and the false shadow it generates in the LTVT simulation for tonight's Moon).
Despite its occasional defects, the key point, I think, is that Kaguya's global LALT DEM looks remarkably accurate, overall.
Regarding "the mean error in elevation measurements for Kaguya timing data" the following is the official statement (and explanation, rather opaque to me) in the article "Lunar Global Shape from Kaguya-LALT Laser Altimetry" by H. Araki, et al. Science 323, 897 (2009) by Araki et al. Others better qualified than I can evaluate if they are saying the Kaguya surface positions and elevations are semi-independent of earlier lunar control work. If so, then the agreement of positions, at least, with ULCN2005 is impressive.
-- Jim
QUOTE
Text:
Topography data were produced by incorporating precise orbits for the Kaguya main orbiter. These orbits are calculated from twoway Doppler data by the GEODYN-II software using the latest lunar gravity model SGM90em (SELENE Gravity Model) that is an adapted version of the model SGM90d for the purpose of orbit determination (10–12). Orbit precision is determined from orbit differences during overlapping parts, showing that the radial orbit error is generally within 1 m (13) and the total positioning error (computed using the root sum square over the radial, along-track, and crosstrack directions) is found to be ~50 m. Thus, the radial topographic error originated from the orbit repeatability is 1 m (1 SD), the instrumental error is 0.55 m (1 SD), and the instrument range shift is between +2.5 m and +12 m (8, 9), which are summarized +/-4.1 m (1 SD) as the final budget where the range shift is incorporated as 4 m (1 SD). In the same way, the horizontal topographic error originated from the orbit repeatability is 50 m (1 SD), the pointing error is 175 m (maximum), and the time-tag error is 1.5 m (maximum), which are summarized as +/-77 m (1 SD) as the final budget (14).
References and Notes:
8. H. Araki et al., Adv. Space Res. 42, 317 (2008).
9. One remaining concern is about systematic errors in measurements of pulse arrivals due to distortion of the return pulse caused by the sloped and/or rough target terrain in combination with unknown albedo effects. This error (range shift) may result in underestimates of ranges by 12 m in the very worst case of 30° slope and 30% surface reflectance before the pulse spreading correction. For moderately flat surfaces, systematic range errors are expected to be 2.5 m (8).
10. D. E. Pavlis et al., “GEODYN II system description, vols. 1-5,” Contractor Report, SGT Inc. (2006).
11. J. J. McCarthy, “SOLVE program user's guide,” Contractor Report between NASA/GSFC and Hughes/STX (2007).
12. N. Namiki et al., Science 323, 900 (2009).
13. Orbits are determined by full-scale precision force and measurement modeling. For each data arc, estimated parameters include the state vector at epoch, a solar radiation pressure coefficient, empirical accelerations with a once per orbital revolution signature in the along-track and cross-track direction, and measurement biases to absorb systematic effects and mismodeling. Orbit precision has been evaluated by computing orbit overlap differences. Overlap analysis showed a radial consistency of 1 m in general, with outliers (that were excluded from topography data processing) up to 4 m.
14. The pointing error is considered to be <0.1° (175 m for 100-km altitude), based on the thermal and other deformation analysis of the main orbiter. Time-tag error is <1 msec (1.5 m along-track for 100-km altitude) through the correction that takes into account the propagation time from the main orbiter to each station and the processing delay on each tracking station. These values (175 m and 1.5 m) are incorporated into the final budget as 3 SD errors.
Topography data were produced by incorporating precise orbits for the Kaguya main orbiter. These orbits are calculated from twoway Doppler data by the GEODYN-II software using the latest lunar gravity model SGM90em (SELENE Gravity Model) that is an adapted version of the model SGM90d for the purpose of orbit determination (10–12). Orbit precision is determined from orbit differences during overlapping parts, showing that the radial orbit error is generally within 1 m (13) and the total positioning error (computed using the root sum square over the radial, along-track, and crosstrack directions) is found to be ~50 m. Thus, the radial topographic error originated from the orbit repeatability is 1 m (1 SD), the instrumental error is 0.55 m (1 SD), and the instrument range shift is between +2.5 m and +12 m (8, 9), which are summarized +/-4.1 m (1 SD) as the final budget where the range shift is incorporated as 4 m (1 SD). In the same way, the horizontal topographic error originated from the orbit repeatability is 50 m (1 SD), the pointing error is 175 m (maximum), and the time-tag error is 1.5 m (maximum), which are summarized as +/-77 m (1 SD) as the final budget (14).
References and Notes:
8. H. Araki et al., Adv. Space Res. 42, 317 (2008).
9. One remaining concern is about systematic errors in measurements of pulse arrivals due to distortion of the return pulse caused by the sloped and/or rough target terrain in combination with unknown albedo effects. This error (range shift) may result in underestimates of ranges by 12 m in the very worst case of 30° slope and 30% surface reflectance before the pulse spreading correction. For moderately flat surfaces, systematic range errors are expected to be 2.5 m (8).
10. D. E. Pavlis et al., “GEODYN II system description, vols. 1-5,” Contractor Report, SGT Inc. (2006).
11. J. J. McCarthy, “SOLVE program user's guide,” Contractor Report between NASA/GSFC and Hughes/STX (2007).
12. N. Namiki et al., Science 323, 900 (2009).
13. Orbits are determined by full-scale precision force and measurement modeling. For each data arc, estimated parameters include the state vector at epoch, a solar radiation pressure coefficient, empirical accelerations with a once per orbital revolution signature in the along-track and cross-track direction, and measurement biases to absorb systematic effects and mismodeling. Orbit precision has been evaluated by computing orbit overlap differences. Overlap analysis showed a radial consistency of 1 m in general, with outliers (that were excluded from topography data processing) up to 4 m.
14. The pointing error is considered to be <0.1° (175 m for 100-km altitude), based on the thermal and other deformation analysis of the main orbiter. Time-tag error is <1 msec (1.5 m along-track for 100-km altitude) through the correction that takes into account the propagation time from the main orbiter to each station and the processing delay on each tracking station. These values (175 m and 1.5 m) are incorporated into the final budget as 3 SD errors.
as i have been cleaning up the topo data for use in celestia ,those "bad data points" are being removed along with the vertical
stripes as seen here
orig.
Click to view attachment
cleaned up
Click to view attachment
but there IS A miss-alignment with the Clem_NIR_V0.1 data
see my post at shatters.net
http://www.shatters.net/forum/viewtopic.php?f=5&t=15533
for more on that ( i don't like reposting the same thing in different places )
stripes as seen here
orig.
Click to view attachment
cleaned up
Click to view attachment
but there IS A miss-alignment with the Clem_NIR_V0.1 data
see my post at shatters.net
http://www.shatters.net/forum/viewtopic.php?f=5&t=15533
for more on that ( i don't like reposting the same thing in different places )
I just noticed that LALT_LGT_TS files contain 'raw' elevation data by latitude & longitude - and some other data I don't understand yet. Has anyone tried to get a better-resolution elevation map out of them?
Edit: Never mind, I see I missed a post a few back. This has already been mentioned.
Edit: Never mind, I see I missed a post a few back. This has already been mentioned.
Here you can find my little experiment with Kaguya data.
Video
The file is DTMTCO_02_00823N200E0310SC
Image center coordinate:
Latitude: 19.95
Longitude: 30.36
Is near Apollo 17 landing site. The red line is the approximate location.
Compare with http://www.lpi.usra.edu/publications/slide...g/slide_35.html
Dimension: 47.748 Km x 42.715 Km
Resolution: 74.036 m (389116 point)
Texture dimension: 6728x5777 px
Illumination conditon: Morning
3D and animation with Blender
Ciao
VB
Video
The file is DTMTCO_02_00823N200E0310SC
Image center coordinate:
Latitude: 19.95
Longitude: 30.36
Is near Apollo 17 landing site. The red line is the approximate location.
Compare with http://www.lpi.usra.edu/publications/slide...g/slide_35.html
Dimension: 47.748 Km x 42.715 Km
Resolution: 74.036 m (389116 point)
Texture dimension: 6728x5777 px
Illumination conditon: Morning
3D and animation with Blender
Ciao
VB
People,
Phil here reporting from Houston. I'm at LPSC. At the reception this evening I heard that a utility for opening Kaguya images will be made available in a few months... will say more when I can.
Phil
Phil here reporting from Houston. I'm at LPSC. At the reception this evening I heard that a utility for opening Kaguya images will be made available in a few months... will say more when I can.
Phil
Here you can find a script for import LALT_GGT_NUM dataset from the JAXA in Blender. The name of the file to download is Moon importer.blend
You can choice latidude and longitude and then the script import the date.
All you need is Blender (not version 2.5) and the file LALT_GGT_MAP.IMG. Before to run the script change the path on the script (on the top/left of the windows
This is an example. (Pay attention to the number of vertices, my max limit is 2 millions of vertices)
If you speak italian you can see my blog, where I explain How to do
Ciao
VB
You can choice latidude and longitude and then the script import the date.
All you need is Blender (not version 2.5) and the file LALT_GGT_MAP.IMG. Before to run the script change the path on the script (on the top/left of the windows
This is an example. (Pay attention to the number of vertices, my max limit is 2 millions of vertices)
If you speak italian you can see my blog, where I explain How to do
Ciao
VB
I have only very recently discovered the treasure trove of KAGUYA data and have a question specifically to the TC (Terrain Camera) Data that I have not been able to answer from reading through all of the KAGUYA thread so dar.
It seems that others (Phil Stooke) already did quite some work with the TC data so maybe they could help answer the following question: So is it really true that there is already global (or a substantial fraction of global) coverage of TC derived DEM data as suggested by the official KAGUYA mission statements (which would be really, really ueber-awseome: a global DEM at 10 meter resolution, i.e. about 100 times (!) more detailed than the laser altimeter derived maps at about 1 kilometer per pixel). It also seems that Google Moon is already using a high resolution DEM in many places which from the look at it seems more detailed than the usual 1-kilometer per pixel altimeter DEM (but not as detailed than a 10-meter DEM ? (anyone know what datasets are exactly used by Google Moon ?)
What I have been able so far ist to download and process TC DEMs for selected areas but I have trouble to fnd the proposed "global coverage".
When looking at the TC overlays in 3D Moon Java App there seem to appear also only very few areas.
So is this still unreleased material or am I doing the wrong search ?
Interestingly, when doing a "blank" search at the Kaguya data archive for all TC DEMs it returns around 30.000 records which looks promising for near global coverage but I have not been able to do a more targeted GIS-style or at least coordinate based search which returns only sparse coverage in selected areas.
Thanks a lot for any suggestions !
It seems that others (Phil Stooke) already did quite some work with the TC data so maybe they could help answer the following question: So is it really true that there is already global (or a substantial fraction of global) coverage of TC derived DEM data as suggested by the official KAGUYA mission statements (which would be really, really ueber-awseome: a global DEM at 10 meter resolution, i.e. about 100 times (!) more detailed than the laser altimeter derived maps at about 1 kilometer per pixel). It also seems that Google Moon is already using a high resolution DEM in many places which from the look at it seems more detailed than the usual 1-kilometer per pixel altimeter DEM (but not as detailed than a 10-meter DEM ? (anyone know what datasets are exactly used by Google Moon ?)
What I have been able so far ist to download and process TC DEMs for selected areas but I have trouble to fnd the proposed "global coverage".
When looking at the TC overlays in 3D Moon Java App there seem to appear also only very few areas.
So is this still unreleased material or am I doing the wrong search ?
Interestingly, when doing a "blank" search at the Kaguya data archive for all TC DEMs it returns around 30.000 records which looks promising for near global coverage but I have not been able to do a more targeted GIS-style or at least coordinate based search which returns only sparse coverage in selected areas.
Thanks a lot for any suggestions !
Sorry folks - I did look at this stuff when it first became available, briefly, but I don't find the access very convenient, and I never found access to more than a very restricted subset of images (and never tried the altimetry). I'm tied up with Mars and asteroids at the moment and not doing much with the Moon. Note to people planning online access to data - keep it as simple as possible!
Phil
Phil
QUOTE (Phil Stooke @ Sep 13 2010, 03:55 PM)
I'm tied up with Mars and asteroids at the moment and not doing much with the Moon. Note to people planning online access to data - keep it as simple as possible!
Phil
Phil
nevermind Phil ! thanks for the answer anyway.
Your reporting similar troubles with the dataset basically already answers my main question: so it's not just me having trouble with the access details of the TC Kaguya dataset.
I thought it might be something simple like just using the wrong front end or that a large part of the TC data might still be unreleased for the higher processing levels... something like that...
So I will try to take more time to grind myself further trough this... I will keep you all updated when I find out anything useful.
B.
ok, after some further research I found the following interesting information directly from the JAXA Kaguya-Team posted at the Telescope Review forum which directly addresses my question about coverage and release schedule of the Terrain Camera derived DEMs. As I already suspected, the bulk of the data seems to be still in processing. The interview sounds very promising although we will probably have to wait another year or so for the availability of full global coverage.
BTW.: can't wait for the Indian TMC DEMs which are announced to be even more detailed at 5 meters per pixel vs. 10 m/pixel for the Kaguya TC.
(However I would suppose that the 10 and 5 meter resolution does apply to the orthoimages only, not for the DEMs themselves because the process of photogrammetry (stereo derived DEM construction) usually needs a small window of 3x3 to 5x5 pixels for each DEM height value. That's why, for example the HiRISE Mars DTMs have a 1 meter/pixel resolution while the images they are derived from come with 0.25 m/pixel.
QUOTE
I asked Shin-ichi Sobue of the JAXA Kaguya –team the following questions. Here is the e-mail correspondence (released with permission):
“Q: Is the additional data set to be released on November the 1st 2009? What will it contain?
A: We will provide all available standard products from Kaguya mission instruments which is shown in here.
Q: The Kaguya Laser Altimeter Data (in resolution of 1 data point per 1 degree) has been kindly reseased on February 2009. Is the data produced by Terrain Mapping Camera (the full topographic data set) going to be released? How well is the Lunar surface covered with that data?
A: Terrain Camera (Not TMC, TMC is Indian) observed more than 90% surface of the Moon with 10 meter resolution. But, it takes additional 1-2 years to provide global DTM by TC. On the other hand, about LALT, we will provide 1/16 degree topographical map on November.”
“Q: Is the additional data set to be released on November the 1st 2009? What will it contain?
A: We will provide all available standard products from Kaguya mission instruments which is shown in here.
Q: The Kaguya Laser Altimeter Data (in resolution of 1 data point per 1 degree) has been kindly reseased on February 2009. Is the data produced by Terrain Mapping Camera (the full topographic data set) going to be released? How well is the Lunar surface covered with that data?
A: Terrain Camera (Not TMC, TMC is Indian) observed more than 90% surface of the Moon with 10 meter resolution. But, it takes additional 1-2 years to provide global DTM by TC. On the other hand, about LALT, we will provide 1/16 degree topographical map on November.”
BTW.: can't wait for the Indian TMC DEMs which are announced to be even more detailed at 5 meters per pixel vs. 10 m/pixel for the Kaguya TC.
(However I would suppose that the 10 and 5 meter resolution does apply to the orthoimages only, not for the DEMs themselves because the process of photogrammetry (stereo derived DEM construction) usually needs a small window of 3x3 to 5x5 pixels for each DEM height value. That's why, for example the HiRISE Mars DTMs have a 1 meter/pixel resolution while the images they are derived from come with 0.25 m/pixel.
i have to agree with phil the KAGUYA site was never very user friendly .Usable yes, but very limited for us amateurs / enthusiasts
the dem released was very quickly surpassed by the LOLA data .
the dem released was very quickly surpassed by the LOLA data .
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.