handle QGIS Temporary Scratch Vector Layer inside processing algorithms

[Andreas Janz]

No description provided.

[Benjamin Jakimow]

Which types of QGIS Templayer does this mean?

[Andreas Janz]

@Benjamin Jakimow this is with regard to Temporary Scratch Vector Layers.

As I’m aware, there is no temporary raster layer type in QGIS, right?

[Benjamin Jakimow]

But there might be 3 different types of in-memory vector layers: QgsVectorLayer “memory”, ogr “Memory” and ogr “/vsimem/”

[Andreas Janz]

@Benjamin Jakimow the main problem is, that I in general do all the processing in GDAL/OGR and I’m not using the QGIS API.

Regarding the 3 types you mentioned:

1. is QgsVectorLayer “memory” what you get, when you create a Temporary Scratch Layer in QGIS? If not, how would a user create such a “memory” layer in the QGIS GUI?

   

2. I guess you can not open OGR “Memory” DataSources in QGIS!? What would be the URI that you have to pass to the QgsVectorLayer constructor?

3. OGR “/vsimem/” is no problem, because “/vsimem/…” is a valid URI for QgsVectorLayer and for ogr.Open

‌

[Andreas Janz]

GDAL/OGR can’t handle Temporary Scratch Layers as well. So in each case we fall back to GDAL, we won’t support temp layer. In other cases were we use QGIS API only, we do support temp layer.

[Benjamin Jakimow]

Not being able to handle QGIS memory layers would be a too serious constraint for the EnMAP-Box, in particular because the new Speclibs are based on. There needs to be support using it, e.g. by creating an /vsimem/ copy or similar.

[Andreas Janz]

I could handle this at algorithm level in a single spot here: EnMAPProcessingAlgorithm.parameterAsVectorLayer

Every time the requested vector layer is a Temporary Scratch Layers, I could save it on-the-fly as a QGR layer.

Location could be: ‘/vsimem/<layer.source()>.gpkg’

‌

[Benjamin Jakimow]

Sounds good! This way it should be possible to handle the other QgsVectorDataProviders as well (spatialite, wfs, prostgress, ….).
https://qgis.org/api/classQgsVectorLayer.html#details

Meanwhile I prefer using the QgsVectorLayer API instead of OGR.

[Andreas Janz]

resolves #457

→ <<cset bec42b54acc6>>

[Andreas Janz]

Sounds good! This way it should be possible to handle the other QgsVectorDataProviders as well (spatialite, wfs, prostgress, ….).

Benjamin, please test with your usecases (spatialite, wfs, prostgress, …) and come back to me, if something is not handled correctly