28 Mar 2007
That sound you just heard was me taking a deep cleansing breath. Aaaaah, phhewhwwhww. The first part of the FOSS4G 2007 program is now in place and online, in advance of the upcoming opening of registration. (I hope everyone registers early, to keep my blood-pressure down and ulcers in check.)
Workshops are 3 hour hands-on courses on the first day, and require you to specially register for the limited number of seats: http://2007.foss4g.org/workshops
Labs are 1.5 hours sessions, held during the regular program (days two, three and four) and are open to all conference registrants: http://2007.foss4g.org/labs
26 Mar 2007
A little birdie tells me that I have incorrectly identified Informix, DB2, and PostgreSQL as hosting the SDEBINARY type. In fact, they only host the ST_GEOMETRY type (and PostgreSQL will additionally host the PostGIS GEOMETRY type).
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.
