[Qgis-developer] Improving ftools geoprocessing tools

[Andreas Neumann]

Bernhard,

I agree that these tools should be QGIS algorithms - maybe even ported 
from another GIS (if feasible).

One major annoyance with fTools and some processing algorithms is that 
reliance on ESRI shapefile as output. That way I always loose my columns 
- or they are truncated to be meaningless. For that reason I often don't 
use QGIS, but FME for analysis. Or try to do the processing with SQL in 
Postgis.

If we renovate these algorithms in the vector menu we'd have to make 
sure that the output could be any chosen vector format, or at least 
supports geopackage/spatialite/postgres as output.

Andreas

On 22.10.2015 15:26, Bernhard Ströbl wrote:
> IMHO all ftools should be replaced by native QGIS processing 
> algorithms. For "simple" users it may be not feasible (or not allowed) 
> to install additional software. Therefore native QGIS algorithms 
> should be improved to be fast, robust and offering choices the users 
> need (see recent discussion on dissolve)
>
> Bernhard
>
> Am 22.10.2015 um 15:13 schrieb Andreas Neumann:
>> If we'd replace the ftools (vector and raster menu) through processing.
>> What would replace them? Would we do research and see which of the
>> alternative processing providers provides best speed/reliability - if
>> there are multiple versions? It may be, that for Algorithm A, Saga works
>> best, whereas for algorithm B GRASS is better and for C GDAL or the QGIS
>> builtin in mechanism.
>>
>> Andreas
>>
>> On 22.10.2015 14:59, Victor Olaya wrote:
>>>>   * Why is the processing toolbox not an option for your users? (Do 
>>>> you
>>>> require shortcuts (menu entries) to the tools? Is it the parameter
>>>> interface which is more fine-tuned? Missing functionality?)
>>>
>>> If what you need is to have the tools in a menu, we have been
>>> discussing that before, and the idea is to mantain the same menu
>>> structure if the users wants that, but have the algorithms based on
>>> Processing to avoid redundant (and more difficult to mantain) code. As
>>> I said, this has already been discussed, but it is not yet
>>> implemented. Maybe your funding could help us do it?
>>>
>>> And if algorithms are not performant enough, it's clearly better to
>>> put your effort in the Processing ones (which, in general, are just a
>>> copy of the ftools ones), and have them exposed through the menus, as
>>> explained above.
>>>
>>> Regards
>>> _______________________________________________
>>> 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
>
>
>
> __________ Information from ESET Mail Security, version of virus 
> signature database 12448 (20151022) __________
>
> 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