PostGIS 2.x update
From gvSIG CE Wiki
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 (http://gvsigce.sourceforge.net/mantis), category "Database connectivity". The most important tickets are cross-referenced here.
Contents |
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.
FETCH_SIZE
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
