Kaguya TC image projection

Planetary Datasets
, ,
1

Greetings

I’m trying to visualize this Kaguya TC image (ID: TC1S2B0_01_05581S890E3121), which I’ve downloaded as a COG from this USGS website: USGS Astrogeology Planetary ARD

When I add to ArcGIS Pro (most current version) , the image isn’t appearing in the correct location. It’s supposed to be near de Gerlache Crater, however, it’s loading at near the Shackleton Rim.
I’ve tried to Reproject the tif in ArcGIS Pro and use gdal_warp, but to no avail.
Am i missing something glaringly obvious to get this COG to appear in its correct place? or any tips?

2

It does look there is an issue with the defined projection for that image (likely others). I will report it. But even with an override the image is still 2km off (~ +2087 meters in X). I assume that is since it is from an “uncontrolled” set of images. It could be easy to bring into alignment using manual image registration tools in Arc or QGIS. Download this VRT (header) and place it next to the original TIFF. Drag the VRT into ArcMap and see if it helps. It has an updated clon=180 (for the polar stereographic map projection) and the +2087m shift in X. To check out the updates crack the VRT open in a simple ASCII editor. I created the original using GDAL tools:

gdal_translate -of VRT in.tif out_clon180.vrt

now edit the VRT to update the map projection (and I applied that shift to the X offset).

TC1S2B0_01_05581S890E3121_clon180_shiftedX.vrt.pdf (1.9 KB)

NOTE: I had to add a “.pdf” to the file to get it to upload. After downloading rename to *.vrt (remove the .pdf extension). I also had to use this search page to get to the image. The image link above didn’t work for me.

1 Like
3

Thanks for your help, this worked for me in ArcGIS Pro : ]

In the event this happens again with this data, would this be the workflow?
Download COG > gdal_translate to .VRT > edit central meridian + x > check import

I found in the VRT where you set the central meridian to 180, but I’m not seeing where you set +2087 for the X.

4

So setting the new central_meridian = 180, really means it will apply a rotation around the south pole (really a rotation around the latitude_of_origin, which was set at -90). That makes it more tricky to apply any X/Y offsets. The offset here happened to be in X. On the map, after the rotation is applied, the shift is actually -2km (to the left). But we need to apply the shift before the rotation, so I had to apply a +2km shift to the VRT header.

Note this is likely unique value for this image and every shift could be different – again since these are uncontrolled images.

So with that out of the way. Here is the key to how images are registered in the Cartesian system as defined by the map projection. Note the first parameter is the X Offset in projected units (usually meters). Geotransform Tutorial — GDAL documentation

From the original ``<GeoTransform>``

-3.2661179801298999e+02, 8.1652949503247001e+00, 0.0000000000000000e+00, 2.2536214062896001e+03, 0.0000000000000000e+00, -8.1652949503247001e+00

I took the first number -3.2661179801298999e+02 + 2087.0, so this would be the updated ``<GeoTransform>``

2480.38820198701001, 8.1652949503247001e+00, 0.0000000000000000e+00, 2.2536214062896001e+03, 0.0000000000000000e+00, -8.1652949503247001e+00

Obviously, the decimal precision is a little crazy, but what was in the original. So where did 2087 m come from? I just used the measure tool in QGIS between the image and the LOLA Site11: de Gerlache rim DEM: PGDA - High-Resolution LOLA Topography for Lunar South Pole Sites

BTW, this is not normal – we should not need to update map projections. Most of the time, map projections are correctly and automatically transferred from one format to another. Now planetary data often has horizontal shifts, especially if not controlled.

1 Like
5

Thanks for the help. I’ve downloaded a few other images and one DTM since then, and haven’t had this issue again. I suppose it might only happen with select images for some reason.
A follow-up question I have on the DTM, though, is that there’s a lot of data that seems null, which makes sense considering they’re in areas that would be shadowe,d like deep craters.
The team’s LPSC paper stated that these shadowed areas were infilled with LALT data. Under inspection these look like they would correlate to null data values (DN -9999). Looking at the LBL file, there are a few parameters like “valid min” “valid max” and “min” “max”. There’s also a “dummy” pram which is set to -9999. Is the valid min really valid? is that what is supposed to be infilled by the LALT data and the dummy value is not valid? The “valid min” is -9989 as opposed to the “dummy” value, which is -9999.

