Documentation home Next page

This page describes the installation and work with PostGIS GDO

Installing PostGIS GDO

Installing the GDO server

At the moment, there is no installation package provided. Once you download the PostGISGDOBin.zip archive, unpack the files GMPsgCtl.ocx and PostGISGDO.dll to any desired location on your hard disk and register them by the Regsvr32 utility. You can also use the provided Register.bat file to register the libraries.

Working with PostGIS GDO

Postgis GDO server runs in three modes:
  • read only mode - this mode requires no metadata
  • read/write mode - this mode requires GAliasTable and modification logging
  • schema updatable mode - this mode requires full INGR metadata
In order to simplify creation of metadata tables, Database Utilities are provided - this is a standalone utility with file name PsgDBUtils.exe.

Working with Database Utilities

Database Utilities provide simple interface to create or drop metadata tables and to edit/create/delete feature class metadata. When assigning the feature class metadata, list of available tables is displayed, except the two PostGIS metatables, GAliasTable, and all tables listed in GAliasTable. You can simply turn a feature class on or off by the check box in the list. Checked table is visible, unchecked is not visible. The same apply when editing particular fields.

DB Utilities provide very little option for the field manipulation, as well as for the coordinate system assignment. The reason is that PostgreSQL knows perfectly what type is each particular field, and PostGIS nows perfectly what geometry type, and what coordinate system each geometry field is.

The only exception are BLOB fields - "bytea" type in Postgres. This fields can be cast to a geometry field and can store either graphic text or raster images. PostGIS does not provide storage for these two types, so the data can be stored as INGR geometry format, and cannot take part in spatial operations, including spatial filtering. The coordinate system must be specified in term of Srid = EPSG code.

Working with PostGIS GDO

You can view all geometries from the database with read only version. If you want read/write capabilities, simple metadata must be present. The geometries can consist of points, line segments and arc segments. However, not all PostGIS geometry types allow storing of arcs. In this case, if arc is attempted to be stored with the geometry, PostGIS GDO will automatically stroke it, without notification.

If you work with full INGR metadata, you can also create, modify and drop tables. If you create new geometry tables, PostGIS GDO will createt the geometry columns as type MULTIPOINT, MULTILINE and MULTIPOLYGON for point, linear and area feature classes respectively. These types do not store arcs. If you need arcs to be stored, you can create the table manually via psql tool specifying the appropriate type - typically MUTLICURVE and MULTISUFACE. The reason why PostGIS GDO does not use these more generic types is that these types are not the WKT (WKB - well known text, well known binary) standard, and it looks like PostGIS cannot use (some?) spatial functions on these types.

Note about spatial filter

PostGIS cannot spatially filter geometries containing arcs, as mentioned above. Problems can also be experienced when the filter geometry is somehow complex. However, simple geometries, like map window extent, work OK as a spatial filter.

Note about coordinate systems

PostGIS GDO does not create the GCoordSystem table, it synthesizes this table in memory. The reason is that PostGIS must know of each geometry coordinate system. It uses the EPSG codes (Srid) and stores the coordinate system definitions internally. So PostGIS GDO gets this Srid information and does not create GCoordSystem table in order to avoid duplicity. However, in the schema updatable mode (INGR metadata), the GCoordSystem table is created. But PostGIS still must be able to match the coordinate system with Srid. Otherwise new geometries cannot be inserted.

For portability reason, the Srid - GCoordSystem mapping is linked with the PostGIS GDO dll. It consists of about 40 coordinate systems known at the time of PostGIS GDO creation. If a new coordinate system should be added, the EPSG code must be known, the csf file with name EPSGxxxx.csf must be copied into the source CoordSystems folder, the resource must be recreated using the MakeCSRes.exe utility (use the MakeCSRes.bat instead) and the PostGIS GDO project must be recompiled.

Working with Views

Views should be visible as any other tables. However, if the view contains one or more geometry columns, a record for each geometry column must be manually created in the "geometry_columns" table. The record should be the same as for the base geometry, except "f_table_name", which should refer to the view name. If the view is created in other schema than the base table, then it is necessary also to change the "f_schema_name" field.

Updatable Views

While working with read-only views is quite simple, updatable views require some more attention. PostGIS GDO uses a hidden (system) field named "ctid". This field is present in each table and also in SQL selects which result in updatable recordsets, however is not present for example in "SELECT MAX(ID) FROM ..." selects. So PostGIS GDO uses this field also for determining, whether a recordset is updatable or not.

Views do not contain this "ctid" field unless specially requested. So to enable editing capabilities on a view, the view must be declared as:

CREATE VIEW myview1 AS SELECT ctid, * FROM mytable1;

Furthermore, to create editable view a special rule ON UPDATE ... DO INSTEAD (also ON INSERT, ON DELETE) must be created on the view. And even more, in order to work properly with PostGIS GDO, this rule must contain RETURNING clause. So an example of such rule is:

CREATE RULE myview1_upd AS ON UPDATE TO myview1 DO INSTEAD UPDATE mytable1 SET id = new.id, name = new.name, geometry = new.geometry ... WHERE mytable1.ctid = old.ctid RETURNING mytable1.ctid, mytable1.*;

Finally, PostGIS GDO Database Utilities must be used to manually assign key fields on the view. The "ctid" field should be made invisible!

Documentation home Next page

Last edited Jan 28, 2012 at 3:49 PM by pkrejcir, version 7

Comments

No comments yet.