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).

[elakdawalla]

OK, now that I've posted the existing maps, here is a call for help with future ones. At her current pace, Opportunity will run off of SFJCody's high-resolution base map in about two months. He can't do the next map, and I tried but couldn't figure out how to make any region file generators work within the amount of time I allotted myself to spend on the project, so someone else needs to try to figure out how to do this!

The first step is to get the images. I can provide those, thanks to James Canvin, who processed the small piece of PSP_005423_1780 that covers the area around Santa Maria plus the entirety of PSP_010341_1775 which covers the rest of the way to Endeavour plus the entire western rim into 8192x8192 JPEG format subimages, each of which overlaps by 10% with the next. They can be downloaded here:

Santa Maria (PSP_005423_1780, 33 MB)
Endeavour 1 of 3 (PSP_010341_1775, 183 MB)
Endeavour 2 of 3 (PSP_010341_1775, 199 MB)
Endeavour 3 of 3 (PSP_010341_1775, 148 MB)

Then, SFJCody had the following advice to me on how to get these into Google Mars:

It's not complicated, but it is fiddly, time-consuming and sometimes annoying. James Canvin split the map-projected JP2 into 10% overlapping 8192x8192 chunks which I could overlay in Google Mars manually. I did this the standard way; temporarily making the overlaid image partially transparent in order to see the existing features beneath. Once each section was done I adjusted the brightness & contrast in photoshop to match the existing neighbouring HIRISE frame. There are brightness/contrast variations even within the frames so indivdual adjustment of sections was necessary to avoid any visible seams. Pieces that are on the edge of the HIRISE frame are set to GIF or PNG so that the black border can be made a transparent colour. Others are JPEG. As I went through this process of 'laying down tiles' I would switch off the earliest tiles, away from the 'work area' leaving only those immediately adjacent to the section I was about to add. That way I would have a reference for the alignment of the next section without overloading Google Mars by keeping too many 8192X8192 images switched on simultaneously.

Once all the full sized tiles had been created and georeferenced the next step was to turn the tile data (images and location references) into region files. I tried several methods and I'm not sure which is best: here are some of the references I used:

http://code.google.com/apis/kml/documentat...#workingregions

http://superoverlay.geoblogspot.com/

http://www.ogleearth.com/2006/10/super_overlay_t.html

http://www.maptiler.org/

Sometimes the region files created by software turned out to be buggy (they would switch on and off bits of the image so that at some elevation ranges it looked like a chessboard. These ones I tried to create manually using the method outlined in the first reference.

Note that, for the base map to be useful to Eduardo and all of us who follow his maps of Opportunity's progress, the images should NOT be registered to the color HRSC base map included within Google Mars, but instead to the low resolution HiRISE base map linked to in the first post in this thread.

[eoincampbell]

As far as is known, there is nothing to be done about that...

Which is so frustrating, I really appreciate your endeavors ,
I hope Google Mars catches up soon...I mean, shouldn't they ?...

[Tesheiner]

I'm wondering if it is really necessary to overlap the subimages? When I had the idea of making my GE version of route map I spent some time looking on how to make additional background pictures, specially on the topic of "region files". IIRC, GE splits their CTX and HiRISE overlays on subimages with no overlay so, in principle, there's no need for the 10% overhead.

Example: Load the CTX picture P01_001414_1780_XI_02S005W on GE by selecting first "Spacecraft Imagery > CTX Image Browser" then click on the yellow square corresponding to that image. Then click on "Load this image" on the pop-up window and have a look to the respective KML file structure.


PS: I'll have to include a link to this thread on future map updates.

[SFJCody]

I'm wondering if it is really necessary to overlap the subimages? When I had the idea of making my GE version of route map I spent some time looking on how to make additional background pictures, specially on the topic of "region files". IIRC, GE splits their CTX and HiRISE overlays on subimages with no overlay so, in principle, there's no need for the 10% overhead.

The only reason I ever used the overlap was because of my crude method of matching the pieces by eye. There are bound to be better ways to do this.

[Tesheiner]

matching the pieces by eye.

Wow! I knew that was a *lot* of work put on creating the map layer but not that much!

[BrianL]

Why can't Google do this work? Has anyone asked them?

[Stu]

They're too busy quietly taking over the world, one website, one byte, one pixel at a time...

Good idea tho, we should definitely try encouraging them to join in the adventure.

[djellison]

Why can't Google do this work? Has anyone asked them?

Is there any reason we should expect them to? Have YOU asked them?

[BrianL]

Because it seems like an obvious benefit to all users of Google Mars. And I would not be so presumptuous as to be the lead voice on this when I have had nothing whatsoever to do with this imaging to this point. I'm just putting it out there as an idea for consideration, because I think Google has the resources to take this on.

[walfy]

I just tried "stitching" in the first image. GE's image overlay tool is very clunky, very difficult to make a perfect match with the previous detailed overlay that we've been enjoying. I wish I had more time to monkey with this. Any reason why they have to be applied in these broken up tiles? Why can't the original large file be overlayed in one fell sweep? Probably an obvious answer somewhere...

[Tesheiner]

You answered yourself.

... the original large file ...

It's several hundreds of MB.

And back to the main topic everyone, here's a good reference on how to work with "region files" in GE. It's the key point to have an extended and high resolution map coverage on GE. It's not too complicated to implement but the process must be automated somehow since we are talking about dozens or perhaps a few hundreds of regions.

Working with Regions

[fredk]

I'm not familiar witht the images in question, but presumably the full hirise frame is much larger than we'd need to cover the proposed future route to Endeavour. Could it be cropped down to a single image that covers, say, a kilometre or a half kilometre on either side of the proposed route to Cape York? Would that be small enough to handle, without needing to piece together smaller subframes?

It would be nice to have the west rim of Endeavour as well, but that's still some time away for Oppy, and by then perhaps the folks at google will update GM...

[Tesheiner]

Could it be cropped down to a single image that covers, say, a kilometre or a half kilometre on either side of the proposed route to Cape York? Would that be small enough to handle, without needing to piece together smaller subframes?

So, we are talking more or less about nine square kilometers which, at 25cm/pix, corresponds to a picture 36000 x 4000 pixels big. Ouch! Too much for a single picture, I would say.

[elakdawalla]

The region file generators that make images for Google Maps take a large original image, like our 8192 by 8192, and chop it and/or downsample it into different versions that get displayed at different zoom levels. When you are zoomed way out, Google Mars might display the photo in a single tile whose source file is only 256 pixels square. When you zoom in some, it'll display tiles from it that were chopped into, say, 1024 by 1024 chunks, then downsampled to 256 pixels square. When you zoom all the way in, you'll see the screen tiled with 256 by 256 images at the original resolution. This vastly improves performance and is what allows you to sweep around and zoom in and out so quickly. It's a technique that GIS applications have done for a long time.