In anticipation of the release of Arc2Earth, I asked Brian Flood about his take on KML, Google Earth, the relative strengths and weaknesses of both, Arc2Earth’s features and what’s in store for the future.

Ogle Earth: Just quickly, how did you get involved in GIS and what is your day job?

Brian Flood: I work at Spatial Data Logic (Somerset, NJ), a company I helped start several years ago. We provide workflow and GIS software for local governments throughout the state.

OE: Arc2Earth takes the output of the most popular GIS analytical tool and puts it into the most popular GIS browser. When did you first see this as an obvious market niche in need of filling?

BF: I was impressed the first time I saw the Keyhole viewer years ago, although it was hard not to be when comparing it to the other viewers back then. When I first saw Google Earth it was truly awe inspiring. But I think what really did it for me was the very first Network Link hacks that started showing up soon after the GE release last year. When I usually see stuff like that, my first reaction is to tear it apart and see how it works. In this case, how they worked and more importantly, what they meant to GE as a viewer of external data, was the main cause of the “light bulb” going off. Most of the initial work was related to ArcGIS Server and Network Links however, it soon became apparent that a desktop converter would be a better first step. From there, it was all about integrating as deeply as possible with ArcGIS.

The last thing that sealed it for me was the amount of comments about Google Earth that came from non GIS users. There are many, many fringe GIS users out there that would benefit from an easy to use and high performance viewer that was already filled with plenty of base data. That niche should have been filled years ago.

OE: There are other converters out there. What does Arc2Earth do that the other ones do not? (And how is it different from Safe Software’s offerings? Are they your main competitor?)

BF: There are several other utilities for converting GIS data into KML format. Some are free, some are inexpensive and some are part of larger data translation products. We think A2E has a lot more features and is more tightly integrated with ArcGIS then the competitors. Also, the initial price for A2E will place it in the under $100 range, so you can judge for yourself if the additional features are worth it.

So a quick list of features not available in the other products:

Map Export

* Single Image Overlay – Map or PageLayout

* Multiple Layer Export – exports all or selected layers as vector or raster in one export. Creates folders and TOC

Layer Export

* Export Raster data

* Export any layer as a GroundOverlay

* user defined format and resolution for the overlays

* Labels – Uses the ArcGIS Label Engine for label text (includes expressions, complex scripted labels and custom label class extensions).

* TIN Layers (all node, edge, and face renderers)

Renderers/Symbology

* Marker symbols are exported as images so they appear in GE

* Chart Renderers (Pie, Bar, Stacked)

* Per Features renderers – images for each feature, good for a small number of features where you need to maintain the ArcGIS symbology

Ad Hoc Graphics

* Export all or selected graphics on the map * Allows for very flexible markup of GE

* Export the graphic as a raster or vector (with per graphic extrusion options)

* Label and InfoWindow for each graphic

* Options for each graphic are stored inside the MXD file so you do not have to redo them every time

Open KML

* Option to maintain complex Folder structures as well as combine all geometries together (which is all the other imported will do)

* Imports styles and complex marker symbols

* Open a KML/KMZ from any internet URL directly

* Open and maintain Network Links inside KML files. This will refresh data inside the feature classes based on a time period of viewing extent. The other importers will ignore this tag

* InfoWindow Balloon Tool

Miscellaneous

* Options file – Load and Save options file for each export. No need to re-enter all of the options each time

* Legend – AdHoc, PageLayout or user defined image for the legend. You can preview and save the legend image to create your own more complex version

* Shift X/Y – global shift of data when the underlying GE data is slightly off. The KML file is marked so the process can be reversed

* Geoprocessing tool – include the KML export process as part of a Geoprocessing Script, Tool or Model. You can use an option file to make sure all of your settings are applied automatically

OE: How’s KML stacking up as a geospatial markup language vs. shapefiles, GML, GPX etc? What’s KML’s biggest weakness?

BF: KML is a good format but I’m not sure it can be compared, at least in an apples-to-apples sense, with other spatial data storage formats. Many data formats (like shapefile, coverages or geodatabases) do not contain style or symbology information that control how the data looks in the client software. In this regard, they just contain data and in some cases, how that data relates to itself. Something like GML supports both but does not contain some of the other features of KML, the primary of which is NetworkLinks. Having a runtime communication mechanism (based on open standards) directly in the format is quite powerful and is what allows for some of the more complex KML files to exist.

