The PostGIS development team is proud to announce the availability of PostGIS 1.5.2. Further details are on the postgis.org website
PostGIS 1.5.2 release.
Leo and I are still working on the windows builds. As stated before the 32-bit builds will be out first. We are still preparing our 64-bit test environment on our new 64-bit laptop.
For those who are on 64-bit windows. Sami has some PostGIS 64-bit binaries for PostgreSQL 9.0 windows available on his blog. Though he just has the binaries available so you will need to use the other files from the 32-bit install.
To answer Sami's question, since he has asked it more than once:
I really can't understand why PostGIS developers still want to compile the whole stuff using msys/mingw and that kind of stuff. We have Visual C++ (yes, the compiler is available for free), everything compiles with it and you don't have to whine about how hard it is to compile stuff for Windows because it's not GNU. There are 3 reasons:
Believe it or not -- the PostGIS development crew is relatively small and most work on Unix or MacOSX which do compile under GNU. Each builds
there own regression tests. We need
to be able to test consistently on all platforms which means we need a devlopment environment that all regression tests will work on without too much fuss. As much of a pain as we whine about with mSys -- its the most like what everyone else uses and mimicks the environment most consistently.
Supporting VC means supporting yet another set of make and configure files and yuck project files. I don't even think express can deal with solution files. etc. GEOS does it and it was a pain for them. I know because a while back I would point out all the issues I was having compiling under VC++ (not to mention I don't need VC++) -- cause I'm a webdeveloper -- so don't have it normally installed). It took Mat some time to revise packaged scripts to even get PostGIS to compile under VS. There are people that bicker, but no one steps up to the plate wanting to support VS/VC++.
Leo and I are predominantly web developers and database professionals; frankly in my ideal world everything would be interpreted or Just in time compiled (JIT) by the server. MingW / VS slash anything that needs compiling is just a big pain however I look at it and they are of equal pain to me. I got out of desktop development so I wouldn't need to deal with compiling stuff.
Okay we have whined enough. There are talks in the PostGIS and GEOS group of switching to CMake and to have a process that builds said make / project files so that we can more easily support GNU and VS without hopefully not adding too much extra work on anyone's plate. We will see how that goes. Will we compile the 64-bit version under Msys64 or VS -- we would like to do both and compare the 2. :)
We took some advice from several readers and this time broke the cheatsheet into multiple pages. Hopefully you won't need magnifying glasses to read this one. We also switched to landscape and put all the examples at the end.
If you find any errors or anything major we left out, please let us know and we'll amend.
Over the past two weeks, the PostGIS development team has been working hard to get out PostGIS 1.5.2 in time for the PostgreSQL 9.0 release. This release contains fixes allowing PostGIS to compile against 9.0. Due to an unfortunate turn of events, we missed the cut by a couple of days and are currently
experiencing technical difficulties with the postgis.org website. These should be resolved soon and barring no further difficulties, we should have the final PostGIS 1.5.2 ready late this week.
- This is a bug fix release, addressing issues that have been
filed since the 1.5.1 release.
- Bug Fixes
- Loader: fix handling of empty (0-verticed) geometries in shapefiles.
- #536, Geography ST_Intersects, ST_Covers, ST_CoveredBy and
Geometry ST_Equals not using spatial index (Regina Obe, Nicklas Aven)
- #573, Improvement to ST_Contains geography
- Loader: Add support for command-q shutdown in Mac GTK build (Paul Ramsey)
- #393, Loader: Add temporary patch for large DBF files
(Maxime Guillaud, Paul Ramsey)
- #507, Fix wrong OGC URN in GeoJSON and GML output (Olivier Courtin)
- spatial_ref_sys.sql Add datum conversion for projection SRID 3021
- Geography - remove crash for case when all geographies are out of
the estimate (Paul Ramsey)
- #469, Fix for array_aggregation error (Greg Stark, Paul Ramsey)
- #532, Temporary geography tables showing up in other user sessions
- #562, ST_Dwithin errors for large geographies (Paul Ramsey)
- #513, shape loading GUI tries to make spatial index when loading DBF only
mode (Paul Ramsey)
- #527, shape loading GUI should always append log messages
- #504 shp2pgsql should rename xmin/xmax fields (Sandro Santilli)
- #458 postgis_comments being installed in contrib instead of
version folder (Mark Cave-Ayland)
- #474 Analyzing a table with geography column crashes server
- #581 LWGEOM-expand produces inconsistent results
- #471 DocBook dtd errors (Olivier Courtin)
- Fix further build issues against PostgreSQL 9.0
- #572 Password whitespace for Shape File to PostGIS
Import not supported (Mark Cave-Ayland)
- #603 shp2pgsql: "-w" produces invalid WKT for MULTI* objects.
- #513 Add dbf filter to shp2pgsql-gui and allow uploading dbf only
We should have windows binaries available a short time after release. Unfortunately we do not have the 64-bit windows build ready yet, so you still have to use the 32-bit version of PostgreSQL 9.0 if you need PostGIS on windows.