PostGIS 1.3.3 has been released and is already in the PostgreSQL RPM and soon will be in Yum repository.
PostgreSQL 8.3 users who are using PostGIS are encouraged to upgrade because this release contains a fix for a major bug that
affected spatial aggregates in 8.3. The windows Application Stack Builder version with the update should be out within this or next week.
Shp2PgSQL Loader now can load plain DBFs
We've been working on the 2007 Topologically Integrated Geographic Encoding and Referencing (Tiger) data
recently. For those who are familiar with the US Census current Tiger format, this is the first version to be released in
Environmental Systems Research Institute (ESRI) Shape file format. We ran into one small problem. The Tiger data includes related data with no geometry. These come as plain old
DBase (DBF) files. Prior versions of Shp2PgSQL could not deal with DBF files with no corresponding Shape (SHP) geometry files, but the version
packaged with 1.3.3 can.
I would like to thank Paul Ramsey for checking over my DBF-only patch and squeezing it into this release.
Now that I have gotten my hands dirty again with C code, I almost feel like a real programmer. As a side note, even if you don't use PostGIS, this should
come in handy for loading any DBF file into PostgreSQL.
New PostgreSQL Yum Repository
We recently had the pleasure of trying out the new PostgreSQL YUM repository for Fedora/RedHat Enterprise/Cent OS
distros that is maintained by Devrim GÜNDÜZ. It made the process of installation on Redhat Enterprise Linux a lot simpler.
In this issue we shall provide step by step instructions on using it geared toward the non-Red Hat Linux/CentOS indoctrinated folk (AKA the misguided Microsoft Windows people).
The reason we feel this is necessary is that a lot of people develop on Windows and then deploy on Linux. The Linux experience can
be somewhat intimidating, so we hope to make this an easier process by assuming you know little if anything about Linux. So stay tuned for that article.
People have asked us on several occasions if there is such a construct
SELECT * EXCEPT(...list) FROM sometable. Sadly we do not think such a
thing exists in the ANSI SQL Specs nor in PostgreSQL.
The above feature would come in handy when you have certain fields in your tables that are common
across tables, but you need to leave them out in your query. A common case of this is when you have PostGIS tables loaded using shp2pgsql
with a fields called gid and the_geom which are not terribly useful for simple data queries.
There are 2 common ways we use to achieve this result.
Using PgAdmin's CREATE SELECT script feature. This exists in other GUI tools as well.
Using an Information Schema script hack to construct the SELECT statement