[Qgis-psc] outstanding issues

[Matthias Kuhn]

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:
>>>> 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.

>>>> 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.

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.

> +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.
Yes, geoprocessing tools will be the most important ones. I wouldn't
make them a "plugin". They should go into an qgis_analysis library and
should be available via python bindings (something none of the core
plugins offers). The standard user interface to trigger them should be
from the processing toolbox. Or menu shortcuts also created by processing.

Matthias

>
> Radim
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc

-- 
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source