Digital Earth Weblog

Over the past week I’ve been playing with the free version of Google Earth. This has involved creating some proof of concept KML files for a client, and writing a prototype Java servlet application that exposes ArcIMS Image Services as KML. I love my job!

Several organisations on my radar are looking at how Google Earth might be used as a spatial delivery platform both inside and outside their enterprise. Herewith some notes from my experience so far.

Google Earth is a very cool 3D viewer, but under that shiny exterior it is basically a data presentation tool. In many ways, it has more in common with Adobe Acrobat Reader than it does with desktop GIS. Like PDF, KML is also a presentation format. It is not a suitable format for spatial data storage or transfer.

Google Earth is a thick client application, so you have to play within it’s boundaries. The good news is that a published data product (a KML or KMZ file) can be created in a very short period of time if the data that you need are already available. The trade-off is that you have less control over the way your information is displayed, and how the user interacts with it.

The default layout of the Google Earth interface is optimised to promote Google’s services. For example, the Search panel contains Local Search, Directions, and Fly To options. Fly To only works on town names, not location names like “Mt Everest”. You can turn off the panels that you don’t want to see by using items under the Tools menu, but in practice the vast majority of people will use it in its default configuration.

The Layers list contains a lot of vector data layers that may be completely irrelevent to your application. You cannot remove layers from the Layer list. Some of the data is also quite coarse.

Another key point is that when a user loads a KML file it shows up in the Places panel. Everything in the Places panel is editable by the user. Anyone can edit the KML file and save it under a new name.

OK, time to get into some more technical issues.

For those who are familiar with desktop GIS there are some fundamental differences between GIS project files and KML files:

• A KML file is not a single “project” level document that defines everything that you can see in the map display. Think of it as a bundle of one or more “layers” that are displayed as a “layer group”. The user is free to view your KML file at the same time as they are viewing other KML files.
• The vector and raster layers provided by Google are always available. You can turn off the vector layers using the checkboxes in the Layers panel, but you have no control over them from within a KML file.
• Each individual spatial feature in a loaded KML file is listed in the Places panel. Groups of like features are ususally contained in a single folder (similar to a GIS layer). This can make the Places panel almost unusable if a KML file contains a large number of features. Example: The 3D model of the Sydney Harbour Bridge is made up of 18,000 faces. When you open that folder each face is listed, and you’re in for a lot of scrolling!
• There is no concept of minimum and maximum display scales. All data is displayed all the time. This is significant for network links (see below).

Network Links

KML’s element is simple yet quite powerful, and deserves special mention. It lets you bring in data from external sources into Google Earth. If you have existing web map services you can bring in dynamically generated map images and have them overlaid on the terrain model. This works quite well, but the display of that data in 3D on planetary scale raises a few new, and not so new, issues.

Data extent: If you are viewing the entire planet Google Earth will ask for a map image covering the entire planet (-180,-90,180,90). If your data does not cover the entire planet you can use KML to restrict the output of your map server to a smaller extent.

Scale limits: KML has no concept of view scale limits so Google Earth will make requests to all active network links regardless of the current user’s view. Setting the minimum display scale on your map services is recommended.

Example: I set up a map service that provided all the roads in the state of New South Wales, and didn’t include a minimum scale limit. This map service was also reprojecting on-the-fly. Google Earth asked for a state-wide map and ArcIMS dutifully consumed 100% of available CPU on the server for several minutes while it produced a map image.

Response times: Google Earth likes its network links to respond quickly. If it doesn’t get a response in less that about 5 seconds it complains with a modal dialog box. Not very user friendly.

Server load: A 3D viewer invites the user to pan and zoom. If you have network links set up they will most likely use a view based refresh. When the camera stops moving Google Earth makes requests the network link. This can put a lot of stress on the map server. If I use my mouse to pan-stop-pan-stop-pan-stop I’ve just sent three requests to the map service, but I’ll probably only see the last one. You can prevent this by adding a one or two second delay after the camera stops.

Fixed layers: When you set up a network link to bring in a map image from an external map service the map image will display a fixed list of layers. There is no ability to switch layers on and off from the Google Earth end. The only value it passes through is the bounding box of the current view.

Querying overlays: There is no way to do a feature information query on an overlay obtained via a network link. Display only.

Styling overlays: The styling of the data provided by your map service needs to be significantly different to the styling used in a 2D web mapping application that uses a light coloured background. The imagery in Google Earth is generally quite dark so light coloured vectors, and light text with a dark ghosting, seem to work best.