<div dir="ltr"><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">To me, most QGIS geometric operators assume one geometry type. Can you<br></span><span style="font-size:12.8000001907349px">explain what king of generic operation you have in mind ?</span></blockquote><div><br></div><div>By generic operations I mean mostly any type of operation you're doing all the time on your data : exporting, converting, projecting, selecting, listing, sorting, deleting, etc... All of those which you can't do properly if they're split in three different layers.</div><div>I'm not that much thinking of specific algorithms such as polygons centroid computation or network analysis, that do indeed work on specific layers types only most of the time, and wouldn't make sense on mixed geoms...</div><div><br></div><div>Still, if we are to implement mixed type layers handling in QGIS, we should indeed have some decent support of them in our tool set...</div><div><br></div><div><br></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">I think that doing this will generate a complete refactoring of:<br></span><span style="font-size:12.8000001907349px">- all processing scripts<br></span><span style="font-size:12.8000001907349px">- all ftools<br></span><span style="font-size:12.8000001907349px">- all plugins assuming one geometry.</span></blockquote><div><br></div><div>I think there are 3 main cases:</div><div><br></div><div><u>Geometry type-specific operations</u></div><div>Of course some operators are specific, and make sense only on some geometry types (eg. in ftools lines to polygons, polygons centroids, line intersections).</div><div>Those actually are the less critical, because they would simply continue to work as they do currently, which is by letting the user choose only layers of that particular type (so there would be no way to use "lines intersections" on a mixed layer, unless you'd load it as a line layer as you can currently).</div><div><br></div><div><u>Nongeometric operations</u></div><div>Then, there are other which are not working on geometries at all (such as random selection, basic statistics, etc.). We'd have to check whether the code contains references to QgsGeometry, and if  not, they should work already.</div><div><br></div><div><u>Geometry-type unspecific operations</u></div><div>And then, there, are the functions that work on several geometry types (check geometry validity, buffer, etc..).</div><div>For those, they already must check the geometry type at some point. Either at layer selection, in which case we'd have to hookup our feature-specific iterators instead of the regular feature iterator. Either in the core of the algorithm, in which case we wouldn't have to do anything and they should work.</div><div><br></div><div>Then, there is the most problematic case, which is the output. What to output if user selects a shapefile for the output of "multipart to single parts" on a mixed layer for instance. Probably we'd have to restrict the input layers based on the output layers. Or is there some automatic limitation done by OGR, where it does for instance only export the first encountered geomtry type ?</div><div><br></div><div><br></div><div>But I think you're right, and it will be quite some work. A good timing would be to do it at the same time we rework the overlap between the toolbox and ftools (as far as I can see, it seems like one day we'll drop ftools, and keep processing only, where all this filtering of input/output can easily be managed in a very unified fashion).</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-07 15:39 GMT+02:00 Régis Haubourg <span dir="ltr"><<a href="mailto:regis.haubourg@eau-adour-garonne.fr" target="_blank">regis.haubourg@eau-adour-garonne.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">olivier wrote<br>
<span class="">><br>
>> to me it sounds a bit like loading "varchar" and "float" in the same<br>
>> column<br>
><br>
><br>
> That's exactly what it is not. Generic geometry is a valid and well<br>
> defined<br>
> type, and postgis functions behave very well with it. ST_Area for instance<br>
> will return 0 for a point or a line, which is an accurate result and makes<br>
> sense.<br>
> And while some functions are type-specific, most functions work and make<br>
> sense on all types (spatial relations, buffer, bounding boxes, validity,<br>
> transformation, simplification, conversion...).<br>
><br>
> If you split your data in different tables (or columns), you loose the<br>
> ability to use any of those functions on all your records at once (without<br>
> some complex query that won't be doable in QGIS UI), which IMO is really a<br>
> pity...<br>
<br>
</span> Hi , to me, most QGIS geometric operators assume one geometry type. Can you<br>
explain what king of generic operation you have in mind ?<br>
<br>
I think that doing this will generate a complete refactoring of:<br>
- all processing scripts<br>
- all ftools<br>
- all plugins assuming one geometry.<br>
<br>
Again, I can't see from how in QGIS GUI that can improve things for most<br>
users, without making it more heavy and complex. And that would be very<br>
costy. Any mockup welcome, that can help me change my opinion..<br>
All the best,<br>
Régis<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/Thoughts-about-multi-type-tables-in-QGIS-tp5196607p5200245.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/Thoughts-about-multi-type-tables-in-QGIS-tp5196607p5200245.html</a><br>
<span class="im HOEnZb">Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.<br>
</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>