Getting a pixel count and area size of unique values for a given raster layer hasn’t been straightforward in QGIS. The user could either go through third-party solutions via processing with some limitations, or create a (slow) python script.

That is, until now. Say hello to the newly-committed processing algorithm, the “raster layer unique values report”.

The QGIS algorithm will take a raster layer as input and output an HTML formatted report listing the pixel count and area size – in the raster layer’s unit - for all unique values. Thanks to QGIS core developer Nyall Dawson’s fantastic work on the processing platform in upcoming QGIS 3.0, the algorithm is written in C++ and therefore much faster - over a tenfold improvement - to an equivalent python script.

Using QGIS’ processing modeler, users can come up with a simple model to provide unique values reports within areas of interests, defined through vector polygons:

For example, using the newly-updated 2016 Global Forest Change dataset and the model above, we can quickly generate a deforestation per year chart. Simply reproject the dataset in the appropriate meter-based projection, clip it with a national boundaries polygon, et voila. Paste the resulting HTML table into your favorite spreadsheet program and enjoy the charts:

(This blog post might as well have been titled “QGIS ❤ Wallpapers”)

Over the span of a week, QGIS received a set of improvements which greatly improved the canvas’ save as image function, as well as a brand new save as PDF feature.

Queue the usual slide of improvements:

Adding output resolution, width and height settings effectively frees users from the confine of their physical screen. Being able to fine tine the width and height in pixel also helps cartographers producing maps best-fitted for web-based content.

Saving as PDF feature is a real time saver, offering a fast path to vector export of maps without the need to go through creating a composer, adding a map item, etc.

All of these improvements are very useful to improve quick n’ dirty map export. It is however no replacement to the powerful QGIS composers. On that front, a QGIS core developer at North Road has launched a crowd funding campaign to modernize composers. For those cartographers out there publishing maps on various media forms (print, online, ebooks), seriously consider supporting this campaign.

QGIS’ handling of color ramps has just gotten much better with a series of improvements we committed to the open source project’s upcoming version 3.0.

This slide goes through brief summary of changes: Color ramp handling, made fun!

On the developer front, one nice improvement is the addition of an invert() function directly attached to color ramp classes (QgsColorRamp and its children). This removed the need for symbol layers and renderers to implement individual invert-related functions; those are now served with a customized source color ramp, with edited steps and/or reversed order already taken into account.

TL;DR if all goes according to plan, the next major version of QGIS will feature an updated set of core libraries; among the many benefits this will bring is support for proper rendering for a whole new range of complex languages

QGIS has long been recognized for its excellent Unicode encoding support which enables handling of data and the rendering of maps in a wide range of languages, including but not limited to complex Indic-based writing sytems such as Khmer or Lao.

This is possible in large part due to QGIS’ underlying foundation: Qt. As part of the forthcoming 3.0 release, QGIS is planning to leave Qt4 behind – which has for years now gone into maintenance-only mode - and upgrade to actively developed Qt5, the framework's latest version. This is a significant change and it is cause for celebration as it will come with a wide range of ameliorations all around, across all platforms.

Over here, we are particularly excited about one specific improvement: the revamped text shaping engine.

The what?

Text shaping is the process through which text is converted into glyphs and positioned to form characters. In Qt, that process is handled by a library called harfbuzz. Under Qt4, the library relies on its first generation codebase. Under Qt5 however, a rebooted library codebase (referred to as harfbuzz-ng) is used.

The difference between those two libraries? Over four years worth of improvements! The source tree of the original harfbuzz library saw its last commit on July 30, 2012. The harfbuzz-ng tree however is actively developed, with its latest release, 1.3.0, dating July 21, 2016.

Tangible benefits

Based in Southeast Asia, we routinely produce maps featuring complex languages from the region. One such language is Burmese, which Qt4 simply does not support due to its use of harfbuzz’s first generation codebase.

When rendering Burmese language with QGIS compiled against Qt4, things looked like this:

The glyphs’ shapes and positioning are all wrong, resulting in illegible text. For those who are not familiar with Indic-based languages such as Burmese, the above would be like taking the following text “I love QGIS!” and rendering it “LvQg e! SIo”.

When compiled against Qt5, powered by harfbuzz-ng, QGIS properly shapes Burmese text:

Hurray! 🎉

For those interested in building QGIS against Qt5, follow the instructions on this post by OpenGIS.

Note: Windows users have not – contrary to Linux users - been virtually stuck in 2012 when it comes to text rendering as Qt4 defers to the system’s uniscribe library to do shaping; uniscribe is actively developed by Microsoft with new versions shipped alongside Windows updates.

When producing localized cartographic products, we often have to render numbers - integer and float values - in languages that do not make use of Arabic numerals. For instance, in the map above, area values (in red) are rendered in Thai, based on a numerical field.

In QGIS, until now, users could create an expression-based label that would use a series of replace() function embedded into one another against an numerical field to dynamically localize the numbers:

replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(“my_integer_field”,'0','๐'),'1','๑'),'2','๒'),'3','๓'),'4','๔'),'5','๕'),'6','๖'),'7','๗'),'8','๘'),'9','๙')

To say it didn’t look very good is a gross understatement.

In upcoming version 3.0, the expression engine’s replace() function got upgraded to support arrays (and map) replacement parameters, making for a much cleaner syntax.

For e.g., this is how an expression to convert Arabic numerals into Thai numerals look like:

replace(“my_integer_field”,map('0','๐','1','๑','2','๒','3','๓','4','๔','5','๕','6','๖','7','๗','8','๘','9','๙'))

With a simple replace call, QGIS now allows for on-the-fly localization of number fields. Couple that with the virtual fields feature, users can also have the localized values show up in the attribute table:

Over the last few weeks, we’ve been busy improving the user interface as well as adding features to QGIS’ style management system. The end result is a streamlined experience with better exposure to saved symbols’ management tools such as tagging and a newly-implemented favorites system.

This slide offers an brief overview of the changes, part of upcoming QGIS 3.0:

We also took the time to update the default set of saved symbols shipped with QGIS:

The new set better serves users looking for usable predefined set of symbols. It also does a good job at reflecting the cartographic capabilities of the software.

For adventurous Linux-based OS users able to compile QGIS, these improvements are now available on the master branch. For Windows users, work is under way to make QGIS 3.0’s underlying libraries available.

TL;DR if all goes according to plan, the next major version of QGIS will feature an updated set of core libraries; among the many benefits this will bring is support for proper rendering for a whole new range of complex languages

QGIS has long been recognized for its excellent Unicode encoding support which enables handling of data and the rendering of maps in a wide range of languages, including but not limited to complex Indic-based writing sytems such as Khmer or Lao.

This is possible in large part due to QGIS’ underlying foundation: Qt. As part of the forthcoming 3.0 release, QGIS is planning to leave Qt4 behind – which has for years now gone into maintenance-only mode - and upgrade to actively developed Qt5, the framework's latest version. This is a significant change and it is cause for celebration as it will come with a wide range of ameliorations all around, across all platforms.

Over here, we are particularly excited about one specific improvement: the revamped text shaping engine.

The what?

Text shaping is the process through which text is converted into glyphs and positioned to form characters. In Qt, that process is handled by a library called harfbuzz. Under Qt4, the library relies on its first generation codebase. Under Qt5 however, a rebooted library codebase (referred to as harfbuzz-ng) is used.

The difference between those two libraries? Over four years worth of improvements! The source tree of the original harfbuzz library saw its last commit on July 30, 2012. The harfbuzz-ng tree however is actively developed, with its latest release, 1.3.0, dating July 21, 2016.

Tangible benefits

Based in Southeast Asia, we routinely produce maps featuring complex languages from the region. One such language is Burmese, which Qt4 simply does not support due to its use of harfbuzz’s first generation codebase.

When rendering Burmese language with QGIS compiled against Qt4, things looked like this:

The glyphs’ shapes and positioning are all wrong, resulting in illegible text. For those who are not familiar with Indic-based languages such as Burmese, the above would be like taking the following text “I love QGIS!” and rendering it “LvQg e! SIo”.

When compiled against Qt5, powered by harfbuzz-ng, QGIS properly shapes Burmese text:

Hurray! 🎉

For those interested in building QGIS against Qt5, follow the instructions on this post by OpenGIS.

Note: Windows users have not – contrary to Linux users - been virtually stuck in 2012 when it comes to text rendering as Qt4 defers to the system’s uniscribe library to do shaping; uniscribe is actively developed by Microsoft with new versions shipped alongside Windows updates.

When producing localized cartographic products, we often have to render numbers - integer and float values - in languages that do not make use of Arabic numerals. For instance, in the map above, area values (in red) are rendered in Thai, based on a numerical field.

In QGIS, until now, users could create an expression-based label that would use a series of replace() function embedded into one another against an numerical field to dynamically localize the numbers:

replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(“my_integer_field”,'0','๐'),'1','๑'),'2','๒'),'3','๓'),'4','๔'),'5','๕'),'6','๖'),'7','๗'),'8','๘'),'9','๙')

To say it didn’t look very good is a gross understatement.

In upcoming version 3.0, the expression engine’s replace() function got upgraded to support arrays (and map) replacement parameters, making for a much cleaner syntax.

For e.g., this is how an expression to convert Arabic numerals into Thai numerals look like:

replace(“my_integer_field”,map('0','๐','1','๑','2','๒','3','๓','4','๔','5','๕','6','๖','7','๗','8','๘','9','๙'))

With a simple replace call, QGIS now allows for on-the-fly localization of number fields. Couple that with the virtual fields feature, users can also have the localized values show up in the attribute table:

Over the last few weeks, we’ve been busy improving the user interface as well as adding features to QGIS’ style management system. The end result is a streamlined experience with better exposure to saved symbols’ management tools such as tagging and a newly-implemented favorites system.

This slide offers an brief overview of the changes, part of upcoming QGIS 3.0:

We also took the time to update the default set of saved symbols shipped with QGIS:

The new set better serves users looking for usable predefined set of symbols. It also does a good job at reflecting the cartographic capabilities of the software.

For adventurous Linux-based OS users able to compile QGIS, these improvements are now available on the master branch. For Windows users, work is under way to make QGIS 3.0’s underlying libraries available.