[Qgis-psc] outstanding issues

[Tim Sutton]

Hi

> On 23 Nov 2015, at 20:05, ElPaso <elpaso at itopen.it> wrote:
> 
> 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.

I think its fine for doing it but lets:

1) Go to the list with a concrete proposal rather than an open ended discussion
2) Time cap the conversation so we can move over to action ASAP

@Anita thanks for summarising. From my side, I agree with the three points you made.

Regards

Tim

> 
> -- 
> Alessandro Pasotti
> w3: www.itopen.it
> 
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc




Tim Sutton
QGIS Project Steering Committee Member
tim at qgis.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151123/544b243c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 9882 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151123/544b243c/attachment.tiff>