[Qgis-developer] Improving ftools geoprocessing tools

[Bernd Vogelgesang]

Am 22.10.2015, 16:14 Uhr, schrieb Victor Olaya <volayaf at gmail.com>:

> 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

+1000 Yes, please, get rid of this pain in the a.. as soon as possible and  
use SpatiaLite e.g..
Creating these files might take considerably longer and they consume more  
space, but compared to the time I spend refactoring column names all the  
time and finding workarounds, this is nothing.
It's also one of the reasons why I do my heavy lifting work in R nowadays.

Cheers
Bernd

> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374