PostGIS Manager

Intro

PostGIS Manager is a plugin for Quantum GIS that aims to be a simple yet powerful tool for management of PostgreSQL databases with emphasis on support of spatially enabled tables in PostGIS. Target audience for this plugin are users that want to do some administration tasks on the tables in user-friendly graphical interface without having to type SQL commands. This plugin is not meant to be a complex tool supporting virtually all PostgreSQL/PostGIS functionality. Instead, it should help users with typical tasks and speed up the work.

We hope that PostGIS Manager will help to lower the burden when it comes to usage of geodatabases which are for many considered as an interesting but too complex concept to use for real work.

The user should have some basic knowledge about relational databases and their usage. For the simplest use for only viewing database structure and contents of tables, it's necessary to understand what the databases and tables. Before doing any modifications, it's highly recommended to understand the views, schemas, indexes, constraints, SQL syntax, triggers and rules. Otherwise one can do some serious harm to the data stored in the database.

Main window
Main window of PostGIS Manager

Main window consists basically of two parts:

Short intro to PostGIS

If you're familiar with PostGIS, feel free to skip this section.

PostGIS is an extension for PostgreSQL database that adds support for spatial data. Much of the objects we recognize in the world have some location: a restaurant can be defined by a point, a road can be described as a line with several segments and border of a forest can be represented as a polygon. This means that we can extend our tables (containing restaurants, roads, forests or anything else) with another column which will specify object's location. PostGIS implements adds a new geometry type that stores the spatial information. Once such table contains such column, we call it spatial table or geotable.

When working with a large set of data (think millions of rows), it's necessary to access the data effectively. Relational databases use indexes on columns to achieve better performance of queries. Traditional indexes however can't be used for the spatial data because they're two (or even more) dimensional. PostGIS comes with a spatial index (R-tree, as opposed to B-tree used for traditional indexes).

GIS software typically organizes data into layers: one layer is a set of objects with common properties, e.g. roads, railroads, rivers or cities. In relational databases one layer is represented with a table where one row represents one object: geometry column determines the position and the rest of the columns are object's attributes.

Database view

This widget displays database content in a hierarchy. Top-level items are always schemas (i.e. namespaces), their children are both tables and views.

You can find following icons that differentiate the items in the view:

schema Schema
table Table
view View

If the database has PostGIS support, the plugin will detect which geometry type is used for the table (points, lines or polygons) and set appropriate icon (instead of the original table/view icon):

point Point layer
line Line layer
polygon Polygon layer
unknown Unknown layer type

Unknown layer type means that the geometry column is either not listed in geometry_columns or some special type is used.

Tables that contain more geometry columns are listed multiple times, each time for one geometry column. This is however not very common.

Schemas can be expanded and collapsed, by default all schemas are expanded if the database contains less than 100 tables or views.

Note: by default, there is a public schema in every database and is used implicitly. This means that tables in public schema can be accessed just by their name and not necessarily with schema.table syntax.

Central view

The central part consists of three tabs for inspection of the table metadata and their contents.

Metadata tab

Displays basic information about the table:

For spatial tables it adds a section about geometry type, number of dimensions, coordinate reference system and layer's extent.

This tab is used also used to show schema and database information.

Table tab

Shows contents of the table in a table. Geometry columns are excluded from the view. The table is read-only.

Preview tab

Available only for spatial tables. Displays a simple map from the objects' geometries.

Database connections

In Database menu there's a list of available database connections. The list is loaded from QGIS settings and if you'd like to add, modify or delete any connections, you can do it within Quantum GIS, menu Layer » Add PostGIS Layer. Once connected, you can disconnect from the database (menu Database » Disconnect) or reconnect to a different database.

When started, PostGIS Manager tries to connect to the recently used database for convenience.

Database info

When the user selects menu Database » Show info, the metadata tab is filled with information about the database connection: host computer name, current user (role), user's privileges and server version. If the PostGIS support is installed for the database, it will also show information about version of PostGIS and its support libraries.

There may be also a warning stating there's a mismatch of versions of PostGIS scripts. This might be a result of incorrect upgrade of PostGIS: when installing a newer version, you should also re-run the initialization scripts for every database on the PostgreSQL server that has PostGIS support enabled. The scripts are in lwpostgis.sql and spatial_ref_sys.sql files, located in the PostGIS installation directory (depends on the platform).

Management of schemas

