[Qgis-psc] outstanding issues

[ElPaso]

Il 23/11/2015 18:09, Anita Graser ha scritto:
>
> ​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 
> <mailto: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 <mailto:nyall.dawson at gmail.com>> wrote:
>     >> On 22 November 2015 at 06:19, Anita Graser <anitagraser at gmx.at
>     <mailto:anitagraser at gmx.at>> wrote:
>     >>> On Nov 21, 2015 5:07 PM, "Paolo Cavallini"
>     <cavallini at faunalia.it <mailto: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
>
>


Hi Anita,

thanks for the summary.

I just wonder if discussing on qgis-developer wouldn't be useful.

I'm not sure about ho many developers follow this list, maybe other devs 
have something interesting to say.

-- 
Alessandro Pasotti
w3: www.itopen.it