[Qgis-developer] Improving ftools geoprocessing tools

[Victor Olaya]

shp is the default format for temp files, and as such it is used in
the modeler for intermediate results. That is, however, very easy to
change, so if we agree on any other format, it can be changed and set
as the default for Processing

2015-10-22 16:08 GMT+02:00 Bernhard Ströbl <bernhard.stroebl at jena.de>:
> Hi Andreas,
>
> AFAIK processing uses shp for in between results in a model, too. So if you
> build a model you loose your fields, no matter which output format you
> choose. IMHO it should therefore be considered to change processing's data
> source. Maybe SpatialLite is an option? Users can still export to shp if
> needed.
>
> Bernhard
>
>
>
> Am 22.10.2015 um 15:48 schrieb 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
>
>
>
> __________ 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