<div dir="ltr">To me, the solution of grouping layers sounds more like a hack. I think it will result in some quite complex code and probably UI.<div><br></div><div>It involves as you say something like inheritance or synchronization of settings. It raises some difficult questions about the link with the underlying db (does each sublayer have it's own dataprovider, or is it somehow shared by the layers ?). It's not clear how the UI would treat linked layers (how is the edit mode synced between the grouped layers, is the selection model shared across the layers ? ...). What about features like joins ? And so on...</div><div><br></div><div>If find all of this quite an overkill and a bunch of potential hard to debug problems.</div><div><br></div><div><br><div><div></div><div>I know the approach I suggest induces some changes in the API, but I think the changes would not even be that huge. I'm not even sure they would be breaking changes ?<br></div><div><br></div><div>If I'm not mistaken, currently, the (only?) way to know what feature type will be returned by QgsVectorLayer->getFeatures(...) is QgsVectorLayer->geometryType()</div><div><br></div><div>Multi-typed layer could simply return a new QGis::GeometryType ('MixedGeometry' or something).</div><div><br></div><div>This way, current code would still work. Of course, you would not be able to choose a mixed geometry layer for an algorithm that only allows to work with Line layers, but that's actually quite normal, since a mixed layer is not a line layer.</div><div><br></div><div>Then, we would add the </div><div><span style="font-size:12.8000001907349px">getLineFeatures/</span><span style="font-size:12.8000001907349px">getPointFeatures/</span><span style="font-size:12.8000001907349px">getPolygonFeatures functions (or add an argument to getFeatures), that would allow to iterate only specific types, for algorithms that are designed to work on </span>MixedGeometry<span style="font-size:12.8000001907349px"> layers.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Am I missing something (would this break the API) ? </span></div><div><span style="font-size:12.8000001907349px">Or do you have in mind some things that it could break ?</span></div><div><span style="font-size:12.8000001907349px">Probably as Denis said map tools would require most work. They'd be disabled on mixed layers until we fix them, and we may need some more helper functions to fix those easily (for instance a feature-type filter for snapping).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">And then, the most tricky part, we would need to find a clever way for the UI. We'd have to find a clever way to display geometry-type specific settings that don't clutter the UI when we work on a mono-typed layer.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><div><span style="font-size:12.8000001907349px">Actually, the more I think about, the more I think we shouldn't even consider point/line/polygons as subcategories of a layer.</span></div><div><span style="font-size:12.8000001907349px">They should be able to sit next to each other in one normal layer.</span></div><div><span style="font-size:12.8000001907349px">This would need some work, on the legend for instance (there can be up to 3 symbols per legend item), some work on toolbars and editing tools, but I don't see anything unsolvable here.</span></div></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><br></div><div><div><div>Best,</div><div><br></div><div>Olivier</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-03 20:12 GMT+02:00 Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
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.<br>
<br>
The difference is an opt-in vs. an opt-out approach.<br>
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.<br>
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).<br>
<br>
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.<br>
<br>
Do you think there are downsides of this approach?<br>
<br>
Best regards,<br>
Matthias<div><div class="h5"><br>
<br>
<div>On 04/02/2015 05:07 PM, Olivier Dalang
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>Would it really be more complicated ?<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Exactly in the same way, there would be functions to
determine whether a layer supports a geometry type or not.</div>
<div><br>
</div>
<div>Then, there would be functions to iterate a particular
geometry type for a layer.</div>
<div>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).</div>
<div><br>
</div>
<div>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...</div>
<div><br>
</div>
<div><br>
</div>
<div>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 ?</div>
<div><br>
</div>
<div><br>
</div>
<div>The things at stake are maybe worth the thought still...</div>
<div>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...</div>
<div><br>
</div>
<div><br>
</div>
<div>Olivier</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-04-02 16:41 GMT+02:00 Bo Victor
Thomsen <span dir="ltr"><<a href="mailto:bo.victor.thomsen@gmail.com" target="_blank">bo.victor.thomsen@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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. <br>
<br>
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.<br>
<br>
Regards <br>
<span><font color="#888888"> Bo Victor
Thomsen<br>
AestasGIS<br>
Denmark <br>
</font></span>
<div>
<div> <br>
<div>Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>In some projects of mine, I work with
multiple geometry types in one postgis table,
using a column of type <font style="background-color:rgb(238,238,238)" face="monospace, monospace">geometry(Geometry,4326)</font>.</div>
<div>This is very well supported by postgis.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This works more or less. There are a few bugs
though :</div>
<div>- <a href="http://hub.qgis.org/issues/12499" target="_blank">http://hub.qgis.org/issues/12499</a>
(you can edit other type's node with the node
tool)</div>
<div>- <a href="http://hub.qgis.org/issues/12500" target="_blank">http://hub.qgis.org/issues/12500</a>
(other type's records are shown in the attribute
table)</div>
<div><br>
</div>
<div>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...</div>
<div>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.</div>
<div>For now, you must do all settings three
times, because of this bug/feature request :</div>
<div>- <a href="http://hub.qgis.org/issues/12303" target="_blank">http://hub.qgis.org/issues/12303</a>
(copy/paste style from one geometry type to
another)</div>
<div><br>
</div>
<div><br>
</div>
<div>As you see, support multiple geometry types
in QGIS is not perfect.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This is probably especially relevant when
thinking long term (the day we support 3D,
curves, etc...).</div>
<div><br>
</div>
<div><br>
</div>
<div>What do you think ?</div>
<div>Do you think the relation 1 layer = 1
geometry type will hold ?</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>There's this feature request (6th oldest open
issue on the tracker) about postgis geometry
collections : <a href="http://hub.qgis.org/issues/167" target="_blank">http://hub.qgis.org/issues/167</a></div>
<div><br>
</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
<div>Olivier</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<span>
<pre>_______________________________________________
Qgis-developer mailing list
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Qgis-developer mailing list
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br></div>