[QGIS-Developer] Processing 3.0: Possible change to the Singlepart to Multipart algorithm

[Mathieu Pellerin]

+1, I'm a regular user of that alg & your proposal makes sense. It'll be
useful to have the reduced single to multi geom type within models.

On Jun 27, 2017 6:28 AM, "Nyall Dawson" <nyall.dawson at gmail.com> wrote:

> Hi all,
>
> As you may be aware, I've been working on rebuilding the backend of
> Processing in c++ and refining how it operates.
>
> As part of this I'd like to clear up the list of existing algorithms
> and also refine how they behave. This list of "QGIS" algorithms has
> grown organically during the 2.x cycle, and there's now numerous
> oddities in the selection of available algorithms and their options.
>
> This discussion relates to the "Singlepart to Multipart" algorithm. I'd
> like to:
>
> 1. drop the option for "unique ID field". This option is used to
> 'collect' the geometries from features with matching ID  together into
> a single output geometry. I'd like to remove this option and make the
> "Singlepart to Multipart" algorithm purely upgrade geometry types from
> single part to multipart, without adding any extra parts or collecting
> geometries. So basically the algorithm would upgrade single parts to
> collections containing just a single part - the equivalent of PostGIS'
> ST_Multi function.
>
> 2. Add a new algorithm "Collect parts" which does what the option in
> Singlepart to Multipart used to do. This would collect all features
> with matching fields (you could select more than one field - unlike
> the current Singlepart to Multipart option) and output collection
> features containing these geometries. Just like dissolve, but without
> the dissolving of overlapping parts.
>
> Ideally "collect parts" would be replaced with the more powerful
> "aggregate" algorithm implemented in
> https://github.com/qgis/QGIS/pull/4210, but that's a separate piece of
> work.
>
> The motivations here are:
>
> 1. simplicity of algorithms - keeping the Singlepart to Multipart as
> just a straightforward 'make this geometry multipart type' algorithm,
> without the extra complexity and code inefficiency which comes with
> the current 'unique ID field' support. (Complying with the goal of
> keeping algorithms modular and focused on one particular task)
>
> 2. unlocking future performance gains. Ideally we want algorithms to
> operate feature-by-feature whenever this is possible. This will allow
> us (in some future piece of work) to implement feature pipes where
> features pass through models having operations performed to each
> feature in a chain (instead of the current approach of multiple
> temporary output layers). This isn't planned work (yet), but making
> this algorithm operate feature-by-feature now, while we have the
> luxury of API and model break, will allow it to use these
> optimisations in a future 3.x release. The "unique ID field" support
> prevents this algorithm from operating feature-by-feature.
>
> Thoughts?
>
> Nyall
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170627/c58d5f74/attachment.html>