<div dir="auto">+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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 27, 2017 6:28 AM, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As you may be aware, I've been working on rebuilding the backend of<br>
Processing in c++ and refining how it operates.<br>
<br>
As part of this I'd like to clear up the list of existing algorithms<br>
and also refine how they behave. This list of "QGIS" algorithms has<br>
grown organically during the 2.x cycle, and there's now numerous<br>
oddities in the selection of available algorithms and their options.<br>
<br>
This discussion relates to the "Singlepart to Multipart" algorithm. I'd like to:<br>
<br>
1. drop the option for "unique ID field". This option is used to<br>
'collect' the geometries from features with matching ID  together into<br>
a single output geometry. I'd like to remove this option and make the<br>
"Singlepart to Multipart" algorithm purely upgrade geometry types from<br>
single part to multipart, without adding any extra parts or collecting<br>
geometries. So basically the algorithm would upgrade single parts to<br>
collections containing just a single part - the equivalent of PostGIS'<br>
ST_Multi function.<br>
<br>
2. Add a new algorithm "Collect parts" which does what the option in<br>
Singlepart to Multipart used to do. This would collect all features<br>
with matching fields (you could select more than one field - unlike<br>
the current Singlepart to Multipart option) and output collection<br>
features containing these geometries. Just like dissolve, but without<br>
the dissolving of overlapping parts.<br>
<br>
Ideally "collect parts" would be replaced with the more powerful<br>
"aggregate" algorithm implemented in<br>
<a href="https://github.com/qgis/QGIS/pull/4210" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/4210</a>, but that's a separate piece of<br>
work.<br>
<br>
The motivations here are:<br>
<br>
1. simplicity of algorithms - keeping the Singlepart to Multipart as<br>
just a straightforward 'make this geometry multipart type' algorithm,<br>
without the extra complexity and code inefficiency which comes with<br>
the current 'unique ID field' support. (Complying with the goal of<br>
keeping algorithms modular and focused on one particular task)<br>
<br>
2. unlocking future performance gains. Ideally we want algorithms to<br>
operate feature-by-feature whenever this is possible. This will allow<br>
us (in some future piece of work) to implement feature pipes where<br>
features pass through models having operations performed to each<br>
feature in a chain (instead of the current approach of multiple<br>
temporary output layers). This isn't planned work (yet), but making<br>
this algorithm operate feature-by-feature now, while we have the<br>
luxury of API and model break, will allow it to use these<br>
optimisations in a future 3.x release. The "unique ID field" support<br>
prevents this algorithm from operating feature-by-feature.<br>
<br>
Thoughts?<br>
<br>
Nyall<br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></blockquote></div></div>