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

[Bernhard Herzog]

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

>> Bernhard Herzog <bh at intevation.de> writes:
>> 
>> > 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.

Sure.  That's part of a proper fix for the multiple geometry columns per
table/view problem, though, and thus pretty independent of how views can
be supported in Thuban.

> And you also need an entry for the unique-id
> field, i think. This might be a mandatory entry, isn't?

Yes.  This is yet another independent issue, though.

Do you know whether there's a way to determine which of the columns
might be suitable, BTW?  Figuring out which of the columns contain ints is
easy and would suffice for a start, but it would be nice to know which
of those columns also have unique and not null constraints.

> 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.
[snip example]

Thanks for the example.  At this point we should obviously concentrate
on support for the common use cases.  For that we need feedback like
yours about how postgis is used in practice and how well Thuban supports
it.

> 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?

"Consider" perhaps, as long as we don't need to implement them :)

However, it's usually also good to keep track of why an implementation
is limited in which ways.  Implementing features that will not be used
is pointless, but thinking about what would be possible, what of that
might be useful and what is necessary can often make a design better
even if you only implement the minimum of what you need at first.  At
the very least it leads to a better understanding of the problem domain.

> Don't make the mistake to build the EierLegendeWollMilchSau.

That's unlikely to happen as we don't have the resources for that :)

> 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

That reminds me that Thuban doesn't yet support rows where the geometry
column is NULL.

Another requirement is that there must be a column that can be used as
an ID.

   Bernhard

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