Tag: en_gb

A hydraulic engineer by training, Nicolas Godet has been working at ISL Ingénierie for just over seven years and holds the position of hydraulic project manager (flood risk, hydraulic structure safety), deputy director of the Saint-Jean-de-Luz facility, and QGIS (and GIS in general) advisor.

He discusses the implementation of QDT and the associated methodology for deploying QGIS across ISL’s IT infrastructure.

What are the objectives of the collaboration?

Before I took charge of deploying QGIS at ISL, it was a bit of a mess: no one had the same version, the same plugins, or the same practices.
Following the switch to QGIS3, there was a desire to standardize the QGIS fleet at ISL to have the same version, the same plugin base, and preconfigured profiles.

An initial, semi-homemade solution was implemented in 2022, but it proved difficult to maintain.

At the end of 2024, with a budget allocated, we decided to seek assistance from Oslandia to professionalize our QGIS deployment so that every employee would be using the same version:

• facilitate project sharing within ISL and with our clients,
• have a common and up-to-date plugin base,
• benefit from advanced pre-configuration of user profiles.

The ultimate goal was to be able to update QGIS without disrupting all the configurations.

What challenges does this project address?

The challenge was to be able to keep up with developments in QGIS while retaining profile configurations. Having attended a few presentations (QGIS Days), I had heard about QDT. After preliminary discussions with Oslandia (and in particular with Julien Moura), we agreed to go ahead with customized training. This customized training allowed us to adapt the content to our needs.

How did the collaboration with Oslandia go?

The Oslandia teams are attentive, adapt to our needs, which are not always simple, and were able to offer us tailor-made training.

We decided to have four half-days spread out over several weeks, allowing us to cover the theory and a few examples during the half-day, then work on our own and come back to the next session with questions and ask for more in-depth coverage of certain points rather than others.
There’s not much else to add except that it went very well!

Since this training, ISL has been able to invest in QDT.

Sorry, this entry is only available in French.

The conversation around Looking for better ways to convert between QGIS VectorLayer and (Geo)DataFrame is continuing over at https://fosstodon.org/@underdarkGIS/115442614331293320

What I’ve learned so far:

• QgsVectorLayer.as_geopandas() has landed in QGIS master on 13 Oct 2025.
• There’s also QgsVectorLayer.field_to_numpy() which will be useful for many applications and has landed on 29 Oct 2025.
• QgsArrowIterator is in the works right now.

Exciting times for spatial data science tooling

Plugin developers who want to use (Geo)Pandas-based functionality in their plugins regularly face the challenge of converting QGIS vector layers to (Geo)DataFrames. There is currently no built-in convenience function.

In Trajectools, so far, I have been performing the conversion manually, looping through all features and taking care of tricky column types, such as datetimes and geometries:

def df_from_layer_trajectools(layer,time_field_name="t"):
    # Original Trajectools 2.7 version
    names = [field.name() for field in layer.fields()]
    data = []
    for feature in layer.getFeatures():
        my_dict = {}
        for i, a in enumerate(feature.attributes()):
            if names[i] == time_field_name and isinstance(a, QDateTime):
                a = a.toPyDateTime()
            my_dict[names[i]] = a
        pt = feature.geometry().asPoint()
        my_dict["geom_x"] = pt.x()
        my_dict["geom_y"] = pt.y()
        data.append(my_dict)
    df = pd.DataFrame(data)
    return df

It works (mostly), but it’s far from fast. For the 25 million Geolife points, it takes 4 minutes:

In an attempt to speed-up (and make the conversion more robust, e.g. regarding datetime/timezone conversion and null values), I’ve spent some time at SDSL2025 with Joris Van den Bossche trying a workaround that writes the QGIS layer to an Arrow file and then reads that file with pyogrio:

def gdf_from_layer_arrow(layer):
    # SDSL2025 version
    with tempfile.TemporaryDirectory() as tmpdirname:
        path = os.path.join(tmpdirname, "data.arrow")

        options = QgsVectorFileWriter.SaveVectorOptions()
        options.actionOnExistingFile = QgsVectorFileWriter.CreateOrOverwriteFile 
        options.layerName = 'data'
        options.driverName = "arrow"
        
        QgsVectorFileWriter.writeAsVectorFormatV3(
            layer, path, QgsProject.instance().transformContext(), options
        )
       
        meta, table = pyogrio.read_arrow(path)
        gdf = gpd.GeoDataFrame.from_arrow(table)

    return gdf

Not only do we get a GeoDataFrame in return, this also runs in half the time, i.e. in 2 minutes instead of 4:

Switching to this approach will require adding pyogrio to the plugin dependencies. Looks like it could be worth it.

We also discussed another alternative: It would be faster to read the vector layer data source directly, in case it is a supported file format. However, this means we’d need separate handling for other input layers.

There’s also the issue of supporting the Processing feature that allows users to run the algorithm only on the selected features because selected features are only exposed through QgsProcessingParameterFeatureSource (and not through QgsProcessingParameterVectorLayer). Maybe the Export Selected Features algorithm can cover this case but it will export an empty layer if there is no selection.

Are you aware of any other / better ways to approach this issue? Any pointers are appreciated.

Sorry, this entry is only available in French.

Sorry, this entry is only available in French.