[Qgis-developer] Improving ftools geoprocessing tools

[Bernhard Ströbl]

What what be a suitable format? It should
1) support all geometry types needed
2) be fast
3) support spatial indices?
4) support long (unlimited) field names
5) support all necessary field types
6) store its data on local hd

anything else?

Bernhard

Am 22.10.2015 um 16:14 schrieb 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