05 Apr 2007
I am attending CalGIS, the California GIS conference, this year in lovely Oakland. Sam Smith and I are manning a Refractions booth on the trade show floor, or rather, Sam is manning the booth most of the time and graciously allowing me to go to whatever talks strike my fancy.
Counting on my thumbs, attendance appears to be around 400 to 500, with about 100 of those folks associated with the sponsors on the exhibition floor.
Quick notes on talks:
-
Keynote from Dave Sonnen, IGN analyst. Sonnen is the big name in industry analysts for geospatial, is suitably well connected, and has big generic things to say. Analysts are supposed to predict the future, so the big takeaways are the five things Sonnen says will change the direction of the industry over the next few years.
- Full spatial data search, the first glimmerings of which we are seeing with the new Google KML search
- Entry of old-line IT firms into geospatial with “good enough” products to hold onto their existing customer base while adding spatial functionality. Oracle, SAP, IBM, etc. We’re already seeing this with Oracle adding their own map renderer, their own slippy map user interface, etc, to their spatial offerings
- Shortage of skilled geospatial workers
- Spatial data quality becoming a core concern (I imagine lots of people taking the georeferencing of base maps from the consumer mapping providers as gospel will do wonders for creating data of poor quality)
- Open source changing the relationship between vendors and customers<
- Sonnen really talked up open source, not just in that part of the talk, but others as well, mentioning World Wind as an example of a must-see open source geospatial app. Needless to say, I made sure to button-hole him and invite him to FOSS4G 2007.
- I caught the tail end of a talk from a Microsoft rep on Virtual Earth. The most interesting bit was a question at the end, asking what he thought made VE better than Google Maps/Earth. He said oblique photos, web browser integration of 3D, roof-top geocoding (said they got data from corporate partners, Fedex, UPS, DHL, who GPSed addresses at delivery time), and better routing (because their data was NavTeq, driven, not TeleAtlas, compiled). The latter points feed into some of the (none-too-subtle) language coming out of the Virtual Earth for Government blog, which avers that Microsoft is doing great work on data quality. We’ll see.
- The Autodesk Map3D product manager gave a good talk on open source, focusing mostly on FDO, and how being open source was benefiting Autodesk and its customers, by providing a faster release cycle and new features from the community. A good talk, it seem well pitched to me, but some of the audience still seemed confused about the idea of a data access abstraction library. It’s hard to talk software library concepts to folks who understand software as something that appears on your screen, no matter how carefully you pitch the message. One question: “does FDO run on the desktop, or on the server”? Both, the presenter gently explained.
- Very nicely presented talk from a Farralon consultant on a basic Virtual Earth web mapping project they did for Boston Redevelopment. Good thoughts on resisting creeping featuritis, focusing on the real end user and stopping there. Good demonstration of the value-adds you get for free building on the VE API (or, as the presenter noted, the GMaps or Yahoo APIs). Good free base data, geocoding, nice UI. Some very nice shots of how VE provides multiple views of the same data. They put some red data dots on their map (yawn), flipped to oblique and there the dots are on the side of the buildings (huh?), flipped to 3D and there the dots are on the tops of the 3D buildings (nice!). Very impressive demonstration of how VE ties together the three views under one API.
- Afternoon talk from CalTrans on their use of Google Earth. They bought the Whole Enchilada, a complete Google Enterprise license ($200K, he said). Looks like they have a good quantity of their live data accessible to their staff via the interface now, some good pretty pictures. Interesting, gave some reasons for not going with other 3D options: ArcGIS Explorer, too vertically integrated, tied into other ESRI things, trying to get their IT more diversified (I guess you can have too much of a good thing); World Wind, harder to use, more “scientist oriented”; Virtual Earth, more business-to-business or business-to-customer oriented. I just report the news, ma’am.
- Finally, a talk from a Google employee on KML Regions. Nothing I did not know already, or you could not learn from the API documentation, but a nice overview of what can be done. I’m looking forward to playing with this technology more, particularly in the relatively untapped field of publishing large amounts of vector data progressively via super-overlays.
Took the BART over the San Francisco for a little evening stroll through the city, had dinner at a “gourmet burger” place on Polk, and BARTed back. In the words of Samuel Pepys, “And so, to bed.”
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.
