ESRI Developer Summit Announced…

Posted by Dave Bouwman | Posted in ArcGIS Devt | Posted on 28-10-2005

0

I just saw the announcement for the ESRI Developer Summit over at ESRI.com.

Kudos to ESRI in general and specifically Brian and Art (and others I’m sure) for making this happen. The timing is great (a month after our first child is scheduled to arrive, so I think I can make it), and with a little luck I think I’ll be able bring my team along.

Looks like I’ll be seeing you all in Palm Springs March 17 & 18th!

Re: Problems accessing the site…

Posted by Dave Bouwman | Posted in dasBlog | Posted on 27-10-2005

2

On a whim I was poking around my dasBlog event log, and noticed that it was basically blocking all requests from everywhere. The feeds have been working, but I guess links from any other site would get a 404…

Time Code Message
10/26/2005 9:36:53 PM 501 Info ItemReferralReceived:
Item referral received for The GIS Longtail – Google, MSN, Yahoo and ESRI from target http://www.spatiallyadjusted.com/2005/10/dave_bouwman_on_the… originating at IP Address 67.176.39.182
10/26/2005 9:36:03 PM 503 Info ItemReferralBlocked:
Item Referral blocked for Unit Testing in ArcGIS… making headway from http://www.google.com/search?hl=en&q=john+cowardin originating at IP Address 67.176.39.182 because of “”
10/26/2005 9:35:56 PM 503 Info ItemReferralBlocked:
Item Referral blocked for Unit Testing in ArcGIS… making headway from http://www.google.com/search?hl=en&q=john+cowardin originating at IP Address 67.176.39.182 because of “”

That’s a little more exclusive that I was going for! It seems that checking “Use Movable Type Black List” currently bans almost all inbound links, for the informative reason of “” (see above). I originally checked this because I was getting a lot of Poker and other comment spam. I’ve un-checked it for now, and I’ll how it goes.

On “Missing the Nail”…

Posted by Dave Bouwman | Posted in Uncategorized | Posted on 15-10-2005

0

Not that I want to get all bent about someone having a different opinion than I have, but I think that Marc is missing one important thing when he says:

Dave Bouwman completely misses the nail – that Google and Microsoft’s entry into the mapping services game is potential bad news for ESRI derives from the fact that a HUGE GIS market/opportunity has just been swiped from ESRI (being the dominent GIS vendor)…

(this is from a comment over on James Fee’s “Spatially Adjusted” blog.)

Here’s the rub – in order for ESRI to have “lost” this huge market/opportunity, they need to have been in the running to “win” it. I contend they were not for (at least) one reason: Cost.

While ESRI is the 800 pound gorilla of the GIS industry, it’s small potatoes when compared with Google & Microsoft, both of whom are awash in captial. To the tune of billions of dollars. While I’m not totally dialed into the “Google Earth / Maps” conversation, I’ll go as far as to say that getting it likely cost serveral 10’s of millions of dollars. We can see that having deep pockets is the crux of the matter by looking at KeyHole. They had the underlying technology before joining Google, yet they were not able to cause this “paradigm shift” because they could not support the infrastructure / bandwidth / data acquistion costs to give it away. And the only reason we are discussing this at all is the fact that it’s free.

While ESRI may have the kind of cash to get something like this off the ground, I expect that they would want to see a return on the investment. To date, we really don’t see how Google is making this pay. Maybe I’m wrong, and everyone else is constantly clicking on ad links, but it seems to me that ads can may work for relatively low-cost services like email or search. The main cost for these services is server cycles, disk space, and a little bandwidth (per request). Google Earth is rather different because the data that drives it is very costly (i.e. you can’t harvest it by crawling the net, or cooking up some cool algorithms). Having worked at Space Imaging, and now Sanborn (both are data providers for Google Earth), I can tell you the data is not cheap – even when buying in bulk. And it’s not a one time cost – you need to keep it current. How much flak did Microsoft take because the data on Virtual Earth covering Apple headquarters was out of date and did not show the building? (link is to a great conspiracy theory that Microsoft “deleted” Apple!).

Then, once you have the data, you need to serve it – to millions of users. Bandwidth may be cheap, but it ain’t free. Think about it like this – how much more bandwidth (a “raw material” cost to the provider) does it take for an average Google Earth session vs. the average GMail session?

