[Qgis-developer] Processing NG/V2 - brainstorming

Richard Duivenvoorde rdmailings at duif.net
Tue Dec 6 02:56:39 PST 2016


On 05-12-16 10:03, Nyall Dawson wrote:
> Hi all,

Hi Nyall et al. Good thinking, just wondering... what is NG/V2? :-)

> So here we go... a bunch of random ideas on future processing enhancements:
>
> 1. Rework native algorithms to avoid layer input/outputs

I have seen some people creating huge FME workbenches, and what I see is 
that these models are almost never 'linear'.. that is: never work in 
'efficient pipes'. But often more like: we grab some data from here, 
from there, combine, do something on it, calculate something from the 
whole, reproject and rewrite some attributes and output it to ... a db.

I mean to say: some kind of intermediate disk-format is needed anyway?
What I have heard from 'the others' is that they use some binary 
(spatially indexed?) file format? Would that be an option for us?
Looking to the python world where you can 'pickle' arbitrary objects to 
disk. Is there something like that available in cpp?

> 2. Georeferenced geometries

> So my current preference would be for QgsGeometry to gain a
> QgsCoordinateReferenceSystem member variable, which is an invalid crs
> if the geometry is not referenced. This should still be quite
> lightweight given that QgsCoordinateReferenceSystem is implicitly
> shared.

Would adding a epsg/crs code not be enough? In postgis/oracle spatial 
there is also a crs-code in every geometry isn't it? Not sure about that...

> 3. Porting components of processing to core
>
> There's demand (from eg QField) to reuse parts of processing outside of PyQGIS.
>
> I think good candidates for porting to core would be:
> - parameters
> - inputs
> - the algorithm base class

This all means a stronger api isn't it? To be implemented in whatever 
language you prefer? That is always good isn't it :-)

Regards,

Richard Duivenvoorde


More information about the Qgis-developer mailing list