[Qgis-developer] Thoughts about multi-type tables in QGIS

[Olivier Dalang]

>
> To me, most QGIS geometric operators assume one geometry type. Can you
> explain what king of generic operation you have in mind ?


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.
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...

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...


I think that doing this will generate a complete refactoring of:
> - all processing scripts
> - all ftools
> - all plugins assuming one geometry.


I think there are 3 main cases:

*Geometry type-specific operations*
Of course some operators are specific, and make sense only on some geometry
types (eg. in ftools lines to polygons, polygons centroids, line
intersections).
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).

*Nongeometric operations*
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.

*Geometry-type unspecific operations*
And then, there, are the functions that work on several geometry types
(check geometry validity, buffer, etc..).
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.

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 ?


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).




2015-04-07 15:39 GMT+02:00 Régis Haubourg <
regis.haubourg at eau-adour-garonne.fr>:

> olivier wrote
> >
> >> to me it sounds a bit like loading "varchar" and "float" in the same
> >> column
> >
> >
> > That's exactly what it is not. Generic geometry is a valid and well
> > defined
> > type, and postgis functions behave very well with it. ST_Area for
> instance
> > will return 0 for a point or a line, which is an accurate result and
> makes
> > sense.
> > And while some functions are type-specific, most functions work and make
> > sense on all types (spatial relations, buffer, bounding boxes, validity,
> > transformation, simplification, conversion...).
> >
> > If you split your data in different tables (or columns), you loose the
> > ability to use any of those functions on all your records at once
> (without
> > some complex query that won't be doable in QGIS UI), which IMO is really
> a
> > pity...
>
>  Hi , to me, most QGIS geometric operators assume one geometry type. Can
> you
> explain what king of generic operation you have in mind ?
>
> I think that doing this will generate a complete refactoring of:
> - all processing scripts
> - all ftools
> - all plugins assuming one geometry.
>
> Again, I can't see from how in QGIS GUI that can improve things for most
> users, without making it more heavy and complex. And that would be very
> costy. Any mockup welcome, that can help me change my opinion..
> All the best,
> Régis
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Thoughts-about-multi-type-tables-in-QGIS-tp5196607p5200245.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150408/de605315/attachment.html>