So – once you have the technology, you need serious cash to run it. While this may pan out in the end (I’m not a luddite, proposing that Google Earth will fail, and we’ll all go back to old-school workstation ArcInfo on a fridge sized VAX mini computers) the resources required to create the “market” and ride it out until location based search/services starts to generate big returns is beyond the reach of ESRI (in my opinion).

Thus, I would say that Google and Microsoft have created the opportunity – driven by their belief that location based services will pan out for them, and in the resulting increase in public “geospatial awareness” will help the entire geospatial industry in the long run.

That said, I hope that Google Earth does become one of the main data visualization tools – because I rocks – and the price is right.

Finally, I’ve heard from a few people that from time to time this site does not load – regardless of the browser being used. While it’s true it does not validate, it does work in all browsers I’ve tried, and I’ve got more interesting things to do that fiddle with it. I happen to use FireFox, and the site loads just fine for me, but if anyone does experience problems getting to the site or accessing the RSS/ATOM feeds, please let me know so I can hassle my hosting company. Email: (dave @ davebouwman dot com)

The GIS Longtail – Google, MSN, Yahoo and ESRI

Posted by Dave Bouwman | Posted in General | Posted on 10-10-2005

1

While doing some reading on last weeks web 2.0 conference over the weekend (very good coverage on Dare Obasanjo’s Blog – he has about 10 posts with details from the sessions), I got to thinking about the The Long Tail, of GIS, and particularly where Google Maps / Earth, MSN Virtual Earth, Yahoo Maps, and ESRI fit into the big geospatial picture. I did some doodling, and came up with a few graphs (which are totally unscientific) that I thought I’d share…

For anyone not familliar with The Long Tail concept, Chris Anderson wrote a Wired Magazine article on the economic models of some online businesses. The basic idea is that on the internet, there are as many users at the top of the curve (mass market) as there are spread out along the “long tail” of the curve (niche market), and thus it can be cost effective to pay attention to “The Long Tail”

So, in the GIS / Mapping realm, the Google/MSN/Yahoo offerings target the “mass market”. By contrast ESRI’s software, focuses “the long tail” of “professional GIS”.

The “Long Tail”

From this perspective, we can see that they don’t really even compete – their audiences are (for the most part) significantly different. I think that the folks spouting “the end is nigh” for ESRI tend to overlook this fact.

Being a GIS developer geek, I further divided out the “tail” section into 3 categories:

  1. COTS (commercial off the shelf) GIS : ArcMap, ArcView, ArcIMS
  2. Customized GIS :Customizations deployed on-top of the COTS product
  3. and Custom GIS Software : Totally custom software utilizing GIS components – ArcEngine or ArcWeb Services
Breaking down the tail

Since The Long Tail meme started out talking about business models, why not take a look at that too. The Google/MSN/Yahoo model is to sell ads to the eyeballs looking at the maps – thus the “viewer” (mostly web apps) is free. Given the large cost of hosting the services, buying and maintaing the data, we’ll see if this is a viable long term plan, but these companies have very deep pockets so it may take some time to tell if “mapping” is paying its way. ESRI however is more like the Microsoft Office model – per seat licensing of a software package. Granted it’s got a higher price point as compared to say Google Earth, but you can do a whole lot more with it. Many people have blogged this topic to death, and I’m not going to say more than it’s like comparing apples to socket wrenches. The apple is nice. The socket set is nice. Why are you comparing them to eachother???

Anyhow, while it’s true that ArcGIS costs more, ESRI is a stable, privately held company that’s doing very well (according to Jack Dangermond at the User Conference), so their model is chugging along just fine.

Per-seat pricing.

From here, I got to thinking about functionality vs usability. The Google/MSN/Yahoo products are designed to be usable by a mass audience. And the mass audience does not know about projections, or metadata, or file formats, or positional accuracy etc. Nor do they want to. If you look at the functionality of the sites, the assumption is that users want a map showing them how to get to someplace.
Contrast this with ArcGIS. ESRI’s approach is to build an enormous capability which can be used to address a very very wide array of problems. For example – ArcMap supports queries for (at least) 8 spatial relationships from a GUI interface. And if you want to get really crafty, you can use the shape comparison language to define any concievable spatial relationship! and expose it through a custom interface.

Breaking down the tail