IMO, KML’s biggest weakness is that it’s controlled by a single company, Google. It is open, in a sense, because you have full access to the published KML spec (well, almost the entire spec). Given this, you can build software that both produces and consumes KML. This is a great boon for anyone who wants to display their data in Google Earth but part of me wishes that the spec was based on something more open. I’ve kept this in mind when designing parts of A2E in case new versions of KML or something similar show up down the road.

OE: You’ve kept on adding features to A2E until the very end. Which is the most impressive, in your opinion?

BF: Whatever feature I’m currently working on :) Side projects are usually passion based so it’s really easy to get excited about a new feature. Ask any programmer and I’m sure you’ll find that they are at their most productive when the project is fun to work on. For instance, the very last item added to A2E was exporting TIN layers. A TIN is collection of node, edges and triangles that make up a larger topology. In this regard, they are slightly more difficult to work with when compared to say simple shapefiles or feature classes. Additionally, ArcGIS contains 10 separate renderers (elevation, aspect, slope etc.) that can all be used in conjunction with each other and some of these will break the base triangle data into even smaller polygons during the display process. Getting this all to translate into KML was difficult but ultimately very rewarding and will hopefully be useful in displaying data in GE (scientific analysis, terrain modeling or new building sites where the terrain has changed).

So I guess my point is that each feature added to A2E was at one point both my favorite and the one I thought was most impressive :)

OE: What feature you would most like to see added to Google Earth?

BF: Textured polygons – Most 3D viewers can apply an image as the fill for polygon surfaces, GE is currently missing this feature. The obvious use for this would be displaying realistic building or other landscape features. Most video games look exceptionally realistic because of the deep support of textures throughout the view. This is sorely missed in GE right now.

Asynchronous Network Links – currently, the network links are executed one after another in a linear fashion. However, they are inherently IO and not CPU bound and thus, perfectly adaptable to an asynchronous pattern. Nearly anyone developing complex Network Links would benefit from this change. Sites that returned multiple WMS layers or subdivided single WMS image (like what Mapdex is doing) would display much quicker. For the end user, everything would just appear a lot faster and if GE has taught us anything, it’s that performance does matter to the end user.

Below ground data – I would love to be able to display data that exists below the base terrain GE currently uses. There is a wealth of information (pipes, conduits, tunnels or undersea ground formations) that would great to show in Google Earth.

OE: What’s next in terms of features for A2E? Will it support ArcGis Explorer? NASA World Wind? Are you thinking of turning this into a business (or is that already the case?)

BF: We have lots of plans for Arc2Earth, much of which came from beta user’s suggestions and comments. Some of the more interesting are listed below:

a) 3D Symbols – This feature almost made the initial release but several bugs kept it out. Basically, you can select from pre-defined or imported (flt, 3ds, vrml) 3D Symbology and use them in place of existing symbology. For instance, if I had a layer that contained point data that represented water tanks, I could optionally use a 3D model of a water tank in place of the traditional 2D markers. You will also be able to use 3D markers in place of the ad-hoc graphics so redlining GE will become a lot more powerful.

b) Arc2Earth Server – This is a separate product that is built on top of ASP.NET. It will automate the process of building server side NetworkLinks that can be used to deliver much larger sets of data (or data that is constantly changing). It’s pretty lightweight, its purpose is not to become another piece of geospatial middleware but instead to act as a KML front-end to all of the existing ones. As it stands right now, a single HttpHandler connects to multiple data providers like ArcGIS Server, WMS/WFS and ArcSDE directly. It also has standalone KMZ provider so users can publish larger files directly from Arc2Earth to a server without any other software. Finally, we’ve had some requests to work directly with non ESRI products like Oracle Spatial and the new open source MapGuide servers. One cool feature is the ability to create map tiles in Arc2Earth that can then be published and then served into Google Maps as custom layers.

c) ArcGIS 9.2 support – representational cartography is a really nice feature added at 9.2 [the next version of ESRI’s flagship]. I’m currently looking at the best way to translate this information into KML. Terrains would be nice but by their very nature, they are enormous files. These would be best served through NetworkLinks

ArcGIS Explorer – well, AGX will natively support the full KML spec so anything you create in Arc2Earth will be viewable in it. Cheers to ESRI for building this directly into the product.

WorldWind – yea, I’d really like to use the Open KML support in A2E to create a WW extension that consumes KML directly. I’ve seen some KML stuff for WW already but I’m not sure if they go to the extent that GE does in reading the KML (NetworkLinks, nested folders, style information etc.)

Business – You bet, only time will tell if KML is the format of choice in the future but I think there are some much larger trends in play that make working in this arena very compelling.

Thanks to Brian Flood for answering these questions.