Brian Timoney writes in to Frank and I with news of a new demonstration project viewable in Google Earth. It shows various GIS resources useful in studying energy production in the US Rocky Mountains, but perhaps more important is that the layers prove the viability of serving static KML files from Amazon’s S3 service to create “passive, web-accessible storage”. The cost savings can be significant, writes Brian. He adds detailed commentary, of course:

There are a few aspects of this project that could lead to interesting points of commentary. Among them:

• The sheer quantity of public data: over 500,000 wells spread over four states, more than 25,000 lease polygons, township/section grid, big raster layers, etc. At the last Google Developer Day Bent Hagemark mentioned that it appeared to him that the <Region> + <NetworkLink> functionality was being underutilized. Well, he can consider this “Regions gone wild”.
• The fact that every well and every lease is linked to an online data source (for the wells, their respective states’ O & G sites; for the leases, the BLM’s LR2000 site) that has detailed drill-down information. The value-add is that each site has a different method for navigating its offerings, often in a text-driven, non-intuitive fashion. Here we have a single visual platform giving the user easy one-click access to five different online datasources. Since we’ve all been hearing about the GeoWeb meme during the recent spate of conferences, I’ll throw this out as my entry: a common, easy-to-use platform that intelligently links individual features to comprehensive data stores found elsewhere on the ‘Net.
• We’re serving up all of the KML using Amazon’s S3 service (idea inspired by Brian Flood’s Arc2Earth product). One of the implications of the <Region>/<NetworkLink> combo is that you get all of the capability of streaming large datasets without a web server having to actively parse out the user’s Viewport parameters and then deciding what data to stream back as KML. So now, passive, web-accessible storage is quite attractive not only because of the low storage/transfer costs, but more importantly, the management overhead of a webserver dealing with live requests and database uptime, etc., etc. is no longer an issue. Server maintenance and management are huge costs in both money, but more importantly, in person-hours. The IT implications are significant.
• “But we need database connectivity because our data is dynamic”. Really? How dynamic? Anything updated daily or less may be better written out as static KML. In our tests, it took a mere 8 minutes to write out all of the KML for 500,000+ wells from an ArcSDE database: a fairly large dataset, then, can be updated daily and reap all of the benefits of passive storage noted above. At the other end of the spectrum is a layer like Federal Land Ownership that, in a perfect world, is updated at best once a quarter. We took a snapshot directly from GeoCommunicator, tiled it up into Regions, and serve it up significantly faster than GeoCommunicator’s own web interface.
• One of the not-subtle inferences from the above remarks is that as consultants from a GIS background, we have to face the dominance of ESRI everyday in pitching our wares. There are a plethora of methods for converting ESRI data stores to KML—ESRI’s own ArcServer technology, Arc2Earth, open source data connectors such as OGR/GDAL and Autodesk’s FDO contributions, etc. The point being, with the economics and low-hassle factor of streaming large data via KML, many organizations don’t have to make an either/or choice but rather tailor the content/visualization platform to the various needs of different end-user groups.

[…] I’ll be at FOSS4G-2007 giving both a 3-hour workshop as well as a talk on implementing on-the-fly spatial analysis with Google Earth using PHP & PostGIS.

Now if they could just fix the professional use licensing model….

Well, Brian, as for your last point: I just noticed (and confirmed) there is a promo on for Google Earth Pro right now where you can get $100 off the $400 annual subscription price: Details here. Does that help?:-)

Notice the fancy use of styles to highlight incontiguous regions.