[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