Through trial and error, and by that I mean a lot of trials, and a lot of errors, I have come to understand that the Desktop version of Google Earth is much more forgiving than its Browser Plugin counterpart. For the project, we are embedding KMZ into a web page, and not providing a link to download and then view in the Desktop version of Google Earth.

There are a lot of companies out there that provide Google and Bing mapping services. Some even develop software that allows you to "easily" generate the Google Earth files. This information will benefit both software engeneers and those who create Google Earth files themselves. Some of this advice will even be meaningful if you are only producing KMZ for the Desktop.

• Do not use Windows Bitmap (.bmp) files. I know some of you out there are died in the wool Windows users. Yes, when you zip up the KMZ, the BMP files compress down, but why use 1,500 BMP images at 400 kb each when you can use 1,500 GIF images at 8 kb each? You can do the math on that one. At the end of they day, no matter if the KMZ is for Desktop or Browser consumption, you want the end-user to be served your files as fast as possible. I can take a 55 mb KMZ and turn it into a 4 mb KMZ just by converting to GIF. You could use a Photoshop Action, or if you have ImageMagick installed on your computer/server, write a very small bash script to do the conversion.
• Do not use Windows backslashes in your URLs to assets inside of the KML. Yet another Windows anomaly, no matter if it is C:\\ or Assets\ it does not matter. Guess what? Mac or Linux systems, Web browsers do not understand what the heck that backslash is. Don't use it. Ever.
• Do not bloat your exported KMZ file with useless garbage. For example, out of 322 mb (uncompressed) of assets, 110 mb of this was .log and .csv files that were used in the creation of the KML files. If your software is written to include these files in the generated KMZ, you are doing no one a favor, especially the end-user.
• Do not use spaces in file names. Not in the KML, not in the KMZ, not in the compressed folders, and especially not in the image file names. This is trivial to web geeks, but Linux Web servers do not like spaces in file names. Modern web browsers will see a space and URL encode it with %20, but the Google Earth Browser Plugin will not display images referenced if they have spaces in their names. Don't ask me why, but Google Earth Desktop has no problem with this at all. Spaces in names is a bad practice. I don't care if you use IIS or Apache, don't put spaces in file names.
• Do not use special characters in file names. Again, this is basic stuff to any web or Linux geek, but special characters, such as parenthesis or equal signs, are a no-no in folder and file names. And again the Google Earth Browser Plugin will not display images referenced if they have special characters in their names. Don't ask me why, but Google Earth Desktop has no problem with this at all. Stick with alphanumeric names, dashes and underscores. This is very basic Web Principles 101. These "rules" also happen to translate over to the desktop - both spaces and special characters.

Bandwidth, file space, RAM concers: This is mainly relavent if you are actually putting the KMZ files up on a web server - for public download or just to embed in a web page, that does not matter - you have got to keep the file size of the KMZ as small as possible. Even if you are giving the KMZ to someone, you do not want to give them a 233 mb file. In the case of embedding the KMZ and letting the Google Earth Browser Plugin do all the work, you are going to kill your bandwidth, and make your server work extra hard, if you are serving up large KMZ files.

Instead of placing the image assets inside the KMZ, place them on the web server and reference them with a FQDN (Fully Qualified Domain Name, starting with http://). So now you have turned that 4.2 mb file into a 700 kb file (remember it was originally over 50 mb with the bitmap and other junk files in it). Your web server processes and bandwidth bill will thank you for taking the time to do all this. Even if you have a dedicated server, there is no need for the extra processes and RAM usage required to serve up such large files. And if you need your file to be self-contained, then skp the FQDN image links, but you still end up saving your client and their end users a lot of time.

Post-processing concerns: This all leads to where I am now. I have been given huge KMZ files and been tasked with making them usable for a web audience. The following section might get a little technical, so if you are not comfortable with the command line I suggest befrending a nerd, geek, or server monkey. Money always helps but you could always go for the bear necessities in life - you know, like a case of Mountain Dew. Regular Expressions have a stigma, but they are the answer to everything needed to take a 50 mb (and larger) file down to under 1 mb for consumption on the web. Below are some code snippets, you can use them as a starting block. My Perl and bash scripts are specific to my needs, so they really won't help you much.

Of note: While the files provided to me (or you) may have never been intended to be used on the web, adhering to accepted practices would cut out 2.5 of the 4 steps below. If all that needed done was to modify the IMG SRC in the KML, Regular Expressions would not be required.

• First we need to convert those gargantuan bitmap files to GIF. If you create an Action in Photoshop, be sure to use Save for Web as it will convienently change all spaces to dashes for you.
• Second we need to sanitize (strip out) the special characters, my case requires parathesis sanitation. This is best left to sed and a shell script. Relavent code below:
  new_filename=`echo $filename | sed 's/[()]//g'`
  You can save even more time with your shell script by combining sed and ImageMagick, sanitize and then convert BMP to GIF. Or you can use Photoshop to automate the conversion. Totally up to you.
  $gif_filename=`echo $filename | sed 's/\.bmp/.gif/'`
  convert $new_filename $gif_filename
• Finally we need to modify the KML to match the new file names, with dashes, and without parenthesis. This could be done in any launguage, PHP and Perl being popular options. Whichever language you are using, you can use Regular Expressions to find and replace everything including those Windows-only backslashes, replacing them with your FQDN, swap spaces for dashes, sanitize parenthesis, and change the file reference from .bmp to .gif - all in one fell swoop. Here are the relavent lines of code. Obviously it is quite handy that in my case the width and height of each IMG tag was the same.
  while (m/(.*<img src=")(Profile[\\\/])(.+?)(" width="457" height="305" \/>.*)/sg) {
  $str =~ s/ /-/g;
  $str =~ s/[()]//g;
  $str =~ s/\.bmp/.gif/g;
  print $pre."http://domain.com/images/".$str.$post;
• The final step is to upload all your new GIF images and re-package the KMZ file. You can now delete the entire assets folder, in my case, "Profile" and zip it all back up. If you are using Windows you can edit the .kmz in place with WinZip or WinRAR, which is nice. If you are on a Mac, like me, here is a tip: When you zip up the KML and other folders (generally Placemark icons and 3D models) be sure and select just those items and not the surrounding folder! Mac OS X likes to make a new folder out of stuff you zip up, which can be annoying. Finally rename your zip to .kmz and you are all set. Test it in Google Earth Desktop and then upload and test it on your web server.

So why did we go to all this trouble? Let me ask you a question: Would you wait for a web site to load a 50 mb file in the background? What if it timed out? Would you really have the patience to try and load it again? Time matters to your end-users, and seconds matter on the web. Beyond this reason, bandwidth and CPU cycles are commodities that cost money in the web hosting world, a lot of money.

In conclusion: If your company produces Google Earth documents it behooves you to keep within established standards for web design and think about the people who will be using the mapping data the most. It also helps to have a better understanding of the idiosyncrasies present in the Desktop and Browser Plugin version of Google Earth; this is similar to understanding the finer points of designing for Firefox/Safari/Internet Explorer (thought to be fair, Google Earth issues are much less painfull).

Cut the bloat and be concious of demanding users, desktop, online, mobile, it does not matter. They want to see stuff now-now-now. These are not unreasonable expectations.

The single new feature promised in the DSi — as in "eye," or "individualization" — sounded like a throwaway gimmick.

The previously existing Pictochat and Download Play functions are applications as well, but it's two of the new apps — called just "Camera" and "Sound" — that really sell the DSi.