Computing, GIS and Archaeology in the UK

Update: Due to issues with our download server, portable gis is not currently available. Investigations are taking place as to the exact cause and I will announce when it is fixed, though this may take a few days as I am away over the weekend. Thanks for your patience and your interest!

Version 1.2 of Portable GIS has been released today, addressing a number of bugs in Version 1.1. Thanks to everyone who provided feedback and spotted the bugs. If you use, or intend to use, the web-based components of Portable GIS, or the OpenEV viewer, then this is a recommended update.

The download is available here, along with a patch to convert version 1.1 to 1.2. Please read the instructions provided in the patch file as the process is slightly complicated.

Feedback is, as ever, greatly appreciated, and thanks to the 100 or so people who have downloaded the first version!

Aware that there haven’t been Thursday Tip days for a couple of weeks, or indeed anything else in the way of blog posts (follow-up post coming along soon)- here’s a real quicky:

If you want to be able to connect to your postgresql data using an external programme (such as Open Office Base, QGIS, gvSIG or Mapserver) AND be able to properly view/select and edit the data, you will need to do the following:

1. Ensure that the table you are trying to view has a primary key. Error messages if you don’t do this might vary, or be non-existent, but the end result will be that your data won’t display on the map, or won’t be editable.
2. Ensure that there is an entry in the geometry_columns table for the table you are trying to view. The geometry_columns table is specific to postgis and contains metadata about your tables. If the geometry of your table was created using the addgeoemtry function then this will be filled in, but otherwise it won’t. The function probe_geometry_columns() may fix this if run at the psql command line, but sometimes it doesn’t. But, you can fill in records in the geometry_columns table in the normal way. The table contains the following columns:

• F_TABLE_CATALOG (this is left blank for postgresql- it’s an oracle thing apparently)
• F_TABLE_SCHEMA (the schema of your table- if you haven’t set this it’s likely to be the default PUBLIC)
• F_TABLE_NAME (tha name of your table)
• F_GEOMETRY_COLUMN (the name of the geometry column in your table)
• COORD_DIMENSION (the number of spatial dimensions of your geometry- 2 or 3, or 4 if you’re really ambitious)
• SRID (the EPSG code for your projection, eg 4326 for lat/long, 27700 for British National Grid)
• TYPE (the type of spatial object held in your table, eg point, line, polygon etc etc)

The moral of the story- always include a primary key in any tables you expect people to select or edit data in, and always add an entry in geometry_columns if you want to display your spatial data on a map.

Does anyone else see the irony in these two statements, which fortuitously popped up in my feed reader one after the other?

It’s so depressing when people talk about phasing out paper maps. It seems to be part of a general feeling that all maps are for is getting from point A to point B on the road. Does your sat-nav point out interesting things you maybe ought to detour for? (I’ll probably get a wry smile from Mr Archaeogeek at this point, who knows I love to buy paper maps of new areas and sit down all evening just looking at all the sites on them. Particularly archaeological sites. He’s very long-suffering). I guess sat-nav just doesn’t have that same sense of history.

A couple of people have remarked to me that one reason that they are not prepared to make the open source jump is the lack of support.

Well, last week I wrote about a mastermap importer that I had found. I said I would like to be able to merge the huge numbers of shapefiles produced into more manageable chunks. I got a lot of good advice as to ways I might be able to do that using gdal, which is really handy, BUT I also emailed the developer about the same problem. Two days later he released a new version of the software with that functionality built in.

To me, this highlights one of the big advantages of open source. People want to make their software better, and are willing to listen to suggestions. Small firms or one-man bands don’t have the inertia of the major firms and can respond to requests quickly and easily. To the user, that means flexibility and control. In other industries, that would be seen as an advantage, not a disadvantage, so why not in software?