<div dir="ltr">Hi Nyall and others,<br><br><div class="gmail_quote"><div dir="ltr">Le mar. 21 août 2018 à 07:09, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 20 Aug 2018 at 23:17, DelazJ <<a href="mailto:delazj@gmail.com" target="_blank">delazj@gmail.com</a>> wrote:<br>
><br>
> Good day devs,<br>
><br>
> [...]<br>
><br>
> I have some concerns/questions:<br>
><br>
> -"translate" vs "array of offset features": why not just add the "number of features to create" parameter to the translate algorithm instead of having created a new one?<br>
> - "offset lines" vs "create parallel lines": same question as above, in favor of the offset lines algorithm<br>
<br>
My personal preference is to keep individual algorithms as simple as<br>
possible, and have additional algorithms covering similar use cases. I<br>
prefer this over the GRASS/SAGA algorithm approach of having one<br>
algorithm with a multitude of parameters which interact in different<br>
ways. In this case the algorithms have been separated into "vector<br>
creation" algorithms (array of offset features, create parallel lines)<br>
vs "geometry modification" algorithms (translate, offset lines).<br>
<br>
There's also the consideration that the vector creation algorithms<br>
also include the original feature by design - if you wanted to do this<br>
same thing by adding a "number of features" to the translate/offset<br>
lines algorithm, then you'd either need to add *another* parameter for<br>
"include original feature" OR require users to do some manual feature<br>
copy/pasting to append the original feature to the new table. Neither<br>
option is desirable in my view.<br>
<br></blockquote><div>OK, for some reasons I didn't notice that the "array of offset features" also returned the original feature, hence my assumption that this behavior in the "create parallel lines" was a bug and the differences between the algs was only features multiplication. Makes sense to have different algs in this case.</div><div><br></div><div> However I wonder if "number of features to create" is the appropriate label; what about "number of copies to create" or "number of offsets to create" given that when you enter 4, you get 5 features in the new layer (including the original feature)? I'd expect 4 *features* as requested.<br></div><div><br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> [...]<br>
<br>
>   - Would that be possible to review the description and insert this homothetic idea so that people understand clearly that one do copy the same features and the other one may be different?<br>
<br>
Improving the algorithm's tags/short description/short help would<br>
always be appreciated!<br>
<br></blockquote><div>sure. Never doubt that. See <a href="https://github.com/qgis/QGIS/pull/7687">https://github.com/qgis/QGIS/pull/7687</a> (reducing the use of the word "offset"). Hoping that i get what it's about this time.</div><div>. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> with less algs, there will be less translation to do and I hope less confusion around this concept.<br>
<br>
...but I'm a strong -1 to squashing these operations into the same algorithm.<br>
<br></blockquote><div>See my above comment about having overlooked some features of the new algs. When reading the algs description, the relation with the "single featured" alg is not obvious to me; maybe reusing chunks of description would have helped.<br></div><div>This comment was also for a general point of view: I don't know how it's handled, but if we could try to reuse existing labels, this will reduce translators and doc writers workload. A simple example (from memory, sorry) "leave blank to use layer name" vs "leave empty to use layer name"</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>   - and I still wonder if "create parallel lines" and "array of offset features" are not inverted names: in my mind, "array of offset features" sounds closer to "offset lines" than to "translate" which in turn is looks closer to "create parallel lines".<br>
<br>
I dislike the name "array of offset features", but it was the best one<br>
Mathieu and I could think of. Maybe it should be "array of translated<br>
features"/"array of offset lines"? I'd be happy to accept a PR giving<br>
them better names!<br>
<br></blockquote><div>My point here was that the alg that actually does the "parallel thingies" is the so-called "array of offset features" and the "create parallel lines" actually creates offset features.</div><div> I'm ok with the "array of tranlated features" to replace "array of offset features". As said earlier, an offset geometry often seems to not be the "same" geometry while this alg does keep it. Done in the aforementioned PR.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - what about allowing polygons for the currently called "offset lines" and "create parallel lines" algs?<br>
<br>
Isn't that basically the same as buffer/multi-ring buffer (followed by<br>
taking the boundary of the result).<br><br></blockquote><div>Maybe in this order (would need to check the returned geometry) because generating the boundary first (either with the 'boundary' or the 'polygon to line' alg or drawing a closed linestring) then running the "create parallel lines" or "offset lines" alg does not return a closed linestring (which I think should be the expected result). Bug (should I file a ticket?) or I again missed something?<br></div><div><br> </div><div>Harrissou<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nyall<br>
<br>
><br>
> Regards,<br>
> Harrissou<br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">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/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div></div>