[Qgis-developer] fTools - Processing (again)

[Filipe Dias]

Hi

Side note: that are now some ogr2ogr based equivalent algorithms available,
that on average have significantly better performance than their ftools
counterparts. Up until recently the absence of virtual vectors in
Processing did not allow creating algorithms requiring two or more layers.
But that feature was added in the latest developer meeting by Luigi Pirelli.

My point is: it may be worth considering abandoning some ftools algorithms
in favour of ogr2ogr based ones.

Cheers

On Mon, Sep 14, 2015 at 8:31 AM, Matthias Kuhn <matthias at opengis.ch> wrote:

> Hi Bernhard,
>
> The current code redundancy does have some severe issues like:
>
>  * Algorithms may give different results from the vector menu and
> processing (although both labelled similar, [QGIS] Geoprocessing)
>  * Bugs need to be fixed twice
>  * Features need to be implemented twice
>
> If I remember right, somebody was working on a C++ implementation of
> fTools recently. Does that ring a bell somewhere? It would be a pitty if
> you work on this and a new implementation is merged at the same time.
>
> After this question has been answered, a big +1 from my side to work on
> this.
> And another +1 if we get some unittests for the algorithms. They are
> actually perfect candidates for unittests.
>
> Kind regards
> Matthias
>
> On 09/14/2015 09:05 AM, Bernhard Ströbl wrote:
> > Hi Paolo,
> >
> > just a thought: AFAIK fTools does not use 3rd party backends, so the
> > question of bulletproofness in conjunction with fTools IMHO should
> > only be raised for those algorithms that are currently in "QGIS
> > geoalgorithms". (Otherwise I fully agree: the rest should work
> > flawlessly)
> > As I said I would be willing to port what has not been ported yet
> > and/or look over algorithms that do not work as expected.
> > In spring the question of icons has been raised, too. This should not
> > be forgetten, either.
> >
> > Bernhard
> >
> > Am 11.09.2015 um 12:52 schrieb Paolo Cavallini:
> >> Il 11/09/2015 11:29, kimaidou ha scritto:
> >>> +1 for this !
> >>
> >> Hi all,
> >> thanks for raising this point, IMHO a serious one. I'm very much in
> >> favour of removing redundancy. In this case, however, I think we better
> >> be careful before removing fTools, because:
> >>
> >> * people are used to it, and for one-shot analyses it is (slightly)
> >> easier to run than Processing (weak argument)
> >> * we do not have enough development resources to make Processing
> >> bulletproof, particularly for 3rd party backends; therefore, we
> >> encounter occasional problems, and we cannot guarantee a smooth user
> >> experience in all cases (strong argument).
> >>
> >> First issue can be solved, as suggested, by adding menu shortcuts to
> >> Processing analyses, to mimic existing situation.
> >> Second one is more serious: IMHO we really need a dedicated developer in
> >> this area: any power user (=larger institutions) are willing to take it?
> >> Similar things may be said for GDALTools.
> >> All the best.
> >>
> >
> >
> >
> > __________ Information from ESET Mail Security, version of virus
> > signature database 12248 (20150914) __________
> >
> > The message was checked by ESET Mail Security.
> > http://www.eset.com
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150914/b8e3c5af/attachment.html>