[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