PostGIS 2.x update

From gvSIG CE Wiki

Jump to: navigation, search

Excellent PostGIS 2.x support is a main design goal for gvSIG CE. The current implementation is lacking in many respects.

This wiki section documents what needs to be done to improve support for vector data served by a PostGIS 2.x (PostgreSQL 9.x) DBMS. It is meant as an overview that provides some technical background and context. Individual bugs and features are discussed and tracked via tickets in the bug tracker (, category "Database connectivity". The most important tickets are cross-referenced here.


Driver design and issues

The PostGIS driver does not use any native PostgreSQL client backend (DLL). It simply SQL statements for communication with the DBMS.

The main driver logic is contained in extJDBC (com.iver.cit.gvsig.fmap.drivers.jdbc.postgis):

  • PostGisDriver handles the basic DBMS queries.
  • PostGISWriter (inconsistent spelling is real) outputs features to PostGIS spatial layers. Its most critical function is conversion of gvSIG CE geometries to WKT geometries.
  • PostGisFeatureIterator reads a set of PostGIS features by primary key and allows iterating through them.


Geometry type conversion

Z and M dimensions

One of the most pressing issues is proper support for Z (3D) and M features in PostGIS. The current logics in

Geometry column

'the_geom' vs. 'geom'

Primary fields

com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getIdFieldsCandidates(IConnection, String)

Since a PostgreSQL table can only have one "primary key" type constraint, it seems safe to choose any field that has this constraint. The only potential problem are primary keys that are composed of more than field. A more relaxed key field constraint would be "not null and unique". For performance reasons, the key field should be indexed.

SRS data

Unknown = '0'.

User interface

UI widgets for (generic) DBMS connections are impemented in: ???

Connection management

UI implemented in: ???

Connection settings are saved in ???

Table filtering

Currently, too many tables are shown as import candidates for a PostGIS connection.

Take a look at the QGIS dialog for ideas which tables could be (potentially) filtered out.

Note that there is also an "undefined" geometry type in PostGIS. QGIS allows the user to interactively set the geometry type for these columns. Currently, this is visible in the "raster_columns" PostGIS metadata table (which is actually an SQL view).

In addition, PostGIS has a lot of data management tables that should not be imported directly into a GIS project. E.g. the "topology schema", the raster metadata that is stored as SQL views, etc.

Comment support

PostgreSQL has:

COMMENT ON TABLE IS '..'; COMMENT ON COLUMN <column> IS ; COMMENT ON CONSTRAINT <constraint> IS ; These should be displayed as tooltips in e.g. table browser, field schema viewer/editor, attribute table window. We could import them and put them in the table metadata, as is already done for long field names.

CAD editor support

Error handling

Automatic reconnection

Forward DBMS error messages to GUI

Missing capabilities