• Convert MAP

Instructions to convert a MAP file to other formats

Convert to FITS

• Use the AltWG toolset to get the proper format

Maplet2FITS --configFile fitsConfig_orex_spc.ini RAD201.MAP RAD201-fullv1.fits

• An example ini file can be found here fitsConfig_spc.ini.

• Notes from Ray Espiritu on 5 May 2020 about the ini file "It may look familiar as it has the same format as the nft config files you send me for generating MLNs. Format is KEYWORD#value. Notice that “//” denotes comment lines. This does not allow you to add custom keywords; the keyword has to exactly match a keyword that is normally populated in the fits header."

• There will still be some header information you will want to change. For this use ChangeFitsHeader, also part of the AltWG distribution toolset.

• More notes from Ray Espiritu on 5 May 2020 for "This tool allows you to add,delete, or modify keywords in the header. Run “ChangeFitsHeader –examples” to see examples for each operation (add, delete, modify, change). There is a limitation inherent in the fits format in that the new fits header cannot have a size difference of more than 2880 bytes from the old fits header. You shouldn’t encounter that if you are adding or deleting a handful of keywords."

Convert to GeoTIFF

Fits file to tif

• First, convert to FITS format (and update headers as necessary).
• Use GDAL to convert from FITS to GeoTIFF

gdal_translate -b 3 -a_srs RAD201-v5.prj -a_ullr -8510 8510 8510 -8510 RAD201-fullv1.fits RAD201-fullv1.tif

• An example of the prj file can be found here, and can be viewed with a text editor such as "vi". RAD201-v5.prj

• The -a_ullr is giving the bounds of the DTM in meters. The math is "Upperleft X = (Q*2+1) * GSD (in meters) / 2 * -1" and "UpperLeft Y = (Q*2+1) * GSD (in meters) / 2". So if the GSD is 20 m with a Q of 425, the math is (425*2+1) * 20 / 2 * -1 = -8510

• The -a_scale option will tell the geoTiff how to convert the DN value to physical units. See below to determine the value needed.

• If you are converting a fits file with multiple bands, you can specify a particular band with the -b <band #>

• GDAL works with both fits and pgm
• If your file has multiple bands, use the -b option to select a band

Use spheremapsB

Use this when you want to fix the map projection of the DEM. The output will be a PGM. Imbeded in the header of the pgm you will find relevant information, such as "REFERENCE RADIUS", HTMAX (height max), HTMIN (height min), and HTSCL (height scale, which is used to convert DN to distance)

BEFORE RUNNING spheremapsB, you need to make a bigmap wider than the area you want. Otherwise, slight rotations will make the edges of the pgm from spheremapsB be blank. Put the bigmap of interest in MAPLIST.TXT. spheremapsB requires a list of maps in MAPLIST.TXT, and if you use the maplets then HTMIN and HTMAX will be the min and max for the maplets. You want HTMIN and HTMAX to be the final product, not a somewhat irrelevant value used to build the final product. Plus, essentially arbitrary HTMIN and HTMAX will mess up the next set of calculations to convert DN to distance.

• Often you will want the "REFERENCE RADIUS" to be the datum for the object, and not the value of the maplet VLM (though this is subject to change).
• DN of zero is for "No Data"
• For 16-bit, the DN will be 1 to 65535
• To convert from DN to distance, you will take (DN - 1)*HTSCL + HTMIN. This value will be distance from the "REFERENCE RADIUS".

Set proper values

This is still a work in progress, but I think this is close (26 Aug 2020). When you initially create the tif, the "values" will be in DN space and you will need to convert them to meters. You do this by setting the scale (multiplicative) and offset (additive), and then separately unscaling the pixels. You can't do these processes with one command line, you have to use two.

• Because of the how the data is recorded (see spheremapsB above), the scale will be HTSCL and the offset will be HTMIN - HTSCL.

gdal_translate -a_srs INGV02_jrw.prj -a_scale 2.406482777E-03 -a_offset -3.627833373E+03 -a_ullr -4552.5 4552.5 4552.5 -4552.5 ING2EQ_DTM.pgm ING2EQ_DTMtemp.tif
gdal_translate -unscale -ot Int16 ING2EQ_DTMtemp.tif ING2EQ_DTM.tif

• The above example uses Int16, which will only write integer values for height (i.e. 1 meter accuracy), for sub-meter values, use Float32. However some programs cannot handle 32-bit.

• When using unscale, you also have to be sure you output in the correct format, so use -ot for that.
• Always check the output to make sure you have the proper values. Do this using gdalinfo

gdalinfo -stats ING2EQ_DTM.tif

Below are the gdalinfo stats from Mercury_Messenger_USGS_DEM_Global_665m_v2.tif

