What’s a beta book? Well in this case it’s a lot like software—feature complete and ready for you to give it a spin.

The announcement from the Pragmatic Bookshelf:
The Pragmatic Bookshelf | Desktop GIS
“From Google Maps to iPhone apps, geographic data and visualization is quickly becoming a standard part of life. Desktop GIS shows you how to assemble and use an Open Source GIS toolkit. You’ll find strategies for choosing a platform, selecting the right tools, integration, managing change, and getting support. You’ll get a good introduction to using the many tools available so you can visualize, digitize, and analyze your own mapping data.”

Of course nearly everyone in the country has removed their snow tires in anticipation of the upcoming May 1 deadline. As they say “Life is tough in the far north”.

The good news is that now we can go directly from winter to summer…

I found myself wanting to print something and, based on my last experience, prepared for the ordeal of setting up a printer. I about fell out of the chair when I opened the Printer configuration and found that the Eee had already found the CUPS printer on my network and added it. Hit print and it works. Nice.

If you manage a collection of rasters that are updated on a frequent basis, storing them in a relational database with ArcSDE quickly becomes a pain. I’m not talking about a dozen or so rasters, but rather tens of thousands. The overhead of the database and middleware just doesn’t seem to be worth it.

A better solution is to use MapServer with a tile index (created using gdaltindex) to serve them to your desktop clients via WMS. Fast, simple, and easy to update and manage.

For example, here is a simple shell script to convert shapefiles in a directory from their current (in this case projected) coordinate system to WGS 84:

#!/bin/sh
for shp in *.shp; do
ogr2ogr -t_srs EPSG:4326 wgs84_shapes $shp
done


This simply takes every shapefile in the current directory and converts it to WGS 84 and places it in the wgs84_shapes subdirectory. If you don’t know what an EPSG:4326 is or need help with projections and coordinate systems, check out the Spatial Reference website.

Total runtime for converting 91 shapefiles was about 47 seconds—way faster than you could do it pointing and clicking.

If you are a Linux or a Mac user, you can take that little shell script and use it directly. If you are a Windows user, you can use the batch language to write a similar script, or better yet install MSYS or Cygwin. With MSYS or Cygwin you can run the script above as-is on Windows.

The quickest way to get the GDAL/OGR utilities for Linux and Windows is to install FWTools. For Mac, download the GDAL framework and required dependencies from Kyng Chaos.

Don’t get me wrong—using a GUI is great, however when you have huge quantities of data to convert there is no better way than the command line.

It’s an interesting read with some good points until I got to this:

Our current favorite example of this approach is Ruby-on-Rails. This system is the little language, Ruby, extended with integrated support for database access and manipulation through the “model-view-controller” programming pattern. Ruby-on-Rails compiles into standard JDBC, but hides all the complexity of that interface.

Rails compiles to JDBC? Now I’m questioning the the whole paper…

Enter Leopard. I upgraded my machine rather than a clean install — I’m in the middle of too many things to start from zero. Being cautious, I waited a few days to see what kind of issues might arise (such as the Blue Screen of Death). For the most part, the upgrade went well, with a few exceptions:

• My crontab disappeared. Well not entirely as the crontab still existed in /var/cron/tabs, but running crontab -l showed nothing. To fix I just ran crontab -e and pasted the contents into the empty editor (Vim of course) and saved it.
• All my printer definitions disappeared. All I have is remote printers hanging off a Linux box so this was worth a bunch of fiddling around to get things working again
• AFP doesn’t work with Linux netatalk. Apparently Leopard doesn’t allow clear text passwords (a good thing) but the versions of netatalk on Ubuntu and Debian don’t support encryption. You can build it yourself, but this will break AppleTalk printing (which of course I’m using). No more AFP connections for now.
• GPG support in Apple Mail broke (requires an update from the GPGMail guys)
• After finally patching up X11 in Tiger, Apple decided to ship Leopard with X.Org rather than XFree86. A total disaster. I have nothing against X.Org — I use it on Linux — but the implementation in Leopard is rife with problems. Take a look at the Mac forums and you’ll see what I mean. While I was finally able to get an Nx session, there were scrolling problems, the yellow mouse pointer is back, and it crashed when running QGIS. I finally removed X11 and installed the XFree86 version from my Tiger disk to get things working again.

I also found a number of applications that needed to be upgraded in order to work (no surprise really). Fortunately most of the open source developers are on top of the changes needed.

Your average user probably won’t have to face these issues. If you’re a developer or heavy open source user, be aware it may take a while to sort out the issues with your upgrade. I just hope there aren’t many more surprises lurking for me under the hood…

To remedy this situation I found that the pg_dumplo utility has the answer. The trick is to use pg_dumplo to dump the large objects from the “old” PostgreSQL/PostGIS install and then use it to restore the objects to the “new” install after running the postgis_restore.pl script.

The pg_dumplo utility can usually be found in the contrib directory of your PostgreSQL install. For a complete example, see the README.pg_dumplo file located in the contrib/pg_dumplo directory.

Note: You only need this utility if you have created database tables containing large objects. On a “stock” PostGIS database the postgis_restore.pl script does it’s job in a most efficient way.