6

Hmm - not sure which DTM you are talking about? There are many DTMs produced across the community. A link to the DTM and LPSC abstract would be great.

Even with that information not sure I could answer the question about the “dummy” value (or what I would call the NoDATA value). Using -9999 is a common value but it is up to the data provider and should be defined in the label. Some formats support multiple “Special” pixel values which make it harder for applications which may only support one NoData value.

7

Here’s the DTM that I’m currently using: Lunar Orbital Data Explorer - Data Product Page
The product ID is SLN TC PDS3 DTM Map Seamless V2.0. The LPSC abstract for the DTMs is here: https://www.lpi.usra.edu/meetings/lpsc2012/pdf/1200.pdf
In the abstract, they state their global DTM was supplemented with LALT data, and especially so in the south pole area where there are many shadows. Alone that makes sense, but there seems to be just a high amount of “No Data” that I questioned whether it had been infilled. I could be looking at the wrong product as well, but even after searching the Kaguya archive on the JAXA site I’m not finding another large area DTM.

8

Cool. I don’t think I have ever tested that S.Pole DTM before. If I were to guess, I would assume that DTM did not incorporate LALT, since there are so many NoData gaps as you pointed out. The confusing part is that abstract shows a S.Pole hillshade with no gaps…?

Just a recommended update for that DTM label. First, the label does use a “DUMMY” keyword which I don’t think is a valid PDS3 keyword. If you copy that line or simply change DUMMY to MISSING_CONSTANT, then more PDS3 readers will understand the NoData value in the image. This is because the GDAL reader (as used in ArcGIS and QGIS) only looks for MISSING or MISSING_CONSTANT. If nothing is found, GDAL will default to a NoData value of -32768 for a signed Int 16-bit data set. Thus, essentially ArcGIS or QGIS didn’t understand that the DUMMY = -9999 was supposed to be used for NoData – which is why you were seeing other odd values.

Here is my updated label (partial). Make sure to remove any extra files that were generated by ArcGIS or QGIS which might override the original label. Look for any .xml or .aux files to remove before reloading the edited label file. You just want the .img and .lbl before loading.

…

VALID_MINIMUM = -9989
VALID_MAXIMUM = 32766
DUMMY = -9999
MISSING_CONSTANT = -9999
MINIMUM = -4652
…

See attached image to show the DTM loaded with NoData set correctly.
—
If you can’t find another version which does have LALT filled, I would recommend relying on the LOLA DTMs (or lidar shots). Of course, if there are stereo LROC NAC or photoclinometry derived DTMs from LROC NAC for your area use those. Lastly there are Chang’e DTMs/DEMs for the Moon. I don’t have much experience with them. There are available to visualize and download from JPL’s Moon Trek. (switch to South Pole view, before searching for “Chang’e”)

image
image1103×842 324 KB

DTM credit: Lunar Orbital Data Explorer - Data Product Page

9

Thanks for the. For my project, I’m trying to compare various DEM/DTMs to each other using pc_align and assessing vertical differences with geodiff. As an example, I pc_align’d the LOLA 10m south pole mosaic (clipped to CR) and the Kaguya TC DTM (which we’re discussing). Based on your expertise, do you think the large spots of no data would affect the validity of pc_align results?
Here is a first run pass from my console. Note: I ran this before fixing the .lbl

image

These on their own seem to be reasonable? I also ran geodiff on the two products - the histogram seems to align well with the results from pc_align, except for the min and max values of the raster which I don’t know why are so much larger :thinking: do you have insight into how NoData values are treated in pc_align?

10

You should be fine, but maybe someone else will chime in. I would make sure to run with the updated label. Anyway, as far as I know pc_align supports a NoData value (or a data mask). This is likely because they also use GDAL for most raster formats.

Hopefully you will plan to write-up your results and share. Sounds very useful.