Bouquets and Brickbats

I had meant to write some nice things about ESRI’s Geodatabase technology (the Bouquet part of the blog) but then hand out a brickbat over their announcement of a new ESRI Spatial Data Type for Oracle which will compete directly with Oracle’s own, ISO and OGC compliant implementation.

But I only just saw the Directions Magazine article interview with Jack Dangermond on ArcGIS 9.2 (Aug 2, 2005. See http://www.directionsmag.com/article.php?article_id=927&trv=1) so I decided to post the brickbat part of what was to be a more balanced blog straight away.

Here is what I wrote at Directions Magazine:

(A late post to this bit of “old news”.)

Having recently seen some ArcGIS 9.2 “What’s New” documentation I can confirm that a new ESRI Spatial Type for Oracle exists (though I know nothing about actual implementation details).

So, even though there is a perfectly serviceable, OGC and SQL standards compliant (and interoperable) spatial implementation in Oracle (SDO_GEOMETRY) which ESRI supports, they still go ahead and implement their own.

Strange.

To a geospatial professional like myself, one should naturally expect an answer to the following from ESRI themselves:

If the Oracle spatial implementation is OGC and ISO standards compliant why did you feel the need to implement your own?

I don’t know of any IT company today who would bother wasting resources implementing their own representation and methods for numbers, dates and strings in Oracle or any other database, when perfectly acceptable ones (meeting relevant standards) aready exist exist.

So why do it for spatial? Spatial ain’t special – what is good for the goose is good for the gander.

I would rather ESRI have put more effort into improving their interoperability with Oracle Spatial for their ArcIMS, ArcGIS etc products than to waste time and money reinventing the wheel.

With regards to SQLServer, MapInfo via their shockingly undervalued, under promoted and virtually hidden Spatialware product, have had a UDT implementation of vector spatial within SQLServer for far, far longer than ESRI. So for ESRI to claim that they will be the “first to support abstract types” on SQLServer is questionable. Will they be the first on SQLServer 2005? Well, one would think that MapInfo should be able to port Spatialware faster to SQLServer 2005 from their current SQLServer 2000 implementation faster than ESRI could… but I will leave it to MapInfo to argue the merits of their own product.

From what I heard, Microsoft did actually implement their own vector ADT in SQL Server 2005 but pulled it out at last minute. Tom Barclay, Microsoft Resarch Labs (and one of the engineers for Terraserver) was working on this implementation. Some say they pulled it out because they asked some vendors in the GIS industry for their view.

Given ESRI’s treatment of Oracle’s perfectly acceptable spatial implementation I think it right to ask the question:

If Microsoft had released that implementation would ESRI interoperate with it in the same way they have done with Oracle’s?

Message to Microsoft: don’t bother with getting an OGC compliance certificate. It obviously means diddly-squat to some GIS vendors.

More GIS and RS vendors interoperate comfortably with Oracle Spatial than interoperate with ESRI’s ArcSDE. So, who is ESRI doing this new Spatial Data Type for?

I will add to this blog comments on the schema translation services later.