Google Mars HiRISE base images for Opportunity Options

[elakdawalla]

Because it has become a forum FAQ, I've created this sticky thread containing information on where to obtain new base images for Opportunity's traverse for Google Mars, and for discussion on creating new ones. I will continue to add links to new base image layers to this first post as they become available.

New users: Download this 4-MB kml file and open it in Google Earth
Then go to the last post in the Opportunity Route Map thread for the latest traverse map
You need to download the new KML file each time in order to follow Opportunity's peregrinations.

Google Mars comes with a color base image mosaic created from HRSC imagery. In addition, there is an inset full-resolution HiRISE image covering the area from the landing site at Eagle crater, through Victoria, up to the point between sol 2040 and 2041 (just west of Mackinac) where Opportunity drove off the map.

Unfortunately, this Victoria crater HiRISE layer included within Google Mars is not perfectly registered to the HRSC base map. As far as is known, there is nothing to be done about that. Both John Cody's image layers and Eduardo Tesheiner's traverse maps are aligned with the inset HiRISE layer included with Google Mars, NOT to the HRSC base map.

In June 2009 SFJCody posted a reduced-resolution mosaic of HiRISE tiles that cover the entire future traverse area including Endeavour's rim. I have made some small modifications to that map and have hosted it in a single file here (17 MB). Download the file, run Google Earth, select the Mars view, and File>Open the KMZ to view it.

In September 2009 SFJCody posted another HiRISE base image, this one at full resolution, covering the Western Route and reaching not quite all the way to Santa Maria. Here is a link to the kml file (4 MB). Here is a link to a zipped version if you'd prefer to have it locally (256 MB) and I also wrote a blog entry about it.

During the discussion below, in late 2010, I created a small tile that covers just the immediate area around Santa Maria. Here is a link to the kml file covering that region.

In February 2011 Eduardo Tesheiner provided another set of base images covering the area from Santa Maria to Endeavour's rim. Here is a link to the kml file. If you would like to work from a local copy, you can download this 75 MB zip file and unzip it to a folder on your drive, then open the file PSP_010341_1775_RED.kml within it.

All three base images can be loaded at once using this kml file (the same one that is linked to at the very top of this post).

[KrisK]

Lately I've been working on HiRISE GE extension of Endeavour rim, the area south of Cape York. As a result I uploaded this kmz example. The procedure was as follows:

1. cropped PSP_010341_1775_RED using JP2_PDS/PDS_JP2 ("Area" option)
2. converted JP2 to png using "convert" (ImageMagick)
3. loaded png to GE, tuned North, South etc. coordinates and finally saved as kmz

Surely this method is not optimal. As a consequence I have one big image being loaded so GE hangs a little bit while loading. But later it works ok At the beginning I wanted to use MapTiler (just as it was done in previous posts) but it produced strange results for this big png file. My tests with smaller example files looked more optimistic with that program.

Here are some screenshots:

http://www.flickr.com/photos/55907406@N08/...088526/sizes/m/

http://www.flickr.com/photos/55907406@N08/...088544/sizes/l/
http://www.flickr.com/photos/55907406@N08/...088528/sizes/l/
http://www.flickr.com/photos/55907406@N08/...088534/sizes/l/ (here it looks that I need to work more on that )


I decided to upload kmz maybe sbd would like to use it...
https://rapidshare.com/files/1768082589/tes...deavour_rim.kmz

[Tesheiner]

That sounds great!
But, as you said, it's not optimal given the file size; actually, my laptop almost freeze during 1-2 minutes and finally finishes with a big "X" (can't display) instead of the real picture. I'll suggest you to keep working with MapTiler but splitting the big source file into smaller (e.g. 8000x8000) pieces first.

At the beginning I wanted to use MapTiler (just as it was done in previous posts) but it produced strange results for this big png file.

Could you detail it a little bit?

http://www.flickr.com/photos/55907406@N08/...088534/sizes/l/ (here it looks that I need to work more on that )

That's due to small differences in the lat/long coordinates you are using (in relation to the map I made). I can provide you with some data that should solve it, if you want.

[KrisK]

Could you detail it a little bit?

Here you can see result: http://www.flickr.com/photos/55907406@N08/...320902/sizes/m/

Finally I decided not to use MapTiler. Instead I wrote my own bash script to create super_overlays. The following link was very helpful:
http://code.google.com/intl/pl/apis/kml/do...l#superoverlays
At this stage I can say that I almost there:

http://www.flickr.com/photos/55907406@N08/...795813/sizes/m/
As you can see there is a brightness difference between tiles. Have to think what is the origin of the problem...

Below is the area (size 2^n) that I want to overlay in GE:
width = 16384
height = 3x16384
so I have three squares 16384x16384. Currently I work with the first square.

That's due to small differences in the lat/long coordinates you are using (in relation to the map I made). I can provide you with some data that should solve it, if you want.

Yes please ...Previously I made the alignment mostly by hand now I have the following strategy:
1. take N,S,E,W out of LBL for full HiRISE product....DONE
2. recalculate N,S,E,W for my cropped area....DONE
3. add/subtract deltaLAT, deltaLON to perfectly match the existing overlay...TBD

So I suppose your data will allow me to finish step 3 right?