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

[Nathan Woodrow]

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> 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 listQgis-developer at lists.osgeo.orghttp://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/1e02fc68/attachment-0001.html>