Project

General

Profile

Question #4906

THEMIS IR TIN product

Added by Rutu Rutu 6 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Applications
Target version:
-
Software Version:
Test Reviewer:

Description

Hi,

I downloaded .cub TIN product of THEMIS IR using JMARs. This is thermal inertia image. When I open this into Arc map it showing offset. This product file is not overlapping on any of the images. Can you suggest something?

Thanks,
Rutu

History

#1 Updated by Tammy Becker 6 months ago

  • Category set to Applications
  • Status changed from New to Acknowledged

#2 Updated by Trent Hare 5 months ago

  • Priority changed from High to Normal

Rutu,
We are going to need more information to provide help. First, I assume TIN is a Themis IR Nighttime image.

>>I downloaded .cub TIN product of THEMIS IR using JMARs
I don't know of a method to download a .cub using JMARS. As far as I know you can export and/or capture file formats like PNG, Jpeg, BMP, Tiff. None of these are geospatially ready (the Tiff is not a GeoTiff). To help re-assign projections this tutorial might help: https://github.com/USGS-Astrogeology/QGIS_tutorials/blob/master/QGIS_introduction_and_planetary_data/noproj.md

If it really is and ISIS2/3 cube, can you host it somewhere? In the label at the top of the file there should be a map projection group if it is truly in a map projection (and ready to be used in a GIS).

Perhaps you are talking about the THEMIS Nighttime controlled mosaics available in ISIS3 .cub (or GeoTIff) from USGS: https://astrogeology.usgs.gov/maps/mars-themis-controlled-mosaics-and-preliminary-smithed-kernels
If so, those should work in ArcMap automatically and overlay on most other GIS-ready Mars data.

let us know.

#3 Updated by Tammy Becker 5 months ago

  • Assignee set to Trent Hare

#4 Updated by Rutu Rutu 5 months ago

Trent Hare wrote:

Rutu,
We are going to need more information to provide help. First, I assume TIN is a Themis IR Nighttime image.

>>I downloaded .cub TIN product of THEMIS IR using JMARs
I don't know of a method to download a .cub using JMARS. As far as I know you can export and/or capture file formats like PNG, Jpeg, BMP, Tiff. None of these are geospatially ready (the Tiff is not a GeoTiff). To help re-assign projections this tutorial might help: https://github.com/USGS-Astrogeology/QGIS_tutorials/blob/master/QGIS_introduction_and_planetary_data/noproj.md

If it really is and ISIS2/3 cube, can you host it somewhere? In the label at the top of the file there should be a map projection group if it is truly in a map projection (and ready to be used in a GIS).

Perhaps you are talking about the THEMIS Nighttime controlled mosaics available in ISIS3 .cub (or GeoTIff) from USGS: https://astrogeology.usgs.gov/maps/mars-themis-controlled-mosaics-and-preliminary-smithed-kernels
If so, those should work in ArcMap automatically and overlay on most other GIS-ready Mars data.

let us know.

Hi,

THEMIS TIN is Themis IR nightime thermal inertia image. I attached the link of one of the stamps.
http://viewer.mars.asu.edu/planetview/inst/themis/I07476016#P=I07476016&T=2

If I understood the details properly I think the mosaics which you suggested are not thermal inertia products.

#5 Updated by Trent Hare 5 months ago

Rutu,
Thanks for the link to the data. Your question makes more sense now. I think stating that you downloaded in JMARS confused me.

It looks like only the "TIN" images are actually map projected (and happen to be in ISIS2 cube format). The others files on that page are PDS (.img) or graphical formats (.png) with no mapping labels.

So what's the problem...? It is essentially an ArcMap issue but other GIS applications (e.g. QGIS) will have the same issue. The file has a longitude range from 0 to 360 (LONGITUDE_SYSTEM = 360) but defines a center longitude as 0. This is fine in theory but GIS applications much prefer if the center longitude were defined as 180 (the center of the longitude range for this projection). For TIN data in this system, which happened to be below 180 degrees, all would have been good. But any TIN data in the 180 to 360 longitude range (using a center lon = 0) will need to be updated. for more see: https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,360.0.html

