Maplet2FITS --configFile fitsConfig_orex_spc.ini RAD201.MAP RAD201-fullv1.fits
An example ini file can be found here fitsConfig_spc.ini.
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."
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
If you are converting a fits file with multiple bands, you can specify a particular band with the -b <band #>
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.
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.
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.
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
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
gdal_translate -of ISIS3 -tr 5 5 -co TARGET_NAME=Moon -co DATA_LOCATION=GEOTIFF tmpUnscale.tif INGV02_ORv1.lbl
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
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...