[Qgis-psc] outstanding issues

Radim Blazek radim.blazek at gmail.com
Tue Nov 24 01:14:38 PST 2015


On Sun, Nov 22, 2015 at 7:23 PM, Matthias Kuhn <matthias at opengis.ch> wrote:
>> +1 for fTools in C++ in QGIS core (core plugin) without dependency on
>> SAGA/GRASS... maybe not necessarily all, but surely 'Geoprocessing
>> Tools'.
>>
> Yes, geoprocessing tools will be the most important ones. I wouldn't
> make them a "plugin". They should go into an qgis_analysis library and
> should be available via python bindings (something none of the core
> plugins offers). The standard user interface to trigger them should be
> from the processing toolbox. Or menu shortcuts also created by processing.

I agree that they should got to analysis lib + Python bindings. I
meant a thin core plugin just if we wanted menu entries independent on
Processing (like it works now with fTools) in addition to entries in
Processing.

My impression from the discussion on the HF is, that apart wrong
single/multi geometries handling the biggest problem is most probably
missing spatial index (slowness). I am thinking about something like:

QgsVectorProcessing( QList<QgsVectorLayer*> inputLayers,
QgsVectorLayer* outputLayer, QgsVectorProcessingAlgorithm *alg)

which will build spatial indexes (if necessary) and process each
feature from the first input with all overlapping (or otherwise
defined (distance...)) features from the second (or more) input layers
calling

QgsFeature QgsVectorProcessingAlgorithm::process(QList<QgsFeature>)

QgsVectorProcessingAlgorithm subclasses for standard operations like
intersect, union etc. should also go to core.

That all for 'Statement 3' as defined by Anita.

Radim



More information about the Qgis-psc mailing list