30 Mar 2007
PostGIS has been around for a surprisingly long time now, over five years, and has accumulated a lot of crufty stuff kept around for backwards compatibility. (The only function I have found to have been removed is an old point point-in-polygon function from the very early versions called truly_inside().)
Here are some things that I think it would be wise to pursue going forward:
- Complete SQL/MM support. We already have a good deal of it, to provide compatibility with SDE (should SDE wish to provide spatial SQL access to PostGIS). We will need to complete curve support to get substantially closer.
- Clean up function names, deprecate old OGC function names and move to using XX_ prefixes to define where the functions come from. ST_ for SQL/MM, SE_ for SDE-specific, PGIS_ for PostGIS specific, etc.
- Automagic indexes. Wrap all the ST_ functions in index magic so that Contains(A,B) kicks in the index automatically.
- Automagic geographic support. More controversially, recognize when simple spatial ops are being called on lat/lon features and apply appropriate translations to do them in a planar system, or on a sphere/spheroid. The danger here is that in pleasing the crowd, we will quietly confuse a small number of people for whom the automagic assumptions are wrong.
- Update documentation. PostGIS is now far in advance of its last serious documentation update. The reference material is all correct, but the tutorial level stuff needs to be updated. All the examples work, but they are not the “right” way to do things anymore. Particularly important if we start deprecating old function names.
- It is a bit over-the-top to call the above changes “next generation”, because only one of them (full SQL/MM curvepolygon support) would involve touching the core object representation. But they would definitely effect the user-level interaction with PostGIS a lot, and in my mind “complete” the simple-features aspect of PostGIS, allowing us to move on to the real next generation topics, like topology, networks, routing and other “on top of simple features” functionality.
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.
