<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Regarding MapInfo as a user:<br>
<br>
<ul>
<li>You can't be sure abut the drawing order for different object
types in a single layer. With multiple types you risk having a
small object (ie point) being hidden by a larger object (ie a
polygon) becuase the polygon is drawn "above" the point.<br>
</li>
<li>Import tab files to different GIS systems that can't handle
multi type layers. When you try to import 1 million object layer
there is always 999999 objects of one type and 1 object of a
different type - and the import will fail. This is confusing for
a lot of users and irritating for the rest.</li>
<li>Thematics in MapInfo does not work properly when used on a
multi object type layer<br>
</li>
</ul>
<br>
Regarding MapInfo as a developer:<br>
<br>
It's a royal pain having to deal with all the possible situations in
a MapBasic script when you have to deal with a layer with multiple
object types. Suddenly a script will fail because it's trying make
an otherwise legal operation on a type of object its not supposed
to deal with. You can of course remedy the situation with a lot of
"if-then-else" type checking or "onerror" goto's but your scripts
readability will be horrible.<br>
<br>
<br>
Regards<br>
Bo Victor Thomsen<br>
AestasGIS<br>
Denmark<br>
<br>
<div class="moz-cite-prefix">Den 04-04-2015 kl. 10:28 skrev Marco
Hugentobler:<br>
</div>
<blockquote cite="mid:551FA093.3090404@sourcepole.ch" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi<br>
<br>
Yes, the implicit assumption that each layer has one geometry
type probably goes back to the shapefile. I agree it is a wrong
design from QGIS to assume that and it is not in line with the
logic of many important datasources (Postgres, Oracle, MS SQL,
WFS and also some OGR formats like dxf), therefore causing
workarounds on the dataprovider level to seperate db tables into
several layers. I think it is best (at least in the long term)
to have a logic compatible to the datasources instead of doing
workarounds at provider and gui level.<br>
<br>
There are many places where this has an impact (e.g. symbology
system, editing). Therefore it will be good to break the 'one
geometry type' assumption not before version 3. A first step
could be to identify the places in core/gui/app where changes
would be needed.<br>
<br>
@Nathan and Victor: I don't have experience with MapInfo. What
is the exact reason why multi-geometries have been
user-unfriendly there?<br>
<br>
Regards,<br>
Marco<br>
<br>
<br>
<br>
On 02.04.2015 13:52, Olivier Dalang wrote:<br>
</div>
<blockquote
cite="mid:CAExk7p2s6_waUrdU6P18_T1Y8L9BNL-o6Lu+o_Hi+Yct1t4LmA@mail.gmail.com"
type="cite">
<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">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">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">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">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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Qgis-developer mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<a moz-do-not-send="true" 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>
<br>
<pre class="moz-signature" cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.sourcepole.ch">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
<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>