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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
