Google Mars HiRISE base images for Opportunity Options

[elakdawalla]

OK, we are almost there, but not quite. I downloaded MapTiler and ran Eduardo's selected of the Santa Maria image through it. In a matter of two minutes MapTiler generated 1000 tiles and associated KMZ files with a single KML file in the top directory. When I opened the KML file in Google Mars, bingo! It worked just as Eduardo said. The numbers for the corner coordinates aligned the tile nearly perfectly with the existing map (it's offset to the northish by about 3 meters, give or take a meter). So far so good. That is a solution that will work for people -- as long as they are willing to download 20 MB worth of data per 8000-pixel-square image tile.

But Eduardo suggested that I save everybody a lot of hard drive space and hassle by hosting the image tiles at the Amazon S3 server (where the Planetary Society serves large files) so that people don't have to download the entire enormous map. Using MapTiler I specified the location of the S3 server (http://planetary.s3.amazonaws.com), and it regenerated the tiles, KMZ files, and KML files. The top-level KML file looks like it points to the right place:

CODE

<Link>
        <href>http://planetary.s3.amazonaws.com/santamariatest/0/0/0.kmz</href>
        <viewRefreshMode>onRegion</viewRefreshMode>
      </Link>

However, when I try to open the local copy of the KML file in Google Mars, it does not *quite* work. (Please try it for yourself: here's the KML file.) It's really puzzling, because it's not a matter of a broken link. It is clearly finding the georeferencing information within the KMZ files to correctly locate the corners of all the image tiles, but the images are not showing up:


What is really weird is that if I point my browser to one of the KMZ files, it finds the image data just fine. For instance, try http://planetary.s3.amazonaws.com/santamariatest/0/0/0.kmz (the very same link listed in the code block above, which is the lowest-res tile, the "apex" of the image pyramid) for yourself, and you should see this:

It works! So I don't understand why opening the KML file does not work.

Here is what I did with MapTiler. Help me figure out where I am going wrong and why the image tiles aren't showing up.
Tile Profile: Select Google Earth (KML SuperOverlay)
Source Data Files: Locate local file. I started with a PNG version of the image Eduardo selected, the tile that overlaps Santa Maria; I set the black pixels transparent using Photoshop. Click on its name and "Georeference" button. Put in 4 coordinates listed by Eduardo in green text in his post above, in 'north south east west' order as software specifies.
Spatial reference system: I selected WGS84. I wonder if we should be specifying some Mars-specific projection here -- but WGS84 seemed to work OK for the locally stored version of the map.
Tile Details: Accepted defaults (min zoom 0, max zoom 5; Hybrid JPEG + PNG)
Destination: Result directory: I specified the name of a local directory (the path to the image plus the folder name "santamariatest", so in the end it was "C:\Documents and Settings\Emily\My Documents\Google Mars\james canvin's images\santamariatest"); Destination URL: "http://planetary.s3.amazonaws.com"
Viewers: Google Earth (KML SuperOverlay)
Viewer Details: I specified a map Title (this is just metadata)

[Tesheiner]

However, when I try to open the local copy of the KML file in Google Mars, it does not *quite* work. (Please try it for yourself: here's the KML file.) It's really puzzling, because it's not a matter of a broken link. It is clearly finding the georeferencing information within the KMZ files to correctly locate the corners of all the image tiles, but the images are not showing up:

It's working perfectly for me.
It takes some time to download the first time but all LODs are working.

[walfy]

It worked for me, too, but took awhile to download, though not a problem with patience. I would love to work on it too, but unfortunately, do not have the time now. Let's hope NASA gets on it posthaste!

Emily, maybe you need to refresh the KML file within GoogleEarth, as it might have a cached version of the KML file that's still linking to your own computer for the images. Just a guess, not really sure.

[elakdawalla]

Holy cow, suddenly, this morning, it worked! I think we have a solution that will work out for us!

My question now is: should we regenerate the first map extension from scratch? It would require someone (*cough* Tesheiner) to relocate the corners of the beginning image tiles. I would also think it would be better to regenerate the base images so that they are non-overlapping (which probably needs James' help). And if we are going to do that, and are doing all the map segments at once, I think we should try to match the levels among the different base images to make them appear seamless. This last step I can do very easily (by determining what levels adjustment is needed using the browse versions of the HiRISE images, then using a Photoshop macro to run it on the folder full of 8192 by 8192 chunks).

--Emily

[Tesheiner]

Lots of activity in this thread. I guess my map is finally going to be supplanted with something better!

Better maybe, but we simply would not be able to follow Opportunity's trek on Google Mars without your help.
For an "end user" such map overlay might look just line another picture but those who have worked (or tried to work) with multi-resolution images on GE should understand how much time it takes to get such map working without the help of an automated software. Thanks a LOT for the big effort you put on that map!

My question now is: should we regenerate the first map extension from scratch? It would require someone (*cough* Tesheiner) to relocate the corners of the beginning image tiles. I would also think it would be better to regenerate the base images so that they are non-overlapping (which probably needs James' help).

I like this proposal.
Just a remark about the non-overlapping tiles. Better test it first with e.g. two or three tiles, just in case the gap between them is visible on GE. If that happens, some overlap should be kept.

[elakdawalla]

Good point, we should test. I do think think that if you set corners to be slightly *inside* each other -- adjusting this at like the 6th or 7th decimal place -- then it should work at all levels of detail.

This is reminding me of something that was deeply maddening to me when I was first doing planetary GIS work in grad school, going between ISIS and ArcView. There were different conventions for what the corner of a raster image actually meant. For one piece of software, the convention was that the specified corner coordinates were at the extreme upper left, upper right, lower left, and lower right corners of the image. For the other piece of software, the convention was that the corner coordinates were at the centers of the corner pixels in the image. I do not remember for sure which was which, but I think it was ArcView that called the corner coordinates the centers of the corner pixels. This would make sense because it would prevent the possibilities of image-to-image gaps with extreme zoom that you raised.

[Tesheiner]

I do think think that if you set corners to be slightly *inside* each other -- adjusting this at like the 6th or 7th decimal place -- then it should work at all levels of detail.

Let's test it but IMO I think the corners should be calculated in a way that the whole north border of the new map matches with the base map around Victoria. For the example with Santa Maria I calculated the coordinates using Mars radius as I found in a web page with Google; now we should do it slightly different.

There were different conventions for what the corner of a raster image actually meant. For one piece of software, the convention was that the specified corner coordinates were at the extreme upper left, upper right, lower left, and lower right corners of the image.

For our case, I think it doesn't matter the convention IF the definition is kept the same from tile to tile.

[elakdawalla]

My point is that if the convention is for it to be the centers of the corner pixels, then if you specify the same lat/lon coordinate for the corners of two adjacent tiles, then the two tiles will *always* overlap by one pixel no matter what zoom level you use.

[elakdawalla]

Well, Tesheiner, you were right. I ran MapTiler on the other Santa Maria segment, using the same east and west coordinates as for the first one, using the first one's north coordinate for the new one's south edge, and doing simple arithmetic to arrive at the north coordinate. Obviously this is not the exact correct location for the "Santa Maria North" tile, because it is really 10% overlapping, but I wanted to test to see if it would really line up adjacent to the first tile.

It did not. There is a gap -- a rather big one, actually, more than 11 meters. So it looks like we will have to stick with the overlapping images.

[Tesheiner]

Strange...
I was expecting a gap of maybe a pixel or two but 11 meters is a lot!

I just did a different test to compare with your results. Opening the map with Santa Maria, I manually activated the option which enables opening the map folders to see the whole map structure. Then I deactivated the picture for LOD 0 (the top one) and all other LODs except 1. LOD 1 is composed of four individual pictures and there's no gap between them.


Then I checked the properties of those four images and the coordinates match each other exactly.

I'm puzzled.

[Phil Stooke]

Am I missing something here? I downloaded those HiRISE images ages ago when they were first made available to us, and they go right up to the rim of Endeavour. And they are still available, are they not? Why are we adding more? Or did the old files evaporate?

Phil

(EDIT - oh yeah - I guess I did miss something. Sorry Emily!)

[elakdawalla]

Are you talking about the reduced-resolution version? As I mentioned in the first post, SFJCody's first product was a reduced-resolution version that did go all the way to Endeavour. We're now working on full-res products.

[Tesheiner]

There is a gap -- a rather big one, actually, more than 11 meters. So it looks like we will have to stick with the overlapping images.

I see what's happening here. The borders' coordinates I posted before for the tile including SM were calculated using two different values (polar and equatorial) for the mars radius. But after generating the map overlays giving those coordinates as "georeference" I see that the tool changes the south latitude from the given -2.194771186 to -2.19456651200000; check it on the top level KML file. Perhaps that's a consequence of using WGS84.
Then, if you generate the second map layer north of the first one calculating the north/south coordinates based on the ones I provided on that post and not the ones calculated by the tool, the gap appears. But if you generate the layer based on the coordinates from the KML file, there's no gap.

So, perhaps we won't need overlapping tiles but will have to have a close look on how to properly calculate the tiles coordinates.

[walfy]

3) Calculate the lat / long coordinates of all four borders using the results of 1) and 2).

north -2.160015615
south -2.194771186
west -5.45866131
east -5.424110413

The northern border of the image of Santa Maria is at latitude 2° 9'36.06"S, according to GE. How do you turn that into the numerical convention you used above, such as the north -2.160015615 for 2° 9'36.06"S , as I'm attempting to fine-tune where the image is placed to match up more precisely with SJFCody's image.

Thanks for those numbers by the way! They are still very, very close!

[Tesheiner]

You can select the way GE displays lat/long coordinates and among the options are: degrees with decimals or DDMMSS.
Or you can manually convert the minutes and seconds to the proper fraction value.

Wait a minute before matching the picture to the current extension map. If we finally redo SFJCody's map I think the new map may have slight differences in relation to the current one which would affect the placement of the tiles covering Santa Maria.