[Thuban-list] proposal changes on postgisdb.py - connecting views

[Luiko Czub]

Moin Bernhard,

> 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
mandatory
entry, isn't?

> 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
geometry-tables.
So you would use the view, to add additional data-attributes to the
geometry-selection and 
not to mix several geometry-types. Here is a example for a view, I am working
with: 
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
build the
EierLegendeWollMilchSau.

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;
> and
>    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