[Qgis-psc] outstanding issues

[Nyall Dawson]

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:
>>
>> Hi all,
>>
>> 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.

Just my 2c.
Nyall