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 consists basically of two parts:
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.
You can find following icons that differentiate the items in the view:
Schema
Table
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 layer
Line layer
Polygon layer
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.
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.
When started, PostGIS Manager tries to connect to the recently used database for convenience.
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).
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.
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.
There are also several more operations available in the Table menu:
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.
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.
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).
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:
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.