<div dir="auto">I understand and agree on having "atomic" algorithms but I'm not sure if we can always consider single features as the unique operating level. I know this would bring benefits to the code engineering but we have to keep in mind the end users expectations.<div dir="auto"><br></div><div dir="auto">I agree with Mathias, probably we should have atomic/feature level core algorithms and "processing algorithms" using them for higher level structures (datasets) in case they fit the task better.</div><div dir="auto"><br></div><div dir="auto">my 2 cents.</div><div dir="auto">giovanni</div></div><div class="gmail_extra"><br><div class="gmail_quote">Il 27 giu 2017 21:06, "Anita Graser" <<a href="mailto:anitagraser@gmx.at">anitagraser@gmx.at</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 7:45 AM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 6/27/17 7:19 AM, Paolo Cavallini wrote:<br>
<br>
> Hi Nyall,<br>
><br>
> Il 27/06/2017 01:41, Nyall Dawson ha scritto:<br>
><br>
>>> This discussion relates to the "Convex Hull" algorithm. I'd like to:<br>
>>><br>
>>> 1. Drop the "Field (optional, only used if creating convex hulls by<br>
>>> classes)" option and the accompanying method choice used to set the<br>
>>> convex hull to 'create convex hulls based on field'.<br>
><br>
> I understand the rationale behind this; I'm just a bit worried it will<br>
> be more complicated and less understandable for users.<br>
> Perhaps adding another module that does both commands (collect + convex<br>
> hull) in one shot would be useful?<br>
> All the best.<br>
<br>
</span>Maybe there is the need to ship some often-used models by default then?<br>
Thinking of code complexity and maintainability, it makes much sense to<br>
modularize algorithm code as much as possible<br>
</blockquote><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">​I absolutely understand the reason from an engineering point. From the user point - and as someone answering a lot of user questions - it is predictable that end users will be confused. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Idea: Have a warning if a user tries to run the new "convex hull" on a dataset with single part geometries?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Best wishes,</div><div class="gmail_default" style="font-size:small">Anita​</div><br></div><div> </div></div><br></div></div>
<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><br></blockquote></div></div>