[Thuban-list] proposal changes on postgisdb.py

[Bernhard Herzog]

LCzub at t-online.de (Luiko Czub) writes:

> 1.) postgisdb.py expect, that the postgis tables has a field 'gid'. I
> don't know why,

The code was developed originally in an attempt to be as close to the
OGC Simple Features for SQL specification as possible and the gid came
from there IIRC.  I checked that a bit better now, and while the
specification mentions a gid in some places AFAICT it doesn't actually
specify that it must be used in the fashion that Thuban currently
expects.


> so I replaced the SELECT-Statements with the default rwo-id Field OID.

I'm not sure simply using OID instead of gid is the right way to fix it.
It's PostgreSQL specific and even PostgreSQL doesn't guarantee that it
is there since it's possible to create tables without an OID column.

The best way to handle it would be to let the user select the id column
to use, at least when there are a several to choose from (not sure
whether there's a good way for Thuban to figure out which columns are
ints with a unique and not NULL constraint).  This would require a
change to the file format, so would have to wait for 1.1.

For 1.0, using the OID instead of the gid is a good solution, I think.
It's definitely better than relying on gid and tables that don't have
oids are probably quite uncommon.


> 2.) My geom datas are stored in postgis DB for a SRID different from
>   '-1'. psgl raises the traceback 'Operation on two GEOMETRIES with different
> SRIDs',
>   when PostGISShapeStore.ShapesInRegion() searches for geometries. I created a
>   new Method PostGISShapeStore.Srid() and .ShapesInRegion() call this know
>   instead of '-1'. 
>   Changes for this are marked with the comment 'SRID != -1'

This is now in CVS.  The main difference to you patch is that there is
no Srid method.

>   Attention: I'm not shure, that the projection of geomeries, imported from
>   postgis, will be correct.

Yes, that might be a problem.  Ideally Thuban should determine the
projection used by the data in the database if the srid is != -1 so that
it can reproject properly if necessary.  This shouldn't be too hard in
the case of Postgis because like Thuban itself it uses the proj library
for projections and a suitable paramter list is the SPATIAL_REF_SYS
table.  It's not all that easy in the current Thuban architecture
because the projection is associated with the layer and not the data as
it probably should be.

> 4.) My postgis tables sometimes has more than one geometry-field, but Thuban
>   could not handle this.

Some parts of this are now in CVS.  The PostGISShapeStore class can
handle table with multiple geometry columns.  It's somewhat different
from you patch in that the name of the geometry column is an extra
paramter to PostGISShapeStore and only required if the table has more
than one geometry column.  This is for backwards compatibility.

Also for compatibility reasons the other changes are not yet in CVS
because they mean changes to the file format which we want to avoid for
the stable 1.0 branch.  Once we start on a developement branch we'll
have a look at that again.

There's one incompatibility in current CVS in comparison to 1.0.  Thuban
could handle tables with multiple geometry columns in some cases,
e.g. both columns have the same geometry type and srid -1.  Thuban would
more or less arbitrarily choose which of the columns to use, though, so
it wasn't all that useful.  Trying to access such a layer will produce
an error message now.  This means that loading .thuban files with such
layers will fail now, but since it wasn't really supported anyway, this
is not much a problem, I think.


> My big wish is the possibility to connect to a view (possible in JUMP
> 1.1.1, but JUMP 1.1.1 also doesn't handle multiple geometry fields at
> one table).  But I think, this would need a redesign of postgisdb.py.

Not necessarily.  I haven't tested it, but it might be enough for a
start to provide a way in the GUI to type in a table name so that you
can try to open tables that are not in the list thuban shows you.  This
wouldn't require file format changes, so it could easily be added in the
stable branch.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/