24 Mar 2007
In a comment on my wailing regarding ESRI’s apparent decision to roll out their own PostgreSQL spatial type alongside general support for PostgreSQL in ArcSDE 9.3, Bruce Bannerman says:
I think that you are reading too much into this.
ESRI provide ArcSDE Geometry Storage options for a number of DBMS. I’m assuming that this will be the same with PostGRES.
No doubt, there are lots of (too many?) geometry options available with ArcSDE already. And a look at how the options are distributed between the various host databases raises some interesting questions:
- Oracle
- SDEBINARY (ESRI)
- SDO_GEOMETRY (Native)
- ST_GEOMETRY (ESRI)
- DB2
- SDEBINARY (ESRI)
- ST_GEOMETRY (Native)
- Informix
- SDEBINARY (ESRI)
- ST_GEOMETRY (Native)
- SQL Server
- PostgreSQL
- SDEBINARY (ESRI)
- GEOMETRY (Native)
- ST_GEOMETRY (ESRI)
Why does ESRI use the native geometry implementations for Informix and DB2 and not provide their own special implementation? I would posit that the DB2 and Informix implementations, put out by close business partner IBM (and, if I am not misled, implemented in large part by ESRI itself), are perceived as “friendlies”.
Why do they provide a special implementation for Oracle? The Oracle native geometry is controlled by an aggressive corporation with a competitive chip on its shoulder that has been actively hustling to elbow ESRI out of some of its traditional turf. I had the privilege of being part of a “bake off” a year ago. Me, the local ESRI reps, and an Oracle rep, all gave presentations about the relative merits of our spatial database solutions. The Oracle presentation was notable in its head-on attack on the many disadvantages of “proprietary middleware” (read, “ArcSDE”). They gave no quarter. I assume no love is lost on the ESRI side of the fence either.
So, if using the native geometry type is what ESRI does with its friends, and dumping a “special” spatial type in is that they do with their enemies, how is a rational observer to interpret the inclusion of a new PostgreSQL spatial type with the 9.3 ArcSDE PostgreSQL support?
There is no technical reason to do it, that I can see – PostGIS already supports all the function signatures that the Informix and DB2 spatial implementations do. All that is left is company strategy. Apparently, PostGIS is considered beyond their control and potentially hostile (like Oracle’s SDO_GEOMETRY) so they are including a route-around in the form of their own type.
I have contacted the folks at ESRI to try and clear this up, but no response yet. Because PostGIS is open source, there should not be a need for a strategic route around us. ESRI can join the community and submit whatever functionality they require, and they don’t have to get down on their knees and beg, the way they would with Oracle.
15 Mar 2007
Some more details on the upcoming ArcSDE support for PostgreSQL are living in the Q&A page for the upcoming Developers Summits (as pointed out by James Fee).
First there’s the old news:
ArcGIS Server (ArcSDE technology) will support the PostgreSQL database at the ArcGIS 9.3 release.
Then there’s the good news:
The enterprise geodatabase and all of its standard capabilities will be fully supported. It will be OGC/ISO compliant and the PostGIS geometry type will be supported.
Yay! You can work with PostGIS columns via SDE and then push the data out to other PostGIS enabled tools, like Mapserver or Hibernate or GRASS! And then finally, the bad news:
In addition, ESRI will also provide its own spatial type for storing geometries in PostgreSQL.
Gah! Ouch! It burns! There aren’t “special” types for Informix or DB2, why for PostgreSQL/PostGIS? Unlike Oracle, we are ready and willing to add the features to PostGIS necessary to fully support ArcSDE’s spatial SQL needs. And if you don’t trust Refractions, PostGIS is open source, so you could just do it yourselves! Hop in the pool, guys, supporting open source is not just about software, it is about community participation, everyone rowing in the same direction so nobody has to row too hard by themselves.
01 Mar 2007
Lots of interesting tidbits from the conference organizing front:
- We have added Leica Geosystems as a sponsor. Like Safe Software, Leica is proprietary software company that makes use of open source in their developments. I’m looking forward to hearing both companies articulate their vision for engaging more with their respective communities.
- I got to take a tour of the Royal BC Museum galleries where we’ll be having our Wednesday evening reception. The First Peoples Gallery looks great, some amazing totem poles and carvings in the central room, and of course the Natural History Gallery has the really cool animal displays my daughter loves so much (oh, the whispered terror of the Mammoth!)
- The Call for Workshops has gone really well, with over 30 submissions so far, and a slight extension to allow a few more to trickle in. Reading over the evaluations of the 2006 conference, it is clear that the hands-on workshops are what really set FOSS4G apart from other conferences. Yes, sir, sit down at that computer and try out that software – and take it home with you when you’re done, please.
14 Feb 2007
I don’t know whether to be delighted or frightened, but Google has put in place the final part of the publish-find-bind contract for a Google SDI.
Now people can publish their data in the new universal format, Google’s KML. I can find that data using a Google search. And I can bind to that data using Google’s clients — Google Earth and Google Maps.
I guess this speaks to the importance of a useful working prototype in building out collaborative technology with wide adoption. If Tim Berners-Lee had been content to just write down the specs for HTTP and HTML, we probably wouldn’t have the web (maybe we’d have a huge network built on gopher… now that would be cool). But he didn’t just do that, he built a working system at Cern that did useful stuff with HTTP and HTML, and the people at other sites could take and use too, freely.
Time to retrofit all our software to publish KML!
10 Feb 2007
Not a geospatial post, but… I fired up my home accounting software today, to get caught up in preparation for tax time, and look what greeted me:
Intuit is going to shut down all the internet services associated with my copy of Quicken for Mac. But good news! I can upgrade to Quicken 2007 for only $50 and keep my services! Yay!
Holy corporate screwings, Batman! Nice way to drive the upgrade process, Intuit, but a little tough on the customer loyalty — I feel like a beast being driven over Head Smashed In Buffalo Jump. Gotta make those quarterly numbers.
Time to research alternatives — deeds like this should not go unpunished.