When clicked a schema, some basic information about the schema is shown: number of tables, owner and permissions of the current user.

It's possible to change schema's name by either clicking schema's name once more when selected or by pressing F2. When renaming schemas in spatial database, the geometry_columns table is altered too to reflect the change in schema's name.

In Schema menu it's possible to create a new schema and to delete an existing schema. The schema for deletion must be empty.

Management of tables

Whenever a table is selected in the database view, the central view is updated with data from the table. Double clicking table name in database view, clicking Edit table action in toolbar or Table menu, opens table properties dialog. The dialog comprises of three tabs: Columns, Constraints and Indexes - each of them containing a list and some actions.

Table properties dialog
Table properties dialog

You can do following operations with tables:

It's possible to create new tables in a simple table creation dialog. You can open it by clicking Create table action in toolbar or doing the same in the Table menu. The dialog aims for simplicity and offers only basic options: schema, table name, list of columns with their types, column which will be used as a primary key. In case user's going to create a spatial table, it's possibly to specify geometry column name and type, optionally to create a spatial index.

Create table dialog
Create table dialog

There are also several more operations available in the Table menu:

Data Import

Load data from shapefile

Clicking menu Data » Load data from shapefile will open a dialog for import of shapefiles into the database as spatial tables. The dialog acts as a simple frontend for the shp2pgsql command line utility from PostGIS. See Using the Loader section from the PostGIS manual for more information.

There are several available import actions: only create table, only insert rows or both creation of table and insertion of rows. The tool supports several options, most of them can be set within the dialog. Finally, the resulting SQL commands can be either stored in a text file or directly applied in the current database connection.

Note: not having PostGIS installed on your local machine or being installed in some non-standard location will render this feature unusable because of the missing shp2pgsql tool.

DBF Import

For those willing to import some tables without geometries into the database, there's import wizard. Although currently supports only import from DBF files, it might eventually get support for more formats. The first step is to select input file and encoding. In the second step, one can see how the table will look like and optionally do some modifications to the table. Clicking Finish button the file gets imported into the database and the wizard is closed.

Data Export

There's a possibility to export spatial tables into shapefiles: use Dump data to shapefile (in Data menu). Similarly to the Load data from shapefile, this is a frontend to pgsql2shp utility from PostGIS. See Using the Dumper section from the PostGIS manual for more information.

A dialog will pop up where the user can set the source table to be used for import and the output shapefile. The resulting shapefile will be generated after clicking the Dump button.

Advanced features

Geometry processing

In many case you may want to do some analyses with your spatial tables. Often it's useful to know the area of every polygon or length of every linestring in a spatial table. Just imagine situation where you would like to see polygons symbolized depending on their size. Or as a part of cleaning process you want to delete some of the smallest polygons. In these cases it's handy to have the area or length value precalculated in a separate attribute. Of course it's possible to let PostgreSQL calculate the values on the fly (e.g. using a view with such calculated column), but that leads to performance penalties on retrieval of data.

Geometry processing dialog greatly simplifies the task of calculation of features' area or length. You just select the table and appropriate geometry column (usually there's just one per table) and the attribute which will receive the calculated values.

If data in your table are being added or modified, the calculated values become soon invalid. But don't worry. There's a check box "Add a trigger for calculation on insert and update". If checked, the dialog not only calculates the values (one-time action) but it also creates a trigger function that does the calculation and assigns it to the table. On each modification of the table trigger function updates the area/length attribute to make sure the value is correct.

Note: both area and length are calculated in the units of layer's projection. If the layer has meters as map units, the resulting length is in meters and area in square meters. When using lat/lon coordinates, the map unit is one degree and the resulting length (in degrees) and area (in square degrees) doesn't have much use (IMHO).

Table versioning

This is currently an experimental feature.

Having table with versioning means that you can go back to any moment in the history of the table and see its state. This is achieved by only appending changes to the table instead of doing modifications in place. Every record has additional start and end time attribute. In case the record is still actual, its end time is null. The write operations on the table are modified as follows:

To get actual view of the table, you must set a condition that end time is null, otherwise you would fetch contents of the table in the whole history. It's common to use a convenience ("current") view that has this constraint included in the definition.

It's recommended to read TimeTravelling in PostgreSQL [PDF] presentation as the table versioning feature is heavily based on it. Another good source of information (for those understanding German) is Historisierung von Tabellen in PostGIS [PDF] which discusses the topic more in context of GIS application and gives examples of the implementation.