ERDAS Apollo vs ESRI ArcGIS Server

Lets face it, whatever benchmark results a vendor (*gasp*) publishes always draws a certain amount of suspicion. Luckily however, T-Mapy (Czech Republic) have just made available a detailed independant 20 page report on ERDAS Apollo vs ESRI ArcGIS Server.

T-Mapy have a long history with ESRI and now also ERDAS technology so they offer great perspective and expertise on both products. Michal Å eliga has done a wonderful job analysing performance and other metrics for serving a very large (290gb) 10cm aerial photo via WMS. Word of the day goes to “eyemetricaly worse” on page 13 :)

CarbonArc revisited

Jeff Harrison’s mass email caught my eye today with the free trial of CarbonArc. I had the pleasure of taking an early release of CarbonArc for a spin last year and while it was a good start there were a few key things missing from my point of view. Having pushed and prodded Mapinfo 9.5 support for use with our SDI, why not run the new CarbonArc 1.6 through its paces …

From the press release,

CarbonArc PRO 1.6 eliminates barriers to SDI usability through advanced SOA-based discovery, analysis, exploitation, transaction management and security tools for OGC SDI – directly from the ESRI ArcGIS desktop.

Instead of just regurgitating the release, the key question that always gets asked is … doesn’t ESRI ArcGIS already do all this?

Its a tricky question to answer because while on paper i could say, “Yes it does!”, in reality there are just so many annoying quirks and missing features, it quickly becomes a nightmare integrating SDI features into your normal ArcGIS workflow (which is what this is all about, right?).  So with fingers crossed, lets dive right in and see what i can find in 5 minutes flat …

The Good

  1. Well laid out and robust tool set which delivers fully functional WMS/WFS/WFST/WCS capabilities … with no mucking about required!. The thing just works.
  2. Very easy export to Shapefile tool
  3. Full featured filter encoding support … no black magic, user has full control
  4. Full access to the query string for all service types
  5. Caching of features / images when saving to project files

The Bad

  1. GML Integration will always be difficult given its a completely new ArcGIS feature source, but its still not up to the average users expectations I dont think. There is no attribute table, the features are independant of pretty much all other ArcGIS functionality so you are really left with GAIA functionality squished into an ArcGIS window.
  2. Web services request headers are devoid of any accept-encoding headers. I’m still pondering the choice of Expect: 100 requests … but i’m sure there’s a good reason in the depths of HTTP …
  3. The exclusive tool for CubeWerx “Identity Management Service” seems a bit strange as i’m not aware of any services that use this technology? Shoot me a link if i missed something!
  4. Lack of support for any WMS LegendGraphics. Users can choose from multiple Styles, but theres no way to actually view legend information which is a bit disappointing
  5. In the full minute spent trying, i wasnt able to get the WFST support working … i could get as far as the schema but as soon as i’d try to insert a feature the thing would just bail out.

I’m beginning to think the best suggestion would be to somehow merge CarbonArc WFS functionality with an automated export to shape on each filter response. This would allow excellent SDI WFS support, while still giving full ESRI ArcGIS functionality to users without having to reinvent the wheel (for things like the edit system). With the WMS/WCS support pretty solid, i think getting the balance of WFS right could mean the difference between a very promising product and one I would recommend to everyone using our platform.


Bravo .. Sebastian’s post. You made me chuckle and i don’t really know why :) I had actually not seen the projection render call, that is damn nice work Chris and Howard. Sebastian lists a few suggested improvements to the “service” which i whole heartedly agree. Geodesy/datums/projections/geoids/coordinate systems need not be some magical black art done only by PhD’s, or alternatively some magical program that you insert numbers in, get stuff out, but having no idea what just happened. Let there be light …

Second bravo goes to Flamingo mapping components, a new (i think) dutch GPL mapviewer. I happened to stumble onto these guys’ Flash based WMS client the other day and all i can say is hooray! Finally a flash client which is separated into components, has a neat interface and is actually configurable WITHOUT requiring Flash CS3 just to change the stupid service URI.

From the other side of the fence …

Like all good arguments, there are other sides. In what seems to be a two part OGC mini-series on Charlie Savage’s blog RE: problems with the OGC, I noticed a comment by Shane asking …

I’m surprised at the lack of outburst by the pro-standards community. This makes me think they are humbled by your views. I’d expect somebody out there to stick up for OGC and the other standards you mentioned. It would be intriguing to hear someone from DM Solutions or Ionic, for instance.

Even though i am not Ionic, DMsolutions … here are some thoughts from someone who thinks the OGC has created some pretty darned useful standards.

