Re: [Qgis-developer] Improving ftools geoprocessing tools

Am 22.10.2015, 13:30 Uhr, schrieb João Gaspar : Dear QGIS Developers, I'm writing on behalf of my employer, a company that has mixed, proprietary and open source (especially QGIS of course) gis infrastructure, with qgis being adopted each day a little more. Actually

Re: [Qgis-developer] Improving ftools geoprocessing tools

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

Re: [Qgis-developer] Improving ftools geoprocessing tools

> The issue here is about the lousy performances (and even wrong > results) of the native qgis vector geoprocessing tools. I think we all > agree that qgis should have a few (at least the most commonly used) > ones, without depending on any 3rd party software. I fully agree on that Do we have

Re: [Qgis-developer] Improving ftools geoprocessing tools

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

Re: [Qgis-developer] Improving ftools geoprocessing tools

2015-10-22 15:13 GMT+02:00 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

Re: [Qgis-developer] Improving ftools geoprocessing tools

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

Re: [Qgis-developer] Improving ftools geoprocessing tools

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:

Re: [Qgis-developer] Improving ftools geoprocessing tools

> Icon support is already in Processing. The first versions actually > used the same ftools icons, but I removed that because there were new > algorithms being added, and it was quite messy to see some algorithms > with icons and others with the default icon. Instead, I started using > the same

Re: [Qgis-developer] Improving ftools geoprocessing tools

Am 22.10.2015, 16:14 Uhr, 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

Re: [Qgis-developer] Improving ftools geoprocessing tools

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,

Re: [Qgis-developer] Improving ftools geoprocessing tools

QGIS 3.0 seems to be a good moment/opportunity to terminate ftools and replace the menu items to be shortcuts to processing algorithms. M On 22 Oct 2015 19:59, "Victor Olaya" wrote: > > > > * Why is the processing toolbox not an option for your users? (Do you > > require

Re: [Qgis-developer] Improving ftools geoprocessing tools

/me adding "icon" to the list of actions Therefore the plan of action should be: * Add icon support to processing * Create menu entries for often used (internal) processing algorithms * Remove ftools algorithms * Identify slow algorithms * Improve performance Cheers Matthias On 10/22/2015

Re: [Qgis-developer] Improving ftools geoprocessing tools

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

Re: [Qgis-developer] Improving ftools geoprocessing tools

Hi Matthias, the issues are the following: there is whole universe of very basic users that need to do classic geoprocessing operations (clips, unions, etc.) sometimes also with large/dense geometries, possibly with geometry errors. This users are usually not able to handle (or willingly to)

Re: [Qgis-developer] Improving ftools geoprocessing tools

Some time ago Carson ported at least some fTools algorithms to QGIS analysis library. Maybe we can revise this code, update it and then reuse in Processing and 3rd party plugins? Core implementation should be faster than Python code, also maybe we can adopt multithreading approach for some

Re: [Qgis-developer] Improving ftools geoprocessing tools

Hi João, Nice that there is interest in improving the analysis part of QGIS. There was recently a similar discussion with Bernhard Ströbl who also put some effort into improving the dissolve tool (although it turned out to be complex and will probably only be merged in 2.14). In the discussion

Re: [Qgis-developer] Improving ftools geoprocessing tools

> > * 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

Re: [Qgis-developer] Improving ftools geoprocessing tools

Yep. I think the user-friendliness of ftools are that a/ algorithms are offered in a simple and accessible menu items, and b/ the menu item icons _greatly_ ease the understanding of what algorithms do. Both can be added to processing. On 22 Oct 2015 20:26, "Matthias Kuhn"

Re: [Qgis-developer] Improving ftools geoprocessing tools

>> >> Yep. I think the user-friendliness of ftools are that a/ algorithms >> are offered in a simple and accessible menu items, and b/ the menu >> item icons _greatly_ ease the understanding of what algorithms do. >> Icon support is already in Processing. The first versions actually used the

Re: [Qgis-developer] Improving ftools geoprocessing tools

On Thu, Oct 22, 2015 at 3:27 PM, Victor Olaya wrote: >> The issue here is about the lousy performances (and even wrong >> results) of the native qgis vector geoprocessing tools. I think we all >> agree that qgis should have a few (at least the most commonly used) >> ones,

Re: [Qgis-developer] Improving ftools geoprocessing tools

Giovanni, Would (some of) these datasets be suitable to include in unit tests for processing? It would be very interesting to have these available for this purpose. Matthias On 10/22/2015 05:07 PM, Giovanni Manghi wrote: > On Thu, Oct 22, 2015 at 3:27 PM, Victor Olaya wrote: