Effective digits of lat/lon created by phocube
Dear ISIS team,
I have create lat/lon band from a MiniRF cube, but the effective digts of lat/lon is not enough. E.g., the value of longitude can be 324.486, i.e. there are only 3 digits after the point, which makes its neighbours get the same longitude value.
Maybe some parameter can control the effective digits, to make it longer, but I do not know how to do this.
#2 Updated by Tammy Becker 7 months ago
It is not clear what you are using to report the pixel value that returns only 3 digits behind the decimal point (unless your value included zeros).
qview, campt (most of the ISIS applications) will report the pixel longitude values within the phocube output with 6 digits behind the decimal point.
Please note that ISIS computes the latitude and longitude values in double precision. When these values are stored as pixel DN values in an output cube, these values are converted to Float values. So, some precision is lost when used as a pixel value.
An example campt output report of a MiniRF phocube "longitude" output:
Group = GroundPoint
Filename = LSZ_00429_1CD_XKU_87S011_V1_S1_phocubeLon.cub
Sample = 612.5
Line = 10188.5
PixelValue = 10.665812 [THIS IS THE LONGITUDE VALUE IN FLOAT AS AN IMAGE DN]
RightAscension = 108.20589203854
Declination = 65.741032220033
PlanetocentricLatitude = -86.951395956375
PlanetographicLatitude = -86.951395956375
PositiveEast360Longitude = 10.665789508218 [THESE VALUES ARE THE ORIGINAL COMPUTED DOUBLE PRECISION]
PositiveEast180Longitude = 10.665789508218
PositiveWest360Longitude = 349.33421049178
PositiveWest180Longitude = -10.665789508218
#5 Updated by Hualiang Liu 5 months ago
Hi dear Tammy Becker ,
Thanks for your reply. I think I know where the problem was.
I have created lon/lat band (.cub file) by 'phocube', and in fact that was totally fine by this step. Then I used ‘ isis2ascii’ to convert this lon/lat band (.cub file) to an ASCII file (.txt), returning only 3 digits behind the decimal point for longitude (e.g., 324.486), but for latitude, there can be 4 digits (e.g., 39.2911). This problem was caused by the precision of 'isis2ascii', which was increased from 6 to 7 as shown in the history log of this command:
"Makayla Shepherd 2015-01-30 Increased precision of the DNs in the output text file from 6 to 7"
And also, this bug has been pointed out 3 years ago: https://isis.astrogeology.usgs.gov/fixit/issues/2098 .
So after updating my ISIS software to the latest version, I can get 4 digits behind the decimal point for longitude (e.g., 324.4863), which is enough for mapping.
Here is my tip for 'isis2ascii': may be you can provide a parameter allowing users to set the precision according to there own needs.