PostGIS 1.4 out soon
PostGIS 1.4 will be out soon, which will be good because it feels like forever we've had this release baking in the oven. The key changes are as follows:
Which many are detailed in New in PostGIS 1.4
- ST_IsValidReason() -- requires GEOS 3.1 -- will tell you why a geometry is not valid. Its a complement to ST_IsValid() which has existed for as long as I can remember
- Improvements in all the aggregate functions ST_Collect, ST_Union, ST_Accum to use new array logic that can better handle collecting of many geometries. You won't notice this benefit much until you start collecting and unioning 1000s of geometries
- Name change of hidden st*garray functions to be exposed as ST_Collect(geometry[]), ST_Union(geometry[]) ..etc
- Cascade Aggregate Union -- requires GEOS 3.1 -- need I say more?
- Prepared geometry - required GEOS 3.1
- Better debugging facilities and cleaner code base
Sadly ST_DumpPoints did not make it into 1.4, and we seem to have jumped to 2.0 thinking. Where is 1.5? 2.0 seems offly ambitious (geodetic, better 3d, WKT Raster, restructure to allow support for more types, improved curve)
that I feel we really need at least a 1.5 to
cushion the path. There are a lot of things we have left on the plate such as ST_DumpPoints, Steve Frost's Tiger Geocoder upgrade for new tiger 2007/2008 format,
minor enhancements to distance speed and functionality and dumper
that don't require major restructure that I feel those should just come first and that need only be a 3-6 month incubation. Given our new policy of not introducing new functions in minor releases, it would seem almost necessary to have at least a 1.5
More PostGIS in the news
Also in the news - there is a lot of talk of forming a Project Steering Committee (PSC) for PostGIS and moving subversion repository to OSGEO. We'll see how that develops.
For a while the non-existent PSC of PostGIS has been how shall we say Loosely defined. I tend to think strapping something on as formal as a PSC with PSC rules is bad when done too early, but now
feels about the right time for such a thing for PostGIS since the community and number of developers is growing. In general there hasn't been much of a need for it because PostGIS has always had some key things going for it which I think are
hallmarks of a successful project
- Passionate project team and community members -- there has never been a lack of passion in the PostGIS project team and community members
- Very compatible skills and personalities. I think the PostGIS development team group has a very complementary list of skill sets and perhaps even more importantly personalities that
balance each other well. Some are quick to act, some like to sometimes over-analyze the situation, and some like to listen to all sides and be arbitrators or play devil's advocate games just for yucks.
- A nurturing incubation company -- Refractions Research which has served it well all these years and hopefully will continue to do so.
- A strong user community - quick to answer questions in 15 minutes or less
- Of course a great product that is more than affordable
PL/Python Articles
On yet another note, we've been dabbling with PL/Python. Check out our articles on the topic on our Postgres OnLine Mag Site. One thing I must say about Python is that
there are enough smart programmers in that group doing very phenomenal things, that I can just import a library and not write any code. The fact that PL/Python makes it so easy to
just import a python library without anything else, makes standing on the shoulders of giants almost child's play.
- Quick Intro to PLPython
- PLPython Part 2: Control Flow and Returning Sets
- PLPython Part 3: Using custom classes, pulling data from PostgreSQL
- PLPython Part 4: PLPython meets aggregates
- PLPython Part 5: PLPython meets PostgreSQL Multi-column aggregates and SVG plots
- PL Python Cheatsheet Overview
Event circle
On another note -- this year is going to be very busy for Leo and myself. We are going to be presenting at PgCon 2009 in Ottawa in May -
and another lecture in
July at OSCON 2009 in San Jose also on PostGIS, and some other new developments which we shall discuss later.
PgCon 2009 should be interesting -- some other notable PostGIS community members that will be talking:
Mapserver XML mapfile is coming
On the MapServer side it appears they are finally planning to have a Mapserver XML file format as I discussed in Mapserver Cheatsheet. I guess enough people complained about this to make it happen. One less thing for me to worry about.
