Microsoft Sphere for GIS: how would zooming in look?

From CNET.

At first glance Microsoft’s Sphere seems like it would be good for GIS. But then I started wondering how it would look after zooming in. The software would need to project a large sphere onto a smaller sphere, an azimuthal projection I suppose – but between two spheres instead of a sphere and a plane. The result, while interesting, might not be that useful. Microsoft must have some sort of evil plan for it though.

ArcGIS Extensions: Where’s the Market?

Entchev asks why there are so few third party GIS extensions.

Here’s a run down of barriers I see, in no particular order.

Fixation on Ownership
Most extensions are developed by contractors for large organizations. The terms of the contracts usually require the developer to relinquish ownership of all code they are paid write. While this sounds reasonable at first, ownership can be counter productive. Owners often lack the resources to maintain the code, much less license it to a broader market. If ownership were retained by the developer, a maintenance fee could be arranged. As the developer grows the install base, the cost per seat for maintenance should decrease.

Lack of Incentive for Generic Designs
It is cheaper to hardwire code for the original stakeholder’s requirements than to design generically in anticipation of a broader install base. We need to educate stakeholders so they realize how increased design costs can pay off over the life of an extension as savings on maintenance costs are spread across a larger install base.

Lack of Licensing
ESRI likes to point out how they extend ArcGIS using the same methods described in their documents for third party developers. They do not, however, provide any way to piggyback on the ESRI license manager. If third parties could contract with ESRI to generate keycodes for non-ESRI applications there would be more incentive for extension development. The accounting by ESRI could also provide a transparent way for maintenance fees to be structured around the size of an install base.

Fear of Competing with ESRI
If ESRI sees a useful extension, it often is not difficult for them to incorporate the same functionality into their core product (or one of their extensions). Developers realize this. If there were a legal instrument available restricting competition from ESRI, there would be greater incentive for third party extension development.

Lack of .NET Forward Compatibility
I’ve whined about this before. As Entchev points out, new service packs often break extensions. I’m not certain it is possible, but I’ve requested that ESRI change their policy files to allow more forward compatiblity. See enhance request NIM036896.

Collisions Between Extensions
Since the Map coclass lacks an extension interface analogous to ILayerExtensions, the only alternative is to use IElementProperties.CustomProperty on the map’s frame. If two different extensions do this, things can crash. See this for more context. Similarly, there can only be one ClassExtension per featureclass. More on that later.

ArcGIS Server Cloud Licensing

Hurricane Katrina’s Eyewall

Animoto is a startup company that had to spin up 5000 Amazon EC2 instances in one week. They started on a Monday with 50 instances and by the end of the week they had 5000. Then a few weeks later they were back down to about 100. If they were using using Oracle for their database or the enterprise versions of Hyperic or Zenoss for their monitoring how would they have been charged?

Thinking Out Loud has a good post about the difficulty of adapting per-cpu licensing models to the cloud.

Spinning Up in a Cloud
It got me wondering about what plans, if any, ESRI might have for deployment of ArcGIS Server (AGS) to the cloud. It seems likely that the AGS scalability bottleneck will soon be a result of licensing rather than technology. Maybe it is already?

I still don’t see any premiere AGS server sites that I can point people to. Is this due to the in-elastic licensing model?

Take, for example, an emergency operations center. On a typical day, the load will be very low. During an emergency event, the load will skyrocket. The licensing model needs to support adding CPUs during peaks without requiring payment for idle CPUs during low periods.

This doesn’t just apply to AGS. I really would like to see a site that hosted CruiseControl.NET where I could configure it to autobuild ArcObjects based assemblies and run unit tests. Figuring out a fair pricing model will not be easy.