Band 1 Block=23040x1 Type=Int16, ColorInterp=Gray
  Min=-10764.000 Max=8994.000 
  Minimum=-10764.000, Maximum=8994.000, Mean=-478.084, StdDev=2265.894
  NoData Value=-32768
  Offset: 0,   Scale:0.5
  Metadata:
    STATISTICS_MAXIMUM=8994
    STATISTICS_MEAN=-478.0844394489
    STATISTICS_MINIMUM=-10764
    STATISTICS_STDDEV=2265.8943218627
    STATISTICS_VALID_PERCENT=100

• The "Min" and "Max" are showing as being accurate to the third decimal. They are not. They will only increment as whole numbers. They really are an int.

Convert GeoTiff to ISIS

Simple command to convert GeoTIff to ISIS. Below I give the whole set of GDAL commands from PGM to CUB.

gdal_translate -a_srs INGV02_Orth.prj -a_scale 2.276852228E-03 -a_offset -3.621564718E+03 -a_ullr -4552.5 4552.5 4552.5 -4552.5 ortho/INGOR2_DTM.pgm tmp.tif
gdal_translate -unscale -ot Int16 tmp.tif tmpUnscale.tif
gdal_translate -of ISIS3 -co TARGET_NAME=Moon -co DATA_LOCATION=GEOTIFF tmpUnscale.tif INGV02_ORv1.lbl

• Sometimes GDAL may want to use non-square pixels. ISIS will only use square pixels, so the command may need to look like this

gdal_translate -of ISIS3 -tr 5 5 -co TARGET_NAME=Moon -co DATA_LOCATION=GEOTIFF tmpUnscale.tif INGV02_ORv1.lbl

• The "-tr 5 5" would be to make 5 m pixel resolution.

Convert GeoTiff to FITS

Converting to FITS is simple once you have a GeoTiff. I've only opened in DS9, and am not familiar with DS9, but I didn't see any problems.

 gdal_translate -of FITS INGV02_EQv1.tif INGV02_EQv1.fit

Equirectangular Projection Requires special consideration

Email from Trent Hare on 22 Sep 2020. The below worked well!

John,
  So the Equirectangular projection bites again! Unfortunately, different applications have differing implementations. So although we had the projection correct, I wasn't thinking about the influence for the Standard_Parallel_1 correctly.  Usually the application does this all for you :-) !

(1) We have set (in meters):
-a_ullr -4552.5 4552.5 4552.5 -4552.5
defining the location of the image in the defined map projection Cartesian grid centered at 0,0. That is fine but the Standard_Parallel_1 (+lat_ts) only defines the "Latitude of true scale. Defines the latitude where scale is not distorted." https://proj.org/operations/projections/eqc.html Essentially that parameter squeezes the latitudes at that defined parameters such that there is no distortion.

(2) So to set the Cartesian system (grid) to where X=0.0 (m), that is again Longitude_Of_Center = 161.810785  (we are good here)

(3) And to set the Cartesian system to where Y=0.0 (m), that would be Latitude_Of_Center = -35.841220. So we could just set both
...PARAMETER["Latitude_Of_Center",-35.841220],PARAMETER["Standard_Parallel_1",-35.841220]

BUT... ArcMap, ISIS, PDS3 do not support that keyword! Note: GDAL and QGIS do support it though. Not sure about other applications.

---------------- PROCESS Update 

So for ArcMap and ISIS there is no means to define where Y=0.0 (in meters) for this projection. Essentially they hardcode Latitude_Of_Center to 0.0. They just support that parameter.

So let's keep ["Latitude_Of_Center", 0.0] and then offset the image in Y from 0.0 (using meters). Fortunately, Cartesian systems are usually easy to manipulate.

so current image range in meters for Y is from -4552.5 to 4552.5
Let's shift that from the equator to -35.841220 Latitude

1737400  * PI / 180 = 30,323.3504241494820694   ( meters per 1 degree)
next calculate the offset in meters (just for this projection):
-35.84122   ×   30,323.3504241494820694 = -1,086,825.87368903489973542

Now take that number and subtract the original Y offsets.
UpperLeftY = -1,086,825.87368903489973542 + 4552.5
LowerLeftY = -1,086,825.87368903489973542 + -4552.5

so the new command would be. 

gdal_translate -a_srs INGV02_jrw_Equi.prj -a_scale 2.273219713E-03 -a_offset -3.621564714E+03 -a_ullr -4552.5 -1082273.373689 4552.5 -1091378.373689 attempt1/INGV02_DTM.pgm INGV0W_DTMtemp.tiff

Final registration looks pretty darn good compared to the LOLA/Kaguya merge (DEM/hillshade).

maybe try that...