Digital Earth Weblog

The exercise of creating a few KML files helped identify some of the issues around displaying WMS layers in the free version of Google Earth. There are improvements that can be made to Google Earth, and the WMS community also needs to make some changes if they want to see more wide-spread use of WMS.

Chicken and Egg

The ideal result would be for Google Earth to provide tools that would let any user discover and display WMS services. That means Google Earth would need enhanced KML editing and display tools that let any user:

1. Discover WMS services (requires service level metadata – Abstract, Keywords, etc),
2. Select the layers to display from the full list of available layers (requires layer level metadata – Title, Abstract, LegendURL),
3. Set the default visibility of each layer, and then
4. Have Google Earth communicate directly with the WMS (no “reflector” scripts required).

However, even if Google made it easy to find the WMS, my perception is that the metadata available in most public WMSs is not sufficient to make the display of their data layers a good user experience. Just seeing a long list of layer titles is not much use unless the user can accurately guess, or already knows, what the layers represent. From what I’ve seen the same issue applies to viewing WMS layers in desktop GIS like ArcMap, so this is not just a client issue.

Until there is a large user base demanding better WMS services I don’s see the quality of the WMS metadata improving. Google Earth has a large user base and could definitely drive demand for WMS, and that would be a very good thing.

Given that we have a chicken and egg situation, this wishlist tries to focus on the changes that could make a difference in the shorter term. My assumption is that the people who are creating KML that uses WMS layers are likely to be the people who publishing the WMS, and therefore creating a few reflector scripts is not beyond the realm of possibility.

Google Earth

Legend Icons

Right now, the best bang for buck enhancement to Google Earth would be to allow (legend) images to be displayed in description area of each network link. If included in the KML it would display the image below the <Snippet> or <description>:

The KML might look something like:
<LegendIcon width="100" height="200">   <href>http://www.example.org/legend.png</href> </LegendIcon>

Loading Overlays

Personally, I find the red “loading” image that appears, when overlays are being requested, to be a bit over the top. I’d prefer to see a one or two pixel semi-transparent line drawn around the extent of the overlay and the status text displayed outside the map display pane.

Refreshing Overlays

There may be a bug in the refresh code when the browser pane is activated (it may be my refresh settings). Google Earth 3.0.0529 beta. To repeat it:

1. View the WMS Example 6 KML file in Google Earth. Wait until the map display stops moving and the network link has refreshed.
2. Click on the “National Parks Estate Layer” hyperlink, in the Places pane.
3. In the pop-up description window, click on the “ANZLIC Metadata” hyperlink. A web page is then displayed in the browser pane.
4. Close the browser pane by clicking on the [X] button (top right of the pane).
5. The map then refreshes the overlay image using the extent that was visible while the browser pane was open. Screenshot [296KB, opens new window].

Spatial Accuracy of Imagery

Several people have noticed that the high resolution imagery displayed in Google Earth does not align with vector data they know to be accurate. I’ve seen 10m-20m errors between vectors that represent street centrelines and the underlying Google Earth imagery.

This level of spatial error is not an issue if you are marking a place by hand, because the relative accuracy is all that counts. However, when data from external sources is converted to KML (either as KML vectors or through ground overlays) it is a big issue.

Direct Access to WMS

Once the state of the WMS metadata world improves then I’d like to see Google Earth offer direct access to WMSs. Although, as mentioned, there is an opportunity for Google create the demand.

WMS Publishers

WMS Discovery

It has got to be easier to find public WMSs! There needs to be a low tech approach, because we’ve all been waiting (at least in Australia) for centralised registries that always seems to be just over the horizon.

My suggestion is to run an XSL stylesheet over each of your capabilities file to produce an HTML document. Put that document on a public web server and link to it from a well known page. If Google, and other search engines, index these pages at least mere mortals have half a chance of finding your WMS. Hyperlinks are great things!

Of course, for that to work we need better quality…

Capabilities Metadata

Most people hate writing metadata, and WMS capabilities files are no exception. It’s usually the last thing that gets done when a WMS is published.

The WMS specification dictates what is the minimum set of elements required to create a valid capabilities document. Unfortunately, as discovered, that minimum set is not that useful in the Google Earth type scenario.

A few people in the OpenGeospatial community have been pushing for a commonly accepted “WMS capabilities profile”. The idea is to specify which of the optional elements must be provided in a capabilities document in order for it to be useful for a particular purpose.

I wholeheartedly agree with the idea of a WMS capabilities profile. From a Google Earth perspective the profile needs to enable me to run an XSL stylesheet over a WMS capabilities document and produce a functional, and usable, KML file. No editing should be required.

Repurposing capabilities metadata as KML has another significant benefit. It encourages the publishing of useful metadata content. There is no point defining a WMS capabilities profile if the textual content in the capabilities documents does not support discovery, or let the reader make decisions about whether a particular WMS fits their needs.

To those writing capabilities metadata, my suggestion is to treat it like writing content for a web page:

• You need to focus on writing for your audience, not your peers.
• Write it, then edit it until it is less than half the original size (I’m trying, really).
• Provide hyperlinks to more details information, if required.

Publish KML Files

If you publish a WMS consider publishing some KML files. The experience will be worthwhile. If you provide your own WMS reflector you can easily track how may hits on your WMS are coming from Google Earth.

Feel free to use any on the files that are part of my previous post.

Styling WMS Layers

As demonstrated in the previous post, WMS layers that were styled for display on white browser pages can be difficult to see when overlaid on satellite imagery. Consider providing a separate WMS for Google Earth that provides alternate styling.

I know this could be done using Styled Layer Descriptors, but I haven’t had time to think it through. The WMS reflector script could be used to pass that information back to Google Earth in the WMS GetMap URL.

Wishlist Ends

Well, for now anyway. :-) Thanks again to DEC for providing the WMS (you know who you are).

It took a big chunk of my free time to write this wishlist series. I now better appreciate what the free version of Google Earth is capable of, and when it makes sense to use it.

Thanks for reading. I hope you got something out of it as well. If you use any of the files provided in this write-up it would be great to get an email from you.

Previous posts:
» Part 1 – KML
» Part 2 – Network Links
» Part 3a – WMS, the process