Summary:
The idea that Google/MSN/Yahoo is bad news for ESRI is based solely on the whiz-bang-flash of the new mass awakening to the fact that things can be put on a map. Anyone who thinks that Google is going to extend Google Earth to the point of enabling a city to manage it’s parcel base is delirious. Apart from the fact that it’s very difficult, there is no benefit to them. While Google does have a staff of geniuses, this does not mean they can simply whip up a full fledged professional GIS system.
As for ESRI – I think they can only benefit from the increased attendtion paid to mapping in general, and GIS in particular. Once the public really starts to “get” maps, ESRI will be well positioned to facilitate “doing” something with the map – besides just plotting a point location.

ArcGIS Server GotDotNet Project…

Posted by Dave Bouwman | Posted in .NET, ArcGIS Server | Posted on 05-10-2005

0

After I uploaded the project yesterday, I realized that it had a dependancy on the “ClientSide” class library. So, since it was already a mess regarding the namespaces, and all of my source control “shadow” files, I deleted everything off of GotDotNet, made new “clean” copies of the projects on my system (outside of my source control), and uploaded them.

So here’s what’s up there:
OpenESRI.Utilities.ArcGIS.Server.ClientSide

Two classes – MapUtil & ServerUtil, all methods are public shared, so they can be called without instantiating an instance of the class. Both can be used from “client” applications, as they do not make many fine grained ArcObjects calls. ServerUtil basically creates a server context for you. MapUtil has functions for getting an IFeatureLayer or IRasterLayer from the Map, given a the BrowseName.

OpenESRI.Utilities.ArcGIS.Server.SOC

This has 2 COM classes which can be created on the SOC using ServerContext.CreateObject(”OpenESRI.Utilities.ArcGIS.Server.SOC.RasterUtil”) – RasterUtil and SelectionUtil. A third class – GeodatabaseUtil is a COM object which is used by RasterUtil, but is not currently setup so it can be directly created. These classes expose functions which have a lot of fine grained ArcObjects calls, thus it makes sense to run them in the SOC. As for functions, here’s the COM interface list for both classes: RasterUtil

Public Interface IRasterUtil
Function ExtractRaster(ByVal CutterGeometry As IGeometry, ByVal RasterLayer As IRasterLayer, ByVal ScratchFolder As String, ByVal RasterType As String) As IRaster
Function ExtractRasterToDataSetWithLookup(ByVal CutterGeometry As IGeometry, ByVal RasterLayer As IRasterLayer, ByVal ScratchFolder As String, ByVal LookUp As String, ByVal RasterType As String) As System.Data.DataSet
Function ExtractRasterToDataSet(ByVal CutterGeometry As IGeometry, ByVal RasterLayer As IRasterLayer, ByVal ScratchFolder As String, ByVal RasterType As String) As System.Data.DataSet
End Interface
SelectionUtil

Public Interface ISelectionUtil
Function SelectFeaturesByAttributes(ByVal Map As IMap, ByVal DataSetName As String, ByVal Query As String) As IFeatureCursor
Function SelectFeaturesByEnvelope(ByVal Map As IMap, ByVal DataSetName As String, ByVal Envelope As IEnvelope) As IFeatureCursor
Function SelectFeaturesByGeometry(ByVal Map As IMap, ByVal DataSetName As String, ByVal Geometry As IGeometry) As IFeatureCursor
Function GetSelectionSetByGeometry(ByVal Map As IMap, ByVal DataSetName As String, ByVal Geometry As IGeometry) As ISelectionSet
Function GetSelectionCountByGeometry(ByVal Map As IMap, ByVal DataSetName As String, ByVal Geometry As IGeometry) As Integer        
Function
GetSelectionAsInClausByGeometry(ByVal Map As IMap, ByVal DataSetName As String, ByVal Geometry As IGeometry) As String    &
nbsp;   
size=2>Function
SelectByAttributeAsSingleFeature(ByVal Map As IMap, ByVal DataSetName As String, ByVal Query As String) As IGeometry
Function SelectByGeometryAsSingleFeature(ByVal Map As IMap, ByVal DataSetName As String, ByVal Geometry As IGeometry) As IGeometry
Function SelectByEnvelopeAsSingleFeature(ByVal Map As IMap, ByVal DataSetName As String, ByVal Envelope As IEnvelope) As IGeometry
Function CombineFeaturesFromCursor(ByVal FeatureCursor As IFeatureCursor) As IGeometry
End Interface

There are also projects which have associated unit tests for all functions (Nunit). You’ll need to make changes to the test initializers so that it will hit your server, and use your data.