Got an E-mail from Brian Timoney (as did Stefan at OgleEarth), of the Timoney Group, that they have just published a new web site focused on Energy Production information on the Rocky Mountains area of the Western US. They are taking full advantage of KML’s ability to access remote servers to pull in more detail as you zoom in closer to an area of interest. This means you get access to a great deal of information without paying a performance penalty in GE. They did this by using both network links and regioning features of KML (technical information on Regions). See below for more details about the setup. Or, just go visit the new web site, and try out the layers. I particularly like their federal lands layer which lets you see an overlay with labels of the various different federal lands in the Western US (click on the “Federal Lands” placemark for a legend).
Here are some excerpts from Brian Timoney’s thoughts (OgleEarth just posted the full details) on the significance and quantity of the data in the new layers:
…over 500,000 wells spread over four states, more than 25,000 lease polygons, township/section grid, big raster layers, etc. ….every well and every lease is linked to an online data source (for the wells, their respective states’ Oil & Gas sites; for the leases, the Bureau of Land Management’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. … We’re serving up all of the KML using Amazon’s S3 service. … 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.