A retort to one of Charlie’s post if you will .. :)

Rendering Maps. The argument i often see with the WMS bashing goes something like, “WMS is slow. Who uses it in an Enterprise architecture. G/Y/M dont use it, therefore by my intelligent calculations, WMS must be useless”. Lets back up a second. If you want a high performance, slippy interface that can be easily cached, tiling is certainly your best bet. I get the distinct feeling that a lot of people forget the disadvantages of a tiled mapping cache,

  1. Fixed scales. The amount of people i see who simply generate their zoom levels based on GMaps is crazy. What about what your users want? If there are any papers detailing why splitting the world into 18 distinct zoom levels is ideal, please tell me. I’m yet to find one. One size will never fit all.
  2. Redundant data storage. Active caching mechanisms whereby caches are only populated once browsed is nifty, but it also negates somewhat the advantage of using a cache. Conversely, if you pregenerate your entire cache you are more than likely storing 80% (number plucked from the sky) more data than you need. We also arent even touching the storage of the source data either here, or considering the time required to maintain the cache when you are using volatile datasets.
  3. Lack of integration across clients. The whole benefit of standards it to enable cross-use, cross-communication amongst clients and servers. This is non evident amongst tile servers (beyond of course worldkit and openlayers). Sure, WMS-C / TMS are hopefully gathering steam at the moment, but if you are considering integration right now across a gamut of applications, nothing is better than WMS for transferring maps over the interweb to multiple clients. People seem to be losing sight of this purpose every day.
  4. And the kicker for me … Absolutely no customisation. Dont want that road layer? You better hope they duplicated the cache and removed them otherwise you’re in trouble. Want the map in a useful cartographic projection? Duplicate again! Hmmm, can you colour the cadastre yellow instead of red? No, but i can duplicate the cache again for you. I could go on, but you should get the idea ..

And finally, “Arbitrary bounding boxes” are your friends Mr Charlie! Let your users decide their output scale, not the magical we-chose-18-scales-coz-google-wanted-a-nice-single-square-tile-at-zoom-level-0 :)

Summing up, WMS is your friend regardless. Don’t toss it out with the bathwater just because you are using a cache with a slippy map. Implementing WMS and whatever tiling scheme you can easily abstract *AROUND* WMS will give you and your users the best of both worlds. The fact that you can quite easily use any random WMS server inside a tiling scheme surely highlights that the standard does have flexibility.

Time is at a premium at the moment so i wont reply to all Charlie’s points (especially sharing data because we could be here forever). All in all i can see his point of view however we need to remember that we can only work with what we have at the moment, despite their flaws. GeoRSS/Atom/OWS Context/KML ratifying are all coming, its just up to the rest of us to pick up the ball and keep running with it so this will never be true again,

Web mapping standards are going through a transitional state and haven’t kept up with GIS technology breakthroughs over the last few years.


Taking it to “the man”

Paul has graciously asked people to send him some queries to raise before the OGC technical meeting in Ottawa. In somewhat of an irony, it has been exactly 7 months to the day that my rant on client support was first posted.

Unfortunately my post still stands. To reiterate my point,

While i understand the importance of server compliance using tools such as CITE, if the subsequent clients consuming these services are poorly implemented, the end user surely has to question the point of it all.

It should be all about the clients baby! Unfortunately outside of the OWS-X and other demonstrator projects around the globe (where arguably the roles are clearly defined), vendor support is more or less a waste of time. What can be done in one application can’t be done in another. Seemingly simple items of the specs are broken, poorly implemented or simply forgotten. Vendors are all to quick to leap to the conclusion that their *insert propriety acronym here* could solve the problem, even though its entirely feasible to use the standards if their product simply supported it better. Oh and lets not forget that the product leaf-let clearly states that the protocol is supported … but by how much? Who knows!

I think the following image sums up my feelings nicely, we need one of these …


Whether or not WMS/WFS/WCS/CSW (…) client support is caused by a lack of motivation, client demand or vendor negligence, i won’t go so far as to guess. Certainly if OGC put as much emphasis on broadening the consumption of its standard’s as it does jumping through hoops to get certified, I would have a lot less grief at work!

“I’m sorry “Frustrated-Consumer-of-OGC-standards”, what you have requested is entirely possible with the standards and server however your client does not support that manner of request. Can i advise hand-coding a *insert language here* script to post a request, parse the response, convert the format and then drop it into your GIS so you can do what you have asked??”

“Can you just send me the file? That will be easier …”

I hope the horrible analogy of build it and they will come will hold true. Otherwise, we’re in trouble …