[QGIS-Developer] QGIS 3 > Processing: some test

[Nyall Dawson]

On 10 June 2017 at 10:05, Giovanni Manghi <giovanni.manghi at gmail.com> wrote:
> Hi Nyall,
>
>> Native, GDAL, grass and saga will be ported. It's low on my priority
>> list right now though, so if anyone wants to step forward and port
>> these now then it'd be much appreciated. My priorities are:
>>
>
> I could help with gdal/ogr ones

Thanks - that'd be much appreciated! I'll post a public message on
this list when I consider it's time for people to start helping out
with the alg porting. For now, I think it's better if I fix a few more
known regressions first so that the porters aren't bumping into these
bugs.

I'll write up a bit of a guide too.

>> - we have had some algs which were available in 2.x removed. This
>> breaks existing models which used those algorithms.
>
> there is a list?

I'd have to trawl back through the git history to find it. From memory
it may have been something about split or dissolve.


>> We have a lot of
>> duplicate functionality spread across the QGIS algs, which would be
>> good to address for 3.0
>
> true, is also true that some redundancy has helped a lot in the past.
> For example the geoprocessing tools based on ogr2ogr and spatial
> queries (that I plan to expand
> since a long time now), in several cases have been proven faster and
> more reliable than native ones.
> If they are not welcome in QGIS3 no problem, I can make a Processing
> plugin out of them, I'm sure

Just to clarify - I'm not referring to duplicate functionality across
providers, but rather duplicate functionality inside the QGIS
provider. For instance, there's an alg "Polygon from layer extent".
This alg has an option "Calculate extent for each feature separately",
which is redundant given that there's a dedicated alg "bounding boxes"
which does exactly this. There's lots of this kind of duplicate
functionality as a result of the organic nature of the growth in qgis
algorithms, which I think should be cleaned up to both reduce
redundant code and also make processing more usable and algorithms
more discoverable.

I'm strongly in favour of the duplicated functionality in algorithms
from *different* providers, and see the obvious benefits there.

> it will be anyway preferred to native tools that frequently just
> return the wrong result (see several tickets
> on unions, intersections, differences and the alike).

Our (hopefully friendly!) rivalry on this point continues :) I think I
can win you over for 3.0 when we widely rollout the massive benefits
which are possible only in native algs, such as the support for
dynamic parameters. But we'll see....

But on the topic of the incorrect unions/intersections/etc, I agree
this is harmful and bad for QGIS. Perhaps this should be a focus in
future pre-release bug fixing rounds?

Nyall