Google Mars HiRISE base images for Opportunity |
Google Mars HiRISE base images for Opportunity |
Sep 28 2010, 09:23 PM
Post
#1
|
|
Administrator Group: Admin Posts: 5172 Joined: 4-August 05 From: Pasadena, CA, USA, Earth Member No.: 454 |
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). -------------------- My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
|
|
|
Sep 28 2010, 09:33 PM
Post
#2
|
|
Administrator Group: Admin Posts: 5172 Joined: 4-August 05 From: Pasadena, CA, USA, Earth Member No.: 454 |
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: QUOTE (SFJCody) 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. 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.
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. -------------------- My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
|
|
|
Sep 29 2010, 02:51 AM
Post
#3
|
|
Member Group: Members Posts: 399 Joined: 28-August 07 From: San Francisco Member No.: 3511 |
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 ?... -------------------- 'She drove until the wheels fell off...'
|
|
|
Sep 29 2010, 05:58 AM
Post
#4
|
|
Senior Member Group: Moderator Posts: 4280 Joined: 19-April 05 From: .br at .es Member No.: 253 |
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. |
|
|
Sep 29 2010, 06:48 AM
Post
#5
|
|
Member Group: Members Posts: 813 Joined: 8-February 04 From: Arabia Terra Member No.: 12 |
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. |
|
|
Sep 29 2010, 07:59 AM
Post
#6
|
|
Senior Member Group: Moderator Posts: 4280 Joined: 19-April 05 From: .br at .es Member No.: 253 |
|
|
|
Sep 29 2010, 12:00 PM
Post
#7
|
|
Member Group: Members Posts: 530 Joined: 21-March 06 From: Canada Member No.: 721 |
Why can't Google do this work? Has anyone asked them?
|
|
|
Sep 29 2010, 12:51 PM
Post
#8
|
|
The Poet Dude Group: Moderator Posts: 5551 Joined: 15-March 04 From: Kendal, Cumbria, UK Member No.: 60 |
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. -------------------- |
|
|
Sep 29 2010, 02:11 PM
Post
#9
|
|
Founder Group: Chairman Posts: 14444 Joined: 8-February 04 Member No.: 1 |
|
|
|
Sep 29 2010, 04:58 PM
Post
#10
|
|
Member Group: Members Posts: 530 Joined: 21-March 06 From: Canada Member No.: 721 |
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.
|
|
|
Sep 29 2010, 07:30 PM
Post
#11
|
|
Member Group: Members Posts: 404 Joined: 5-January 10 Member No.: 5161 |
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...
|
|
|
Sep 29 2010, 09:07 PM
Post
#12
|
|
Senior Member Group: Moderator Posts: 4280 Joined: 19-April 05 From: .br at .es Member No.: 253 |
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 |
|
|
Sep 29 2010, 09:24 PM
Post
#13
|
|
Senior Member Group: Members Posts: 4257 Joined: 17-January 05 Member No.: 152 |
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... |
|
|
Sep 29 2010, 10:01 PM
Post
#14
|
|
Senior Member Group: Moderator Posts: 4280 Joined: 19-April 05 From: .br at .es Member No.: 253 |
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. |
|
|
Sep 29 2010, 10:12 PM
Post
#15
|
|
Administrator Group: Admin Posts: 5172 Joined: 4-August 05 From: Pasadena, CA, USA, Earth Member No.: 454 |
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.
-------------------- My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
|
|
|
Lo-Fi Version | Time is now: 9th October 2024 - 07:27 AM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |