OK - I guess what you've been saying is that while hundreds of millions of people have downloaded Google Earth all around the world, and have used it to prepare for and respond to natural disasters, find drug farms , protect the rainforest , bring attention to and spatially explain the Crisis in Darfur, even do Imagery Intelligence Analysis - that all of this is "just qualitative analysis."
Tough crowd.....
So despite all of those things, I still hear that Google Earth isn't analysis, and this almost always comes from staunch GIS shops.
Hey, I understand - I'm a GIS guy too. I guess what you're getting at is that unlike the GIS systems you've always used, Google Earth is more of a Geospatial Exploration System, and you want to be able to do some qualitative analysis - some geospatial analytics.
Ah, maybe some Geoprocessing?
Geoprocessing is a GIS operation used to manipulate GIS data. A typical geoprocessing operation takes an input dataset, performs an operation on that dataset, and returns the result of the operation as an output dataset. Common geoprocessing operations include geographic feature overlay, feature selection and analysis, topology processing, raster processing, and data conversion. Geoprocessing allows for definition, management, and analysis of information used to form decisions.[1]
OK, so what if we could extend that Google Earth user experience to be able to leverage your current or future geoprocessing capabilities?
I first saw the potential for this, before coming to Google, when Jack Dangermond and John Hanke co-presented at Where 2.0 last May.
They showed a great little demo of the Google Earth client communicating with the ESRI ArcGIS Server, but you could tell the communication was a little bit of a kludge.
They were using the embedded browser and the center of the Google Earth ?BBOX= NetworkLink information to pull the demo off.
That was before the Google Earth API (3D Google Earth browser plugin) was released.
Now however, we can actually build this application utilizing simple JavaScript and capturing key user events, then passing these events as real geometries over to the ESRI ArcGIS Server JavaScript API and do it all right in the web browser!
Durring that demo however, I was still unable to conduct the second required geoprocessing task on any drive-time-rings that were complex or that covered a large area - which was most of them.
It turns out, that there is a pretty significant limitation on geometries that you send Geoprocessing task queries on the ArcGIS Server if you're not running your application on the same server as the ESRI software.
It bombs out if the geometry in the query exceeds 2,000 characters (which is a browser limitation) and the only way around this currently is to complicate the ESRI JSAPI by deploying a proxy in ASP.Net or Java / JSP...
This is a shame, it really makes things more difficult than I'd like them to be for interacting with ArcGIS Server services - I don't think I should have to mess with Tomcat configurations to get things working...but alas, we do for now.
Ok, now off to the ESRI Federal User's Conference - I'll be demoing this application at the Google booth, so stop by and say hello and check it out and tell me how much you hate it in person :)
I promise to have some well commented source code and a link to try out the application up on Google Code ASAP!
Next up - Geoprocessing with some Open Geospatial tools on the backend.....stay tuned.