[Qgis-psc] outstanding issues

[Radim Blazek]

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:
>>> 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.
>>> 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.
>>
>> E.g.
>> Ftools dissolve would be a good candidate to be replaced by OGR dissolve
>> which we already have in processing.
>>
>
> I honestly have very large concerns about this approach (handing over
> all these operations to 3rd party tools). Here's a few of my reasons:
>
> - loss of control. We become dependant on third parties fixing bugs,
> which they will do in their own schedule and not necessarily match our
> priorities. Furthermore, we would then have to wait for the fix to be
> released in a stable version, picked up by all our distros and
> distributed. All this would be out of our control, and in some cases
> could take a year or more (depending on upstream's release schedule,
> etc). If we keep these operations in QGIS, we can fix high priority
> issues on our own schedule and release point versions as required.
>
> - we would incur the cost of saving layers out to a temporary file
> before running the operation. This may be expensive compared with
> doing things directly in QGIS, where we can take advantage of the
> various shortcuts available in fetching and processing features.
>
> - lastly, it feels very much like conceding defeat. It's basically
> saying QGIS is good for visualising/editing data, but don't rely on it
> for any serious work. I don't believe this to be true at all!
>
> 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.

+1 for fTools in C++ in QGIS core (core plugin) without dependency on
SAGA/GRASS... maybe not necessarily all, but surely 'Geoprocessing
Tools'.

Hopefully we could also give fTools some more descriptive name.

Radim