I think there's a lot of hidden caveats - in QGIS itself as well as in plugins - and it would be very hard to find them all and treat them appropriately.
Therefore I would prefer not to go for a change in layer semantics in terms of that a layer iterator suddenly may return different geometry types. I'd prefer to re-raise the idea of having a special layer-group type that allows to define certain settings on all sub-layers. Adding a multi-geometry layer can by default add such a layer. The difference is an opt-in vs. an opt-out approach. Changing the layer geometry type semantic would require to update everything that does not want to use multi-geometry behavior (hence opt-out). A possibly painful story with lots of side-effects that we possibly can't even think of right now. The group approach would allow any component capable of handling multi-geometry types to add possibilities on group-level. With a good API it can be easy to determine if a layer is part of a multitype group. And from the group an iterator can be requested and a hierarchical setting can be introduced (define defaults at group level, override at layer level). I would strongly prefer the second approach. It should allow to do all the cool things and introduce them incrementally without having to deal with all the unintended side-effects of a sudden break in semantics. Do you think there are downsides of this approach? Best regards, Matthias On 04/02/2015 05:07 PM, Olivier Dalang wrote: > Hi, > > Would it really be more complicated ? > > I mean, for now, an algorithm that works only with line layers already > has to check whether the layer is of type line. That's done before > iterating the features. > > Exactly in the same way, there would be functions to determine whether > a layer supports a geometry type or not. > > Then, there would be functions to iterate a particular geometry type > for a layer. > This could be done by adding a geometry type argument to getFeatures, > and/or by adding specific > getLineFeatures/getPointFeatures/getPolygonFeatures functions, > probably throwing exceptions if the layer does not support this > particular type (shapefile or specific geometry column in postgis). > > To me it seems not much different from how it works currently, at > least from a programmer's point of view. Of course it's quite a change > in the API, that's why it's only thoughts for a future QGIS 3 or 4... > > > I don't know Mapinfo at all, but it's good to know there's already > some experience somewhere (even if bad). But do you really think the > problem is in the principle itself, and not in Mapinfo's implementation ? > > > The things at stake are maybe worth the thought still... > The heavy distinction between geometry types is very artificial. > There's a lot of very valid representation of real world phenomenons > of a certain kind that require different geometry types. Having to > distribute those across different layers because of a 25 years old > file format is somewhat sad... > > > Olivier > > > 2015-04-02 16:41 GMT+02:00 Bo Victor Thomsen > <[email protected] <mailto:[email protected]>>: > > As an old MapInfo user/developer my opion is: Don't do it. It has > always been a problem in MapInfo and it will be a problem in QGIS > - if implemented. > > A better approach is to have the possibility to let different QGIS > layers share some common characteristics (for example labelling). > And - of course - clean up the current errors in QGIS when > splitting contents of data sources by object types. > > Regards > Bo Victor Thomsen > AestasGIS > Denmark > > Den 02-04-2015 kl. 13:52 skrev Olivier Dalang: >> 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] <mailto:[email protected]> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > _______________________________________________ > Qgis-developer mailing list > [email protected] <mailto:[email protected]> > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > _______________________________________________ > 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
