A Geographic Nightmare

November 21, 2007

tags:
9 comments

Oren Eini talks about nightmare platforms, and so I got the urge to talk about my issues with the GIS platform we are using – ESRI ArcGIS Server 9.2. First, let me state that this is a very powerful (and expansive) product. In fact, there is practically no other product that offers the features and capabilities you get with GIS Server. You can do practically anything geographic/mapping related with it. 

The product was built in a way so that by default, almost anyone can create maps and publish them in a web application or a web service. ArcGIS Server is great if all you want is to create maps with ArcMap (ESRI’s desktop application that you use to, well, create maps), use Visual Studio to create a web-page from a template, and use that web-page to let clients view the map. Here is where the trouble begins for us developers. Thing is, if you want to create a real application, that is never enough.

The ArcGIS Server API for working with web applications, is called the Web ADF, and is composed from a host of server controls and libraries. I am sorry to say, that it is a horribly designed, badly documented piece of API. In other words, it sucks pretty bad. Now, I would be a bad sport if I didn’t give a few example, won’t I?

Let’s start with the server controls. What ESRI wanted you to do is drag and drop some controls on a web-page and then go through some wizards to configure the controls. That would be things like, the server address to connect to, the name of the map to show, etc. Now, if you wanted to do something as simple as letting the user change the map he is currently viewing, that should be as easy as changing a property on the Map control, right?

Well, wrong. You have no idea how much trouble we had to go through in order to accomplish this simple task, only for our solution to be broken again upon installation of Service Pack 1 (by the way, the service pack count for ArcGIS 9.2 has already reached 4). We had to solve this issue by browsing reflector for the source code, and then try to find out exactly which code we have to run in each of the Map control life-cycle stages in order to get the damned thing to work. Unfortunately, the release version has its DLLs all obfuscated, so we actually had to go and install the Beta version on another PC, so we can reflect the DLLs whenever we encounter a non-solvable issue. How’s that for a nightmare?

The drag-and-drop suckiness doesn’t end here. There is a control, for example, that’s called SearchAttributesTask. Now this control accepts a collection of layers and fields to search in (you type “bla” and you get to see all the buildings whose name contains “bla”). Now, guess what is the type of the property SearchFields for SearchAttributesTask? No, it’s not a LayerFieldCollection, or something. It’s a string. Yep, the control comes with a nice designer that serializes your choices to something like: SearchFields = “Buildings:::Name:::Size^^^Houses:::Area^^^…”. In order to programmatically change the fields you want to search in, you would have to go and write your own code to create this string serialization, which we did.

The rest of the API is riddled with bad design choices and bugs. Weird exceptions get thrown. You find out that there are 5 different classes that are called Converter in this API, in 5 different namespaces, which in some situations can definitely be used together. Documentation for most methods is something like: Map.GetFunctionalities – “Returns the functionalities of the map.” Oh really? Now I couldn’t guess that on my own. I should mention that since the initial release the documentation has improved a lot, but it is still no paradise. Recent documentation for this method (added since Service Pack 2, if I am not mistaken), explains that it returns a collection of IMapFunctionality. So why, why oh why, does this method have a return value of IEnumerable? This is a .net 2.0 only library, for pit’s sake, they can use generics. And they do, in many other places. Here, they don’t. This kind of API inconsistency can drive a man insane, I tell you.

Now, you could decide to skip the ADF, and go right ahead and use the underlying ArcObjects – lower level COM objects that are pretty much the base of every ESRI software, including the Web ADF. Many things will require you to do this anyway, since only ArcObjects expose the full power of ArcGIS. Using ArcObjects feels a lot more consistent. It is terribly annoying to use, but at least in a consistent way. This is an API, as all COM API’s, I venture, that relies on interfaces. A lot of interfaces. In fact, in order to accomplish a simple thing as adding a feature to a layer, you might have to get familiar with something like 8 different interfaces. Many times you are working with just the one object, which you have to cast as different interfaces in order to access specific methods (I believe the COM term for this is Query Interface).

Now COM is COM, can’t really come complaining to ESRI, right? Well, watch me. For the amount of money an ArcGIS Server license costs, a .NET developer like me could very well expect a decent .NET API to work with. The Web ADF is a .NET API, but it is hardly as powerful as ArcObjects are, nor is it any kind of decent.

To conclude, I would say that ArcGIS Server 9.2 might be a great, easy to use product for some users. But if you’re a developer that wants to create kick-ass, cutting-edge GIS stuff with it, you’re in for a world of pain.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

9 comments

  1. ekampfNovember 21, 2007 讘 23:36

    I sympethise… I had toi work with their damn COM APIs in the army.

    Then again, if you have a simple API how with the ESRI consultants and trainers and partner ISVs make money? 馃槈

    Reply
  2. kwhiteNovember 26, 2007 讘 15:28

    I agree. The API is horrible. I spend so much time trying to decipher it. Then again when I do get things to work, it can do some amazing things.

    The only other aspect of ESRI’s products I dislike is how they take some core basic functions and make them only available in the highest end products. Do I really need the most expensive product they have to run the distance function? (This creates a table of distances between all features of 2 layers).

    Reply
  3. JenerDecember 19, 2007 讘 0:05

    I dropped ArcGIS and ventured into Manifold.net.
    It is still not perfect, but at least allows me to work with .NET 3.5. And it costs only $400. It is the only GIS that is 64-bit.

    Reply
  4. ClintFebruary 6, 2008 讘 4:21

    I work at ThinkGeo a software company that provide .NET Mapping and GIS components. We have a lot of customers come to us after getting fed up with ArcGIS or MapObjects.

    You can download an demo copy with samples apps in C# & VB.net at gis.thinkgeo.com

    Reply
  5. CarolineJuly 17, 2008 讘 10:25

    I having working with ArcObjects for about 5 years now, I have just started venturing into the world of ArcGIS Server.

    I agree with all you have said, but I have also worked with the MapInfo products (MapBasic, MapX & MapXtreme) and I must say that ESRI is leagues ahead of MapInfo. I am not sure how much progress has been done on the MapInfo API’s, as I worked on them about 5 years ago – I have definitely been converted.

    So, I suppose we can do is try and remain as sane as possible, cause I know that the API’s will improve and become consistent.
    Let’s just hope that we have not been locked up in a padded room with fancy white jackets by then. 馃槈

    Reply
  6. You knowAugust 27, 2008 讘 13:50

    Clint is an owner at ThinkGeo! Conflict of interest…

    Reply
  7. NelsonJanuary 23, 2009 讘 15:15

    Clint obviously mentions that he works at ThinkGeo, so I’m not sure how conflicting his interests really are by comparison to what he already admitted…

    Aside from that, I don’t work there but HAVE used there product and it really is INFINITELY easier to use than ESRI’s ArbObjects and licensing requirements are leaps and bounds more realistic. There are some API issues but the people there are so friendly that they will certainly help you with any issues or road blocks you run into and at times even provide generic .proj solutions to demonstrate.

    Check it out for yourself and decide.

    Reply
  8. Eric LJune 16, 2009 讘 19:41

    Being a developer for over 15 years now, and 7+ in GIS, I would definitely have to agree with this post. Products like Geoserver and the spatial capabilities of SQLServer and Oracle may make ESRI obsolete if they don’t get their act together soon.

    Reply
  9. KlausAugust 16, 2012 讘 22:33

    ThinkGeo is a very good alternative. I ditched ArcGIS ArcObjects for ThinkGeo MapSuite and have never looked back.

    Reply