<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">​Hi,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would like to summarize the statements​ concerning ftools so far, see statement 1-3 inline. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 22, 2015 at 7:23 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On 11/22/2015 10:45 AM, Radim Blazek wrote:<br>
> On Sun, Nov 22, 2015 at 10:07 AM, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br>
>> On 22 November 2015 at 06:19, Anita Graser <<a href="mailto:anitagraser@gmx.at">anitagraser@gmx.at</a>> wrote:<br>
>>> On Nov 21, 2015 5:07 PM, "Paolo Cavallini" <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>> wrote:<br></span></blockquote><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote"><div class="gmail_default" style="font-size:small;display:inline">​​</div>​<div class="gmail_default" style="color:rgb(80,0,80);display:inline">​</div><span style="color:rgb(80,0,80)">>>>> I'm still unsure we should replicate existing code: the problems have<br></span><span style="color:rgb(80,0,80)">>>>> been solved over and over in similar code (the closest being saga, also<br></span><span style="color:rgb(80,0,80)">>>>> C++), and redoing things instead of reusing and integrating them does<br></span><span style="color:rgb(80,0,80)">>>>> not sound right to me. I believe the approach we took with GDALTools was<br></span><span style="color:rgb(80,0,80)">>>>> more efficient.</span>​</blockquote></div><div><br></div><div><div class="gmail_default" style="font-size:small">​Statement 1: Don't replicate existing code. Build on existing libraries. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>>>> Il 20/11/2015 18:44, Tim Sutton ha scritto:<br>
>>>>> Folks can I ask that we move the thread back to the practical issues of<br>
>>>>> plotting a roadmap to solving our FTools issues rather than pursuing<br>
>>>>> this avenue which is a dead-end in terms of getting a usable FTools into<br>
>>>>> the hands of our users.<br>
>>>> I think the best we can do now is do do a minimal fix of broken tools,<br>
>>>> spending as little as possible, relying as much as possible on geos7ogr,<br>
>>>> waiting for a more solid approach.<br>
</span>Agreed, a minimal fix should be shipped soon.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Statement 2: ​Implement minimal fixes in Python now. Explore other options for the future. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
>> Honestly, I don't think it's a huge amount of work to port these tools<br>
>> to c++ implementations. A large amount of the work is already done in<br>
>> the geometry classes and there ready for use, and we have some<br>
>> existing python code (ftools and processing algs) which we can use as<br>
>> a starting point for the port. And the benefit would be that we would<br>
>> then have QGIS-optimised implementations ready to go for use by<br>
>> core/processing/other plugins. And we'd be able to fix bugs and modify<br>
>> these operations as required by QGIS.<br>
<br>
</div></div>I also think it's worth providing a set of spatial algorithms, by having<br>
them in our own code, we can integrate them much better than external<br>
tools. No extra conversion into whatever proxy dataformat, better<br>
integration with the QGIS architecture and a unified release schedule<br>
are good reasons.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Statement 3: QGIS needs it's own core spatial algorithms.​ Avoid dependencies and unnecessary conversions between data formats. </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think we also need to make a decision. Therefore, I'd like to suggest to make a motion on Statement 2 and set everything in motion to get minimal bug fixes ready for the next release. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Procedure-wise, I'm wondering who should vote on the motion: core devs? PSC?</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><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""></div></blockquote></div><br></div></div>