[Qgis-psc] outstanding issues

[Anita Graser]

​Hi,

I would like to summarize the statements​ concerning ftools so far, see
statement 1-3 inline.

On Sun, Nov 22, 2015 at 7:23 PM, Matthias Kuhn <matthias at opengis.ch> wrote:
>
> On 11/22/2015 10:45 AM, Radim Blazek wrote:
> > On Sun, Nov 22, 2015 at 10:07 AM, Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
> >> On 22 November 2015 at 06:19, Anita Graser <anitagraser at gmx.at> wrote:
> >>> On Nov 21, 2015 5:07 PM, "Paolo Cavallini" <cavallini at faunalia.it>
> wrote:
>
​​
> ​
> ​
> >>>> I'm still unsure we should replicate existing code: the problems have
> >>>> been solved over and over in similar code (the closest being saga,
> also
> >>>> C++), and redoing things instead of reusing and integrating them does
> >>>> not sound right to me. I believe the approach we took with GDALTools
> was
> >>>> more efficient.​


​Statement 1: Don't replicate existing code. Build on existing libraries.


> >>>> Il 20/11/2015 18:44, Tim Sutton ha scritto:
> >>>>> Folks can I ask that we move the thread back to the practical issues
> of
> >>>>> plotting a roadmap to solving our FTools issues rather than pursuing
> >>>>> this avenue which is a dead-end in terms of getting a usable FTools
> into
> >>>>> the hands of our users.
> >>>> I think the best we can do now is do do a minimal fix of broken tools,
> >>>> spending as little as possible, relying as much as possible on
> geos7ogr,
> >>>> waiting for a more solid approach.
> Agreed, a minimal fix should be shipped soon.
>

​Statement 2: ​Implement minimal fixes in Python now. Explore other options
for the future.


> >> Honestly, I don't think it's a huge amount of work to port these tools
> >> to c++ implementations. A large amount of the work is already done in
> >> the geometry classes and there ready for use, and we have some
> >> existing python code (ftools and processing algs) which we can use as
> >> a starting point for the port. And the benefit would be that we would
> >> then have QGIS-optimised implementations ready to go for use by
> >> core/processing/other plugins. And we'd be able to fix bugs and modify
> >> these operations as required by QGIS.
>
> I also think it's worth providing a set of spatial algorithms, by having
> them in our own code, we can integrate them much better than external
> tools. No extra conversion into whatever proxy dataformat, better
> integration with the QGIS architecture and a unified release schedule
> are good reasons.
>

​Statement 3: QGIS needs it's own core spatial algorithms.​ Avoid
dependencies and unnecessary conversions between data formats.

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.

Procedure-wise, I'm wondering who should vote on the motion: core devs? PSC?

Best wishes,
Anita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151123/d3c94089/attachment.html>