+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" <[email protected]> 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
