[Thuban-list] proposal changes on postgisdb.py - connecting views
LCzub at t-online.de
Thu Feb 12 22:32:32 CET 2004
> Bernhard Herzog <bh at intevation.de> writes:
> > LCzub at t-online.de (Luiko Czub) writes:
> >> 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.
Cause I am a friend of tables and views with more than one geometryfield,
please enlarge this idea with a non-mandadory field for the geometry-field name.
And you also need an entry for the unique-id field, i think. This might be a
> Thinking about this a bit more, it wouldn't be as easy as this. The
> problem is that it would be difficult to figure out which srid and
> geometry type the table or view uses. The way Thuban currently does
> this (by searching the geometry_columns table) wouldn't work for views.
That is, what I mean with 'redisgn', if you whiches to handle tables and views
in the some way.
> In fact Thuban more or less expects that all shapes in a shapestore have
> the same type (e.g. all polygons or all points but not both). In a view
> that is not necessarily the case. I don't know whether that actually
> occurs in practice but it's possible:
In my opinion, the main interest to connect from a viewer like Thuban to views
is, using datas from non-spatial tables for the classification of
So you would use the view, to add additional data-attributes to the
not to mix several geometry-types. Here is a example for a view, I am working
CREATE VIEW edbs_linien_view AS
SELECT f.folie, f.linienart, f.objnr_links, f.objnr_rechts,
f.objteilnr_links, f.objteilnr_rechts, f.gid ,
l.nummerierungsbezirk, l.art_der_geometrie, l.linie_geom
FROM edbs_linienfunktion AS f
JOIN edbs_linie AS l
ON f.owner_id = l.gid;
Kind of association is: edbs_linie 1:n edbs_linienfunktion
Geometryfield is : edbs_linie.linie_geom (LINESTRING)
unique-id field is : f.gid
You could create the situation with several geometrytypes in one column also
with a 'normal' table, if the geometry column is of the type 'GEOMETRY'. But
this is in my opinion a
bad datamodel design , if someone did not know, with what kind of datas he is
working. And do you realy
want to consider all possible bad datamodel designs? Don't make the mistake to
I think, you would make a big step forward for the classification of datas, if
there is a posssibility for connecting views in the way, you describe above.
> Playing around with that a bit, I think we might be able to use e.g.
> SELECT DISTINCT GeometryType(geom) FROM foo;
> SELECT DISTINCT SRID(geom) FROM foo;
> to determine the geometry type and srid to use. If either of the
> queries yields more than one row, Thuban would have to refuse to use it
> for now (it could be made to work if the geometry types are sufficiently
> similar e.g. LINESTRING and MULTILINESTRING). I'm not sure what to do
> if no rows are returned.
Maybe, there must be some rules for connecting views (like the rule 'unique-id
field gid' in thuban 1.0.0):
- all entries for a geometry-column must be of the same geometrytype and srid
- there must be one row of the view, where the geometry-column has an entry
Gruß Luiko Czub
More information about the Thuban-list