Fortunately, there is a somewhat of an easy fix. This can be fixed in ISIS3 or using GDAL. In ISIS3 you would need to import the ISIS2 image using pds2isis and set a new map projection on the file (or change the lonsys=180 and using the same clon=0). Overview of ISIS3 steps would include pds2isis, maptemplate, and map2map (to define a new projection). Once done, the ISIS3 cube should work in GIS apps.

Overview of GDAL steps (this method also overrides map projection but will also require the creation of a new file).

1.) Install Anaconda Python 2.7 (all OSs)
2.) From the anaconda prompt type "conda install gdal"
3.) grab this Python script from: https://github.com/USGS-Astrogeology/GDAL_scripts/tree/master/NewCenterLon_Equi
direct download:

wget https://raw.githubusercontent.com/USGS-Astrogeology/GDAL_scripts/master/NewCenterLon_Equi/NewCenterLon_Equi.py

4.a) run this fix to set the center longitude as 0 or 180. This will force GDAL to calculate new X offsets not just set the new center into a new GeoTiff. example run:

python NewCenterLon_Equi.py -clon 0 I07476016.cub I07476016_shift0.tif

To Center Lon: 0.000000
Original X: 13021100.000000 Shifted X: -8317791.108390

4.b) If your tools supports GDAL's VRT (virtual header), you can actually run this line which will fix the registration in the VRT header while still pointing into the ISIS cube. Make sure to load the VRT into your application - not the cube.

python NewCenterLon_Equi.py -of VRT -clon 0 I07476016.cub I07476016_shift0.vrt
...

Not as easy as it should be but hopefully it helps.

#6 Updated by Rutu Rutu 5 months ago

Hi Trent,

Thanks for reply.

Trent Hare wrote:

Rutu,
Thanks for the link to the data. Your question makes more sense now. I think stating that you downloaded in JMARS confused me.

It looks like only the "TIN" images are actually map projected (and happen to be in ISIS2 cube format). The others files on that page are PDS (.img) or graphical formats (.png) with no mapping labels.

So what's the problem...? It is essentially an ArcMap issue but other GIS applications (e.g. QGIS) will have the same issue. The file has a longitude range from 0 to 360 (LONGITUDE_SYSTEM = 360) but defines a center longitude as 0. This is fine in theory but GIS applications much prefer if the center longitude were defined as 180 (the center of the longitude range for this projection). For TIN data in this system, which happened to be below 180 degrees, all would have been good. But any TIN data in the 180 to 360 longitude range (using a center lon = 0) will need to be updated. for more see: https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,360.0.html

Fortunately, there is a somewhat of an easy fix. This can be fixed in ISIS3 or using GDAL. In ISIS3 you would need to import the ISIS2 image using pds2isis and set a new map projection on the file (or change the lonsys=180 and using the same clon=0). Overview of ISIS3 steps would include pds2isis, maptemplate, and map2map (to define a new projection). Once done, the ISIS3 cube should work in GIS apps.

Overview of GDAL steps (this method also overrides map projection but will also require the creation of a new file).

1.) Install Anaconda Python 2.7 (all OSs)
2.) From the anaconda prompt type "conda install gdal"
3.) grab this Python script from: https://github.com/USGS-Astrogeology/GDAL_scripts/tree/master/NewCenterLon_Equi
direct download:

wget https://raw.githubusercontent.com/USGS-Astrogeology/GDAL_scripts/master/NewCenterLon_Equi/NewCenterLon_Equi.py

4.a) run this fix to set the center longitude as 0 or 180. This will force GDAL to calculate new X offsets not just set the new center into a new GeoTiff. example run:

python NewCenterLon_Equi.py -clon 0 I07476016.cub I07476016_shift0.tif

To Center Lon: 0.000000
Original X: 13021100.000000 Shifted X: -8317791.108390

4.b) If your tools supports GDAL's VRT (virtual header), you can actually run this line which will fix the registration in the VRT header while still pointing into the ISIS cube. Make sure to load the VRT into your application - not the cube.

python NewCenterLon_Equi.py -of VRT -clon 0 I07476016.cub I07476016_shift0.vrt
...

Not as easy as it should be but hopefully it helps.

#7 Updated by Stuart Sides about 1 month ago

  • Status changed from Acknowledged to Closed

Closed inactivity

Also available in: Atom PDF