[Qgis-developer] Thoughts about multi-type tables in QGIS

[Matthias Kuhn]

I agree with Nathan, for algorithms, symbology and a lot of small things
it will become very complicated.

As an alternative approach, we could think about having some layer
settings defined on group level (and maybe even a merged attribute table
for the whole group). That would already make a lot of things easier to
configure for multiple layers at once. We could even mark such a group
as a "union layer group" or similar, so for algorithms that support this
kind of thing it would be possible to offer such a "union layer group"
as choice while all other things just continue to work.

Matthias

On 04/02/2015 02:30 PM, Nathan Woodrow wrote:
>
> I would not be in favour of supporting a many geometry type per layer
> type setup, it just makes things a heap more complicated IMO for
> little gain.
>
> Also makes your code a lot more complicated, you now have to check
> each geometry for type because you are never sure what you will get.
>
> MapInfo did this and it was more a pain then a   feature.
>
>
> On Thu, 2 Apr 2015 10:11 pm Denis Rouzaud <denis.rouzaud at gmail.com
> <mailto:denis.rouzaud at gmail.com>> wrote:
>
>     Hi Olivier,
>
>     I think you can easily extend your reasoning to the support of
>     multiple geometry columns in QGIS.
>     I believe that this would come in QGIS at some point.
>
>     If QGIS 3 is getting closer, our company will support this feature.
>
>     As you suggest, the layer could have different geometry types
>     and/or columns. This could be seen as sub-layer level for rendering:
>     layer > geometry types/columns > symbology rules
>
>     I suppose this is quite a big change. Many things depends on the
>     geometry type in QGIS (like map map tools), and that would
>     represent a large API break.
>
>     But, on my side, I believe it's a logic evolution for QGIS.
>
>     Best wishes,
>
>     Denis
>
>
>
>
>
>
>     On 04/02/2015 01:52 PM, Olivier Dalang wrote:
>>     Hi,
>>
>>     In some projects of mine, I work with multiple geometry types in
>>     one postgis table, using a column of type geometry(Geometry,4326).
>>     This is very well supported by postgis.
>>
>>     It is possible to load such a table in QGIS by manually selecting
>>     the geometry type you want to load. This means that to display
>>     all the features, you need to add the table three times, one for
>>     each feature type.
>>
>>     This works more or less. There are a few bugs though :
>>     - http://hub.qgis.org/issues/12499 (you can edit other type's
>>     node with the node tool)
>>     - http://hub.qgis.org/issues/12500 (other type's records are
>>     shown in the attribute table)
>>
>>     This also has some limitations. When having such a setup, it's
>>     pretty sure you'll want to have the same edit forms for all the
>>     layers. You'll also probably want the same filter, the same
>>     labels, the same actions, etc...
>>     The only thing you'd want to be able to define on a geometry type
>>     basis are the symbol (well, even the classification/colors/etc
>>     could be shared) and the label placement.
>>     For now, you must do all settings three times, because of this
>>     bug/feature request :
>>     - http://hub.qgis.org/issues/12303 (copy/paste style from one
>>     geometry type to another)
>>
>>
>>     As you see, support multiple geometry types in QGIS is not perfect.
>>
>>     Of course it's possible to fix the bugs/pr, and there are some
>>     workarounds (postgis view instead of tables) but maybe it's also
>>     worth thinking a bit more in depth about this.
>>
>>     We could consider point/line/polygons as subcategories/sublayers
>>     of a layer. A shapefile or a mono-typed table would have only one
>>     of those sublayer, but a postgis table could perfectly have the
>>     three. Most of the settings would be defined at the layer level,
>>     while only some settings would be defined at the subcategory level.
>>
>>     This is probably especially relevant when thinking long term (the
>>     day we support 3D, curves, etc...).
>>
>>
>>     What do you think ?
>>     Do you think the relation 1 layer = 1 geometry type will hold ?
>>
>>     I think we inherited this from the old shapefile format, but most
>>     data sources QGIS handles don't have this limitation. I also
>>     think it does not hold with quite a lot of modern GIS uses
>>     (especially web related, think of openstreetmaps for instance).
>>
>>     There's this feature request (6th oldest open issue on the
>>     tracker) about postgis geometry collections  :
>>     http://hub.qgis.org/issues/167
>>
>>
>>     Best,
>>
>>     Olivier
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     Qgis-developer mailing list
>>     Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
>     _______________________________________________
>     Qgis-developer mailing list
>     Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment.pgp>