Tag: en_gb

Credits : Bru-nO (Pixabay Content License)

Thanks to funding from the Bordeaux Metropolis, I had the chance to work on CMYK (Cyan Magenta Yellow blacK) support in QGIS. The metropolis’ goal is to remove the last barrier preventing their complete migration from ArcGIS to QGIS.

The developments are now complete and will be available in QGIS version 3.40, scheduled for release in October 2024, before becoming the next LTR in February 2025. It should be noted, however, that CMYK support will only be complete in QGIS versions built with Qt 6 (still unofficial version) for reasons explained in the article. On Windows, this version can currently only be installed using OSGeo4W (qgis-qt6-dev version).

EDIT: Actually, QGIS version built with Qt 6.8, which ships the needed modifications for CMYK PDF export, is not yet released. More information here.

What is CMYK?

You probably know RGB, which allows you to code a color on screen by choosing the amount of red, green and blue in that color. You may also use TSL or TSV.

RVB – Credits : Daniel Roberts (Pixabay Content License)

These 3 color references allow a color to be coded for a screen, while CMYK targets printers by allowing to set the exact quantity of ink that will be released during printing (hence the 4 CMYK components, one per ink cartridge).

CMYK ( here from left to right KCMY ) – Credits : Magnascan (Pixabay Content License)

The characteristics of CMYK differ greatly from RGB, it’s considered a subtractive colorimetric mode, because the ink absorbs light unlike RGB which is said to be additive, the more red, green, blue you have the closer you are to full light, white.

The intrinsically different nature of these 2 color spaces means that it is strongly advised not to convert from one to the other. The best is to choose a color in a space (CMYK for printing, RGB for rendering on screen) and stick to it.

Worse, printing the same color is different depending on the printer, ink, paper… The choice of a CMYK color has to be done in a color space, represented by a ICC profile file, provided by your printer. It is a bit like a color chart used when choosing paint.

Now you can argue about the REALLY good color of a road line – Credits : Yanis Ladjouzi (Pixabay Content License)

Developments in QGIS… and Qt

It is now possible in QGIS to:

• Enter colors in CMYK format, and in floating precision;
• Define your preferred color mode (RGB or CMYK) and your color space;
• Generate a file in PDF/X-4 format (ready for printing) embedding a color space and using CMYK colors;
• Allow the expression engine to manipulate CMYK colors without converting them to RGB;
• Manage CMYK color ramps;
• Lots of other small improvements and corrections about color management.

Selecting colors in QGIS in CMYK

The beautiful story of Open source

I took great pleasure in participating in this development because it is the result of the collaboration of many players in free software.

During a first phase of study concerning the support of CMYK in QGIS, we quickly identified that Qt, the framework used by QGIS for rendering maps, has limitations. It converts all colors to RGB when rendering maps in PDF format and its support for CMYK color spaces is incomplete.

It is therefore necessary to make it evolve. We therefore turn to our preferred partner when it comes to Qt, KDAB, and more precisely Giuseppe D’Angelo who then carries out the necessary developments.

Regarding new features, these are only available in Qt 6 (Qt 5 is end of life). This is why CMYK support is incomplete in official versions of QGIS still based on Qt 5.

QGIS.org, the association that oversees the QGIS project, decided to fund the developments on Qt. Oslandia, on the other hand would have to manage these developments and then to carry out the integration in QGIS. This integration as well as the related new features was funded by the Bordeaux metropolis.

My developments were then reviewed by other QGIS contributors. (If you want to know more about the QGIS contribution process, you can read a previous blog post about software quality in QGIS)

Finally, I wanted to give a special thanks to Jehan, developer on the GIMP project. His availability and thoroughness in our mail exchanges greatly helped me understand the technical and functional issues of CMYK, and most certainly contributed to the quality of the result.

Next

QGIS 3.40 will therefore be able to generate a PDF/X-4 file using CMYK colors. Qt, for its part, improves CMYK support, PDF writing, and color space management.

Thanks again to the Bordeaux metropolis and QGIS.org for funding these developments, and all the people involved in their realization.

We would be delighted to have feedback from users on your use cases related to color management in QGIS. Do not hesitate to write to us or comment on our posts to tell us how you use these features.

These foundations in the management of color spaces in QGIS open the door to future improvements. If you are interested in this topic and would like to contribute, please contact us at infos+qgis@oslandia.com and check out our QGIS support offer.

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.