<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 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 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 class=""><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">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>