GIS and KML

When Google released Google Earth as a free download several years ago, people quickly learned what Keyhole Markup Language (KML). GIS professionals were quick to build translators to convert their data from several different formats into KML for viewing in Google Earth. The better of these tools let the user maintain the mapping symbology from their GIS software platform into the KML.

In the last couple of years, and enormous amount of geospatial data has been converted to KML to be viewed in Google Earth. In response, may geospatial visualization packages started to let users load KML into their own viewers. So where does KML actually fit into the whole geospatial realm? Will it become a standardized way to store geospatial data?

KML has a couple of things going for it. It’s based on XML and is well documented. It represents a pretty good method for encoding spatial data and symbology (and, to a lesser extent, attribution). But by far the biggest thing KML has going for it is that it is native to Google Earth. To that end, KML is really oriented toward defining displayable geospatial data. I have yet to see any code that performs any geosprocessing on KML, and there is a lot of overhead with KML then with, as an example, a shapefile.

So where does KML fit in compared to GIS data? I think that the answer to that lies with what people with a GIS background typically do with KML. They dynamically generate it from traditional geospatial data stores (shapefiles, geodatabases, etc), and they allow their own viewers to load and see KML files.

KML is serving the role that is usually found within GIS software. Whenever a file is loaded, a symbology class is assigned to it to define how the data will look in the map. Most people, other than programmers, never actually see this information. They only see the windows that let them alter the symbology of data, and the data itself. Some GIS packages allow users to save “layer” information that references the originating spatial data (an ESRI ‘.lyr’ file is an example).

So, in conclusion, it appears that KML represents what is typically in in-memory representation of geospatial and symbology data in most geospatial software applications, offering KML authors a very unique, open, specification at that level of representation.

Targeted Solutions with ArcGIS Explorer

ArcGIS Explorer is described by ESRI as being a “lightweight client for ArcServer”. Interestingly, ArcGIS Explorer is not actually tied to any other ESRI products. It and an SDK to develop customized tasks are free to download, and (as far as I can tell) free to deploy.

What this means is that ArcGIS Explorer can be used as an interface for all sorts of geospatial applications in a manner similar to Google Earth, Virtual Earth, and WorldWind using free and open source geospatial software components. Any processing logic that can be connected to any of these earth browsers can similarly be connected to ArcGIS Explorer. The current strength of ArcGIS Explorer in this category is the ability to customize the interface to hold any new toolsets.

I am really hoping to be able to work on some targeted geospatial applications that can very cheaply take advantage to this visualization platform.