Digital Earth Weblog

While playing with the free version of Google Earth I started a list of enhancements that I’d like to see in the product. The desired outcome is to make it easier to use Google Earth as a spatial data delivery platform, without impacting on the collective end user experience.

Adding features increases complexity so I’m conscious of the impact that the items on my wishlist might have on the end user. Given that the vast majority of users of the free version of Google Earth are not familiar with GIS, and nor should they be, maintaining ease of use is a top of the list requirement.

KML

The KML editing tools in Google Earth enable anyone to create useful KML files without having to see a line of KML. I’d like to see a few enhancements to KML that would improve what can be done behind the scenes.

KML Schema: A post on the Keyhole BBS suggested that a schema for KML is forthcoming, which is great news. I can only add voice to the chorus. Relax NG or XML Schema would be fine, thanks. :-)

Having a comprehensive XML schema for KML will make it a lot easier to create KML documents using schema aware XML editors. A KML schema will also make it easier to create XSL stylesheets that transform other XML formats into KML. Those of us who write code that generates KML will really appreciate the ability to validate our output.

Documentation: The documentation and tutorial were useful to get started, but I found the descriptions of some of the elements a little brief. I’d like to see some more detail on the thinking behind the each element and how it can be exploited.

For instance, the <Schema> element is a mechanism for extending KML. This element may have the potential to raise KML from a presentation format to a useful data storage/transfer format, but there is very little information on how to use it.

There are also a few simple errors and omissions in “Version 2.0 for Google Earth Client Version 3.0” of the KML documentation. Examples:

1. The name of the <snippet> element should be <Snippet>,
2. There is no description for <viewBoundScale>, and
3. When viewed in Firefox there are broken internal links in the documentation page (e.g. href=”#styleUrl” and name=”StyleUrl” don’t connect due to case sensitivity).

Metadata: There is no provision for storing metadata within KML files that describes the “what, when, who, where and how” of the KML content. The geospatial world has traditionally tried to solve this problem with formal metadata specifications, and centralised metadata registries. Experience has shown that it is very difficult to get quality metadata within a single organisation, so attempting to do so on an Internet scale would be a waste of time.

I must admit that I’ve got mixed feelings about asking for metadata elements in KML. Everyone agrees that metadata is useful, but few people actually supply it, and even fewer provide high quality metadata, so why bother. Well, as the number of KML file available on the Internet grows it will become more difficult to find those that fit your requirements (fitness for purpose), to identify their origin (attribution), and the legal beagles in some organisations will demand the inclusion of copyright and disclaimers.

Given the way KML files are passed around like hyperlinks it would be better to include the metadata in the KML itself, rather than store it separately.

Fitness for purpose: Now, Google seem to be OK at this search thing, so I’m sure they’ll make it easier to find KML files. However, right now it’s not that easy. There are a few well known websites that offer downloads. If you use the Google search file type hack you’ll see that there is very little descriptive information about KML files. You get even less if you change the file type to “kmz”.

http://www.google.com/search?q=kmz+filetype:kmz

The simple approach would be for Google to index the content of the <description> elements within a KML file. The addition of a top level summary element might also be useful. Sometimes the text that you wish to display to the user, via the <description> element, is not what you’d use as an abstract or summary.

Attribution: When I’m looking at spatial data I always like to know where it came from. I think the metadata elements in the Atom format would be a good start for KML. If a link to formal metadata is required it can be included in the document metadata (see atom:link).

Transparency: Looking at some of the KML files that are floating around the Web it is obvious that people have created GroundOverlays using images that were designed for display on web pages with while, or pale, backgrounds. That’s not a complaint, I’ve done this myself.

The problem is that in order to create a nice looking overlay you have to use transparency for the entire GroundOverlay image, and that reduces the visual impact of the parts of the image that are of interest. If I’m interested in roads I probably don’t want those roads to be semi-transparent by default. It would be ideal if the <GroundOverlay> would allow you to specify one colour that Google Earth would then convert 100% transparent before displaying the overlay image. i.e. If I specify <transparentColor>ffffff</transparentColor> all white pixels in my overlay image would be made transparent, and the remaining pixels could be displayed at 100% opacity. Not totally, ideal, but it should cover most cases.

KML in Atom: I’ve been thinking about embedding KML in Atom feeds. We’ve already seen some examples of being able to subscribe to Network Links that are generated from news feeds. This lets you visualise what is happening where. Combining the news content with the spatial content would seem to be a useful next step.

The grey matter washing machine is still in spin cycle on this one, so if anything useful is extracted I’ll let you know.

I’ll post some more wishlist items on Network Links, and support for WMS, over the next few days.

Later posts:
» Part 2 – Network Links
» Part 3a – WMS Support, the process
» Part 3b – WMS Support, the wishlist