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.rouz...@gmail.com > <mailto:denis.rouz...@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@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> > > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org> > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer