<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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<br>
<br>
<div class="moz-cite-prefix">On 04/02/2015 05:07 PM, Olivier Dalang
wrote:<br>
</div>
<blockquote
cite="mid:CAExk7p3OHHGot0ude1W5yV6OWpj4WsWvG8qSHuA4HgBLY4p8bg@mail.gmail.com"
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 moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888"> Bo Victor
Thomsen<br>
AestasGIS<br>
Denmark <br>
</font></span>
<div>
<div class="h5"> <br>
<div>Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 class="">
<pre>_______________________________________________
Qgis-developer mailing list
<a moz-do-not-send="true" href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Qgis-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>