<div dir="ltr">Hi,<div><br></div><div>I think the topic of handling multiple geometry columns in one table and the topic of handling multiple geometries types in one column are distinct.</div><div>They don't overlap and we can do one, or the other, or both.</div><div><br></div><div><br></div><div><b>Multitypes</b></div><div><br></div><div>I'm a bit surprised at how many of you have the strong opinion that handling mixed geometries is a bad idea. The most recurring argument is that Mapinfo did it, and it sucks.</div><div><br></div><div><div>So I'd still like a bit more details about what went so wrong with Mapinfo... Here are Bo Victor's points.</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px"><font color="#0b5394">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.</font></span></blockquote><div> </div><div><span style="font-size:12.8000001907349px">Couldn't we use QGIS drawing order options for this, to make sure that by default, we have points, then lines, then polygons ?</span></div><div><span style="font-size:12.8000001907349px">The case can also happen where you want polygons in front of points, so having the ability to change that using drawing order could even be considered a feature.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px"><font color="#3d85c6">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.</font></span></blockquote><div> </div><div><span style="font-size:12.8000001907349px">Yes that's true, but we are not talking about creating any new file type here. The case you're talking about only happens when the user mistakenly chooses to create a multityped column while he actually wanted to model only a particular type of features. This won't happen most of the time, since unexperienced users tend to use shapefiles that are mono typed. We could consider adding some kind of warning in the UI before creating multityped columns in spatialite/postgis, but honestly, at this point, there are already tons of other</span><span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">possible</span><span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">mistakes for people who are unfamiliar with GIS (single/multipart, 2d/3d, projection, nullable columns, etc.).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Still, we'd have probably to implement something for exportation of multityped layers to monotyped formats. It could be a bit like the "export selected features only" checkbox, except that there would be radio buttons to choose which type to export.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font color="#3d85c6"><span style="font-size:12.8000001907349px">Thematics in MapInfo does not work properly when used on a multi object type l</span><span style="font-size:12.8000001907349px">ayer</span></font></blockquote><div> </div><div>That really sounds like an implementation problem, or is there some classification that are feature-type specific ?</div><div><br></div><br style="font-size:12.8000001907349px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px"><font color="#3d85c6">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.</font></span></blockquote></div><div><br></div><div>Doesn't the solution of type-specific iterators solve this ? (plus the fact that multityped layer wouldn't be considered as Point/Line/Polygon layers).</div><div><br></div><div><br></div><div><br></div><div>Bernard thanks for your use case.</div><div>But as you say, it's workarounds, and I'm pretty sure it gets confusing for your user when they want to display say "all compensating features planned after 2008", since they'll have to run the filter on all the three tables.</div><div>Even worse if they want to do some changes in the attributes using the field calculator, they have to remember that each layer actually only shows a third of the actual data, risking to cause some trouble if they don't...</div><div><br></div><div><br></div><div>About use cases, I have two that I'm currently meeting :</div><div><br></div><div><u>Event data management</u></div><div>I have a postgis table for historical events, which can be of any geometrical type.</div><div>The events can have links to other events (using references like previous_event_id).</div><div>Currently, I have to add the postgis table four times. Once for each geometry type, plus once as a no-geometry table so that I can have the full attribute table to be able to use the relations widget.</div><div>At this point, every setting (filtering, labels, actions, symbols...) must be made four times, which starts to become annoying (could be improved : #12303).</div><div>The file is also quite complex to use, because one must know that the four different layers are actually the same.</div><div>All scripting around this setup becomes quite tricky since I have to check four layers instead of one. Python actions that depend on selection are very complex to do for instance : I need the reference to the other layers that represent the same table, and must deal with four selections instead of one.</div><div>And then there's the question of performance, where having four layers probably results in having four times as many queries.</div><div><br></div><div><div><u>CAD data in QGIS</u></div><div>I have some CAD data (.dxf) that I want to be able to show in some projects of mine. Those contain lines and polygons. Currently, I have to load the layer twice, and do my filtering separately on each layer. Nothing impossible, but still I need to do the same operation twice each time I want to change my filters.</div></div><div><br></div><div><u>Other cases...</u></div><div>I think if one day we want QGIS to be able to work in write access to formats like geojson or csv (with wkt representation), we'd need this kind of support.</div><div>That would be great, and I definitely believe these kind of formats already started to grow more and more important, so that we'll want to have that in near future.</div><div><br></div><div><br></div><div><br></div><div><div>In short, I know in most cases it's much better to work with specific geometry types. I'm not arguing against that at all, and I'm not saying we should go towards using mixed-types file formats all over (that would indeed be terrible).</div><div><br></div><div>It's just that there are some cases where the data you model is effectively of mixed geometry types, and that the artificial separation of types brings quite some complications to their editing and display in QGIS, while it's pretty straightforward at database level.</div></div><div><br></div><div>And moreover, we would keep the possibility to load a mixed-type layer as a mono-type layer (current implementation), so we wouldn't loose anything.</div><div><br></div><div><br></div><div><br></div><div><b>Multi-columns</b><br><div><br></div><div>Nyall I like your idea very much.</div><div>I always found it a bit disturbing not to see the geometry in the table view, while it's just another column from a data point of view.</div><div>There are some things to think about from an UI point of view :</div><div>- distinguish the geometry column used by qgis to display the layer on the map from the others</div><div>- would it be possible to sort the attribute table using some of the geometries attribute you're mentioning ? (validity, number of points, rings, etc.)</div><div>- make distinction between "delete geometry" and "delete record" very clear (would there be a map tool to delete a geometry)</div><div>- probably allow to edit geometries directly on the map, rather than only by entering wkt text (in case of edits of the main geometry, simply activate the edit node tools on the chosen geometry, in case of edits on another geometry, display it using an editable rubber band)</div></div><div><br></div><div>But if I get it correctly, your idea is to support other geometries merely as attributes (with the specific fact that they can be used for things such as label placement), not to support alternative geometries on the map canvas, right ?</div><div>Denis is that what you were suggesting ?</div><div><br></div><div>(Well maybe it would be better to start another topic on this ;) )</div><div><br></div><div><br></div><div><br></div><div>At least all of this is food for thoughts !!</div><div><br></div><div>Best,</div><div><br></div><div>Olivier</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-06 12:08 GMT+02:00 Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 3 April 2015 at 01:41, Bo Victor Thomsen <<a href="mailto:bo.victor.thomsen@gmail.com">bo.victor.thomsen@gmail.com</a>> wrote:<br>
> As an old MapInfo user/developer my opion is: Don't do it. It has always<br>
> been a problem in MapInfo and it will be a problem in QGIS - if implemented.<br>
<br>
</span>Count me in as another MapInfo graduate who has seen the mess which<br>
multi-type tables cause and isn't in favour of this approach.<br>
<br>
That said, I'm very interested in this conversation as it touches on<br>
some thoughts/work I've been tackling lately. I think there's some big<br>
improvements we can make as to how QGIS handles geometries in a layer.<br>
<br>
I often work with layers which have a mix of null/not null geometries.<br>
It's important for me to be able to easily edit tables of this form,<br>
including adding new records with no geometry to the table. This isn't<br>
currently (easily) achievable in QGIS. You can add geometries to an<br>
existing record, remove the geometry from a record, add a new record<br>
with a geometry but you can't add a record without a geometry.<br>
<br>
I've been thinking of modifying the attribute table to show geometry<br>
columns. This would be done via a new QgsGeometryWidget widget, which<br>
would display the geometry type ((multi)point/line/polygon) and a<br>
button with an attached menu for clear geometry/copy as wkt/copy as<br>
geojson/paste geometry options. Actually, this is already written -<br>
see <a href="https://github.com/nyalldawson/QGIS/commit/fc7c79fb322bf3f6d681bb3a013efea941517767" target="_blank">https://github.com/nyalldawson/QGIS/commit/fc7c79fb322bf3f6d681bb3a013efea941517767</a><br>
. This could be extended with the suggestions from<br>
<a href="http://hub.qgis.org/issues/10283" target="_blank">http://hub.qgis.org/issues/10283</a> and the functionality from the<br>
plain-geometry-editor plugin.<br>
<br>
Then, we could add a new "Add record" button to the attribute table<br>
dialog for adding a new (empty) row, which would initially contain no<br>
geometry. That fixes the first part of my issues with geometry<br>
columns.<br>
<br>
On 4 April 2015 at 07:59, Régis Haubourg<br>
<span class=""><<a href="mailto:regis.haubourg@eau-adour-garonne.fr">regis.haubourg@eau-adour-garonne.fr</a>> wrote:<br>
<br>
> The only thing annoying me currently is that QGIS "sees" all geometry<br>
> columns when this slow down attribute view a lot. In 1.8 or before (can't<br>
> remember), QGIS did not see them and that was fine to me, and avoided to<br>
> type SQL in DBmanager to add correctly the data in QGIS.<br>
<br>
</span>This is my second big issue with geometry handling. I think the<br>
solution would be to use the proposed QgsGeometryWidget as the default<br>
editor for geometry columns in the dialog. This would avoid the issue<br>
of massive WKT strings choking the table and grinding QGIS to a halt.<br>
However, this relies on implementation of the suggestion from Martin<br>
here:<br>
<a href="http://osgeo-org.1560.x6.nabble.com/Multiple-geometry-columns-per-layer-tp5019573p5019895.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/Multiple-geometry-columns-per-layer-tp5019573p5019895.html</a><br>
<br>
If this suggestion was implemented, then it also opens the possibility<br>
of having data defined geometry overrides for symbology/labeling. Eg,<br>
a table could have an additional line geometry column for label<br>
placement overrides. If this line geometry is not null then it would<br>
be used as the geometry for label placement, otherwise it would fall<br>
back to the actual feature's geometry. Think along the lines of<br>
manually curved labels for selected polygons...<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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></div></div></blockquote></div><br></div>