Page 1 of 89 (1774 posts)

  • talks about »

Tags

Last update:
Sat Jan 21 00:30:20 2017

A Django site.

QGIS Planet

Small multiples for OD flow maps using virtual layers

In my previous posts, I discussed classical flow maps that use arrows of different width to encode flows between regions. This post presents an alternative take on visualizing flows, without any arrows. This style is inspired by Go with the Flow by Robert Radburn and Visualisation of origins, destinations and flows with OD maps by J. Wood et al.

The starting point of this visualization is a classic OD matrix.

migration_raw_data

For my previous flow maps, I already converted this data into a more GIS-friendly format: a Geopackage with lines and information about the origin, destination and strength of the flow:

migration_attribute_table

In addition, I grabbed state polygons from Natural Earth Data.

At this point, we have 72 flow features and 9 state polygon features. An ordinary join in the layer properties won’t do the trick. We’d still be stuck with only 9 polygons.

Virtual layers to the rescue!

The QGIS virtual layers feature (Layer menu | Add Layer | Add/Edit Virtual Layer) provides database capabilities without us having to actually set up a database … *win!*

Using a classic SQL query, we can join state polygons and migration flows into a new virtual layer:

virtual_layer

The resulting virtual layer contains 72 polygon features. There are 8 copies of each state.

Now that the data is ready, we can start designing the visualization in the Print Composer.

This is probably the most manual step in this whole process: We need 9 map items, one for each mini map in the small multiples visualization. Create one and configure it to your liking, then copy and paste to create 8 more copies.

I’ve decided to arrange the map items in a way that resembles the actual geographic location of the state that is represented by the respective map, from the state of Vorarlberg (a proud QGIS sponsor by the way) in the south-west to Lower Austria in the north-east.

To configure which map item will represent the flows from which origin state, we set the map item ID to the corresponding state ID. As you can see, the map items are numbered from 1 to 9:

small_multiples_print_composer_init

Once all map items are set up, we can use the map item IDs to filter the features in each map. This can be implemented using a rule based renderer:

small_multiples_style_rules

The first rule will ensure that the each map only shows flows originating from a specific state and the second rule will select the state itself.

We configure the symbol of the first rule to visualize the flow strength. The color represents the number number of people moving to the respective district. I’ve decided to use a smooth gradient instead of predefined classes for the polygon fill colors. The following expression maps the feature’s weight value to a shade on the Viridis color ramp:

ramp_color( 'Viridis',
  scale_linear("weight",0,2000,0,1)
)

You can use any color ramp you like. If you want to use the Viridis color ramp, save the following code into an .xml file and import it using the Style Manager. (This color ramp has been provided by Richard Styron on rocksandwater.net.)

<!DOCTYPE qgis_style>
<qgis_style version="0">
  <symbols/>
    <colorramp type="gradient" name="Viridis">
      <prop k="color1" v="68,1,84,255"/>
      <prop k="color2" v="253,231,36,255"/>
      <prop k="stops" v="0.04;71,15,98,255:0.08;72,29,111,255:0.12;71,42,121,255:0.16;69,54,129,255:0.20;65,66,134,255:0.23;60,77,138,255:0.27;55,88,140,255:0.31;50,98,141,255:0.35;46,108,142,255:0.39;42,118,142,255:0.43;38,127,142,255:0.47;35,137,141,255:0.51;31,146,140,255:0.55;30,155,137,255:0.59;32,165,133,255:0.62;40,174,127,255:0.66;53,183,120,255:0.70;69,191,111,255:0.74;89,199,100,255:0.78;112,206,86,255:0.82;136,213,71,255:0.86;162,218,55,255:0.90;189,222,38,255:0.94;215,226,25,255:0.98;241,229,28,255"/>
    </colorramp>
  </colorramps>
</qgis_style>

If we go back to the Print Composer and update the map item previews, we see it all come together:

small_multiples_print_composer

Finally, we set title, legend, explanatory texts, and background color:

migration

I think it is amazing that we are able to design a visualization like this without having to create any intermediate files or having to write custom code. Whenever a value is edited in the original migration dataset, the change is immediately reflected in the small multiples.


New major release: GRASS GIS 7.2.0 available

We are pleased to announce the stable release of GRASS GIS 7.2.0

What’s new in a nutshell

After almost two years of development the new stable major release GRASS GIS 7.2.0 is available. It provides more than 1950 stability fixes and manual improvements compared to the former stable release version 7.0.5. The new version includes a series of new modules to analyse raster and vector data along with new temporal algebra functionality.More than 50 new addons are also available. A summary of the new features is available at New Features in GRASS GIS 7.2.

About GRASS GIS 7: Its graphical user interface supports the user to make complex GIS operations as simple as possible. The updated Python interface to the C library permits users to create new GRASS GIS-Python modules in a simple way while yet obtaining powerful and fast modules. Furthermore, the libraries were again significantly improved for speed and efficiency, along with support for huge files. A lot of effort has been invested to standardize parameter and flag names. Finally, GRASS GIS 7 comes with a series of new modules to analyse raster and vector data, along with a full temporal framework. For a detailed overview, see the list of new features. As a stable release series, 7.2.x enjoys long-term support.

Binaries/Installer download:

Source code download:

More details:

See also our detailed announcement:

First time users may explore the first steps tutorial after installation.

About GRASS GIS

The Geographic Resources Analysis Support System (https://grass.osgeo.org/), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The GRASS Development Team, December 2016

The post New major release: GRASS GIS 7.2.0 available appeared first on GFOSS Blog | GRASS GIS Courses.

2017 Hackfests and Summer Camp

Where is QGIS being developed?

That is a questions my students often ask. Open Source is a strange and new ‘world’ for most of them. So I try to explain: QGIS is a software, developed and maintained from all over the world by developers who are employed by companies, self-employed or working for free…

Some of the work is paid for by QGIS and some by users and as written – some do it for free – yay!  The core developers meet two times a year for ‘Hackfests’  (do not confuse with ‘Hacking’).

Sometimes a Hackfest is combined with a user conference – where developers and users can meet, listen to presentations and discuss functionality.

In 2017, the first Hackfest will take place at the Linuxhotel in Essen – Germany from Friday from 28th April – 1st May. This Hackfest is only going to be hard work for the developers – QGIS 3.0 is being developed and launched this year. More details and signing in for this weekend on the event wiki page.

The second Hackfest in 2017 will include a Summer Camp and take place in Nødebo at University of Copenhagen, Forest and Landscape College (Denmark) from Wednesday  2. August till  Friday 11. august

The Summer Camp will be a combination of work and leisure for the developers. And for users there will be workshops.

It is the first time we are having a Summer Camp at the Forest and Landscape College. We have both the place for work and the nature for exploring.

There are 28 rooms/56 beds, 3 large shelters and a large lawn where you can bring a tent sleeping bag and mattress.

Nearby the wonderful forest and lake.

The setup is as following:

Users pay for participating in workshops, food and accommodation (room/bed) – Shelter and tent are free.

Developers and workshop lecturers stays for free.

Call for workshops and sponsors: If you have a topic for a workshop or want to contribute as sponsor, please send me an e-mail at lfi@ign.ku.dk

Save the dates – and we will send out more information about the Summer Camp later this month.

Posted on behalf of Lene Fischer, QGIS Community Organizer


QGIS 3.0 logo voting results

It is our pleasure to announce that the QGIS.org voting members have unanimously agreed to the adoption of the proposed new logo.

qgis-logo_anita0

We are currently planning the roll out of the new logo to all our applications, web platforms, and social media accounts. In addition, we will create marketing material with the new QGIS branding.  Since this is a volunteer effort, we are planning to approach this step-by-step. The goal is to have everything ready by the time of the QGIS 3.0 release.

If you are interested in helping with this effort, please leave a comment here and we will get in touch!

 


QGIS Top Features 2016

A year ago I have asked QGIS’s community what were their favourite QGIS new features from 2015 and published this blog post. This year I decided to ask it again. In 2016, we add the release of the second long-term release (2.14 LTR), and two other stable versions (2.16 and 2.18).

2016 was again very productive year for the QGIS community, with lots of improvements and new features landing on QGIS source code, not to speak of all the work already in place for QGIS 3. This is a great assurance of the project’s vitality.

As a balance, I have asked users to choose wich were their favorite new features during 2016 (from the visual changelogs list). As a result, I got the following Top 5 features list.

5 – Paste a style to multiple selected layers or to all layers in a legend group (2.14)

This is a productivity functionaly that I just realized that existed now, with so many people voting on it. If copy/paste styles was, in my opinion, a killer feature, being able to use it in multiple layers or even a group is just great.

screenshot-from-2017-01-05-00-25-39

4 – fTools plugin has been replaced with Processing algorithms (2.16)

While checking the Vector Menu, the tools seem the same as previous version, but it’s when you open them that you understand the difference. All vector tools, provided until now by the fTools core plugin, were replaced by equivalent processing Algoritms. For the users it means easier access to more functionality, like running the tools in batch mode, or getting outputs as temporary layers. Besides some of the tools have been improved.

screenshot-from-2017-01-05-00-54-17

 

3 – Virtual layers (2.14)

This is definitly one of my favourite new features, and it seems I’m not alone. With virtual layers you can run SQL queries using the layers loaded in the project, even when the layers are not stored in a relational database. We are not talking about WHERE statments to filter data, with this you can do real SQL queries, with spatial analysis, aggregations, and so on. Besides, virtual layers will act as VIEWs and any changes to any of the input layers will automatically update the layer.

Screenshot from 2017-01-05 01-12-10.png

2 – Speed and memory improvements (2.14)

It’s no surprise that speed and memory improvements we one of the most voted features. Lots of improvements were made for loading and managing large datasets, and this have a tremendous impact in all users. According to the changelog, zoom is faster, selecting features is faster, updating attributes on selected features is faster, and it consumes less memory. So don’t be afraid to put QGIS to the test.

1 – Trace digitising tool (2.14)

If you do lots of digitising, you better look into this new feaure that landed on QGIS 2.14. It allows you to digitize new feature by using other layers boundaries. Besides the quality improvement of layers topology, this can make digitizing almost feel pleasing and fast! Just click the first point, move your mouse around other features edged to pick up more vertex.

screenshot-from-2017-01-05-01-42-33

 

There were other new features that also made the delight of many users. For example, several improvements on the labeling, Georeference outputs (eg PDF) from composer (2.16), Filter legend by expression (2.14), 2.5D Renderer. Personally, the Style docker made my day/year. But you can check the full results of the survey, if you like.

Obviously, this list means nothing at all. All new features were of tremendous value, and will be useful for thousands (yes thousands) of people. It was a mere exercise as, with such a diverse QGIS crowd, it would be impossible to build a list that would fit us all. Besides, there were many great enhancements, introduced during 2016, that might have fallen under the radar for most users. Check the visual changelogs for a full list of new features.

On my behalf, to all developers, sponsors, and general QGIS contributors, once again

THANK YOU VERY MUCH FOR YOUR TREMENDOUS WORK!

I wish you a fantastic 2017.


Happy new year 2017!

2016 was an exciting year for us. It was a year with three great releases (2.14 LTR, 2.16 & 2.18), lots of developer and community events (including our 2nd user conference in Girona, the developer meeting in Bonn before FOSS4G & a QGIS Server sprint in Lyon) and many firsts, including the first round of QGIS grants and our new QGIS.org organizational structure.

Group picture from Girona
Group picture from Girona

Many of these initiatives would not be possible without support by our community, dedicated developers and our sponsors, who enable us to keep up our infrastructure and improve software and documentation. We’re particularly proud to welcome three user groups among our top sponsors, with the Swiss user group as our most prominent Gold sponsor:

sponsors
QGIS gold and silver sponsors

Thank you for helping us improve the QGIS experience for everyone!

If you are following this blog, you are already aware that we have even bigger plans for 2017, including but not limited to the big QGIS 3.0 release and a completely overhauled QGIS logo.

We’re looking forward to another great year with the QGIS community.

Keep on QGISing!


QGIS Developer Sprint in Lyon

QGIS Developer Sprint in Lyon

 

QGIS Server 3.0 is going to be better than ever! Last week I attended to the mini code-sprint organized by the french QGIS developers in Lyon.

 

The code sprint was focused on QGIS Server refactoring to reach the following goals:

  • increase maintainability through modularity and clean code responsibilities
  • increase performances
  • better multi-project handling and caching
  • scalability
  • multi threaded rendering

By working for different companies on such a big Open Source project like QGIS, coordination between developers is fundamentally achieved through those kind of events.

We were a small group of engaged QGIS Server developers and I think that the alternance between brainstorming and coding has proven to be very productive: after two days we were able to set common milestones and commitments that will ensure a bright future to QGIS Server.

A huge and warm thank to the french QGIS developers that organized this meeting!

 

Photo: courtesy of Règis Haubourg

 

 

New style: flow map arrows

Last time, I wrote about the little details that make a good flow map. The data in that post was made up and simpler than your typical flow map. That’s why I wanted to redo it with real-world data. In this post, I’m using domestic migration data of Austria.

Raw migration data

Raw migration data, line width scaled to flow strength

With 9 states, that makes 72 potential flow arrows. Since that’s too much to map, I’ve decided in a first step to only show flows with more than 1,000 people.

Following the recommendations mentioned in the previous post, I first designed a basic flow map where each flow direction is rendered as a black arrow:

migration_basic

Basic flow map

Even with this very limited number of flows, the map gets pretty crowded, particularly around the north-eastern node, the Austrian capital Vienna.

To reduce the number of incoming and outgoing lines at each node, I therefore decided to change to colored one-sided arrows that share a common geometry:

migration_twocolor

Colored one-sided arrows

The arrow color is determined automatically based on the arrow direction using the following expression:

CASE WHEN
 "weight" < 1000 THEN color_rgba( 0,0,0,0)
WHEN
 x(start_point( $geometry)) - x(end_point($geometry)) < 0
THEN
 '#1f78b4'
ELSE
 '#ff7f00'
END

The same approach is used to control the side of the one-sided arrow head. The arrow symbol layer has two “arrow type” options for rendering the arrow head: on the inside of the curve or on the outside. This means that, if we wouldn’t use a data-defined approach, the arrow head would be on the same side – independent of the line geometry direction.

CASE WHEN
 x(start_point( $geometry)) - x(end_point($geometry)) < 0
THEN
 1
ELSE
 2
END

Obviously, this ignores the corner case of start and end points at the same x coordinate but, if necessary, this case can be added easily.

Of course the results are far from perfect and this approach still requires manual tweaking of the arrow geometries. Nonetheless, I think it’s very interesting to see how far we can push the limits of data-driven styling for flow maps.

Give it a try! You’ll find the symbol and accompanying sample data on the QGIS resource sharing plugin platform:

resourcesharing_flowmap


Mobile data collection with GeoPaparazzi and QGIS

Geopaparazzi 5.1.2 is a mobile app for Android which allows the user to quickly collect information on his or her surrounding area. This is done with the help of geometries, pictures and notes. Additionally to the notes which are available by default, a person skilled with .json forms may write their own forms for collecting data. In this blog I will cover:

  • How do I create custom notes?
  • How do I export my projects to QGIS?

This process is remarkably simple!

Create a new form type for Geopaparazzi:

As the first step we need to create our new Geopaparazzi form.

  • Create a new .json file
  • Build your form referring to this guide here
  • Each form consists of following sections:
  • A section
  • Various forms belonging to the section
  • Save your new form file when you are done.

You may wish to test your .json file with a JSONLint validator before proceeding.

Adding your form to the app.

Now that you have your form dialog written, we now need to add it to the Geopaparazzi app in order to use it.

  • Hook up your Android device to your computer
  • Navigate to your geopaparazzi folder (usually saved in your internal storage)
  • Find the tags.json file

tags_json_file

The tags.json file contains all of the forms which the app can use. Simply copy your code into the bottom of the tags.json file. Don’t forget to seperate the previous form section (in my case it was examples) from the new one with a ‘,’.

Now your Geopaparazzi app should feature your new custom form. You might have to restart the app for it to display.

added_custom_note

Moving your project to QGIS.

Once you have collected all the information you want, it is time to export your data to QGIS for further examination and use.

export_kmz_file

  • Export your project as a KMZ file
  • Hook up your Android device to your computer
  • Start a new QGIS Project
  • Select Layer/Add Layer/Add Vector Layer
  • When promted for a datasource select your freshly exported KMZ file (You may have to make sure that your browser is searching for all filetypes)
  • Make sure your projection matches EPSG:4326

import_kmz_file

Once this is done you should have a vector layer which displays all of the notes and bookmarks you made on the project. From here you can further style them (e.g. adding labels to your points).

import_completed_with_label

Geopaparazzi filetypes

Following filetypes are used by the Geopaparazzi app:

  • .gpap
  • .mbtiles
  • .sqlite

The Geopaparazzi project file (.gpap), is the main project file and contains all the important information which is recorded during your work. This is the file which is handled in the Export dialog and can be exported by Geopaparazzi into following formats:

  • .KMZ
  • .GPX
  • a STAGE compatible format
  • export all pictures taken as .png
  • export all bookmarks for another .gpap file

An important addendum would be that the .KMZ files which are generated during the export appear to actually be .KML files, as they are not compressed into binary.

The .mbtiles files are found in the geopaparazzi/defaulttiles directory and are seen as the background map in the Mapview.

The .sqlite files can be generated via the Import/Default Database menu. They contain three columns: polygon, points and lines. These columns then save the information of the geometry which the user creates in the Mapview.

For more information on the datasets from Geopaparazzi or how one goes about creating a GeoPaparazzi friendly spatialite database please refer to this documentation

Details of good flow maps

In my previous post, I shared a flow map style that was inspired by a hand drawn map. Today’s post is inspired by a recent academic paper recommended to me by Radoslaw Panczak  and Thomas Gratier :

Jenny, B., Stephen, D. M., Muehlenhaus, I., Marston, B. E., Sharma, R., Zhang, E., & Jenny, H. (2016). Design principles for origin-destination flow maps. Cartography and Geographic Information Science, 1-15.

Jenny et al. (2016)  performed a study on how to best design flow maps. The resulting design principles are:

  • number of flow overlaps should be minimized;
  • sharp bends and excessively asymmetric flows should be avoided;
  • acute intersection angles should be avoided;
  • flows must not pass under unconnected nodes;
  • flows should be radially arranged around nodes;
  • quantity is best represented by scaled flow width;
  • flow direction is best indicated with arrowheads;
  • arrowheads should be scaled with flow width, but arrowheads for thin flows should be enlarged; and
  • overlaps between arrowheads and flows should be avoided.

Many of these points concern the arrangement of flow lines but I want to talk about those design principles that can be implemented in a QGIS line style. I’ve summarized the three core ideas:

  1. use arrow heads and scale arrow width according to flow,
  2. enlarge arrow heads for thin flows, and
  3. use nodes to arrange flows and avoid overlaps of arrow heads and flows
Click to view slideshow.

To get started, we can use a standard QGIS arrow symbol layer. To represent the flow value (“weight”) according to the first design principle, all arrow parameters are data-defined:

scale_linear("weight",0,10,0.1,3)

To enlarge the arrow heads for thin flow lines, as required by the second design principle, we can add a fixed value to the data-defined head length and thickness:

scale_linear("weight",0,10,0.1,1.5)+1.5

arrow_head_thickness

The main issue with this flow map is that it gets messy as soon as multiple arrows end at the same location. The arrow heads are plotted on top of each other and at some point it is almost impossible to see which arrow starts where. This is where the third design principle comes into play!

To fix the overlap issue, we can add big round nodes at the flow start and end points. These node buffers are both used to render circles on the map, as well as to shorten the arrows by cutting off a short section at the beginning and end of the lines:

difference(
  difference(
    $geometry,
    buffer( start_point($geometry), 10000 )
  ),
  buffer( end_point( $geometry), 10000 )
)

Note that the buffer values in this expression only produce appropriate results for line datasets which use a CRS in meters and will have to be adjusted for other units.

arrow_nodes

It’s great to have some tried and evaluated design guidelines for our flow maps. As always: Know your cartography rules before you start breaking them!


New QGIS 3.0 logo candidate

If you have been following this blog and the QGIS community discussions, you will know that 2017 is going to be a big year in the history of QGIS since we are planning the release of QGIS 3.0. One of the requests we had during our Girona Hackfest held earlier this year was to come up with a fresher logo for QGIS. Some of you may remember that we had an abortive attempt at coming up with a new logo a couple of years ago. We found that process quite difficult to manage since we tried to do it in a completely open way and there were so many differing opinions, varying tastes and so on that the whole process reached an impasse and we decided to shelve the idea for time being. With that history in mind we decided to approach the logo updating process for QGIS 3.0 differently this time around  and use a professional designer to come up with a design and then provide the QGIS Voting Members with a simple, binary YES/NO choice as to whether they accept the new logo or not.

Our current logo is a revised, polished version of the original QGIS logo:

qgis_logo_v0-1
The first (left) and second (right) generations of the QGIS logo.

While we’ve all grown to love the yellow ‘Q’ with the green arrow (no comic pun intended), the design choices, such as glow effect and drop shadows look dated. Probably the biggest problem with the current logo is that there is also no consistent logo variant that spells out ‘QGIS’ without duplicating the Q. For the logo refresh we came up with a list of requirements for the new design:

  • It should look more modern than the current logo
  • Avoid any clichés with compass, north arrow and avoid image elements
  • The logo has to work as a :
    • Large and small application icon (on computer desktop, menus, …)
    • On big posters & banners
    • On stickers to place on laptops etc
    • On t-shirts and other promotional materials
    • On letterheads etc.
  • Should work well in monochrome (or have a monochrome variant)
  • Square and rectangular variants should be possible
  • If possible, keep element(s) from the current design. It is important for the new logo to try to retain some of these elements (Q, arrow, colors, …) so people can still recognize the QGIS brand.
  • There should be a variant that includes the whole word ‘QGIS’ or ‘QGIS.ORG’. Currently when we place the logo next to the word QGIS we get a redundant QQGIS or we need to carefully match fonts to make it work
  • As an application icon, it must work on light or dark backgrounds without modification
  • As a general logo, it should have accepted variants that work on light or dark backgrounds
  • Font has to be open source
  • We should also consider how the logo and accent colours can be used in different contexts, e.g. stationery, stickers, …

We went through many iterations, reducing the number of options on each iterations as we applied the above criteria to the candidates. We would like to now present our final candidate (monochrome icon, colour icon, full logo):

qgis-monochrome-black qgis-icon_anita0 qgis-logo_anita0

While retaining the traditional yellow and green, the addition of a new third colour is a nice play on version 3.0. In addition, the old arrow is now a more natural part of the Q and there is a version designed to spell out QGIS.

Soon we will be asking the QGIS Voting Members to vote in order to affirm or reject this new logo. If it is approved we will start the process of rebranding QGIS for version 3.0. If not we will go back to the drawing board and repeat the process until we come up with a logo the QGIS Voting Members are happy with …


New style: conveyor belt flows

The QGIS map style I want to share with you today was inspired by a hand-drawn map by Philippe Rekacewicz that I saw on Twitter:

The look reminds me of conveyor belts, thus the name choice.

You can download the symbol and a small sample dataset by adding my repo to the QGIS Resource Sharing plugin.

resourcesharing_conveyor

The conveyor belt is a line symbol that makes extensive use of Geometry generators. One generator for the circle at the flow line start and end point, respectively, another generator for the belt, and a final one for the small arrows around the colored circles. The color and size of the circle are data defined:

conveyor_details

The collection also contains a sample Geopackage dataset which you can use to test the symbol immediately. It is worth noting that the circle size has to be specified in layer CRS units.

It’s great fun playing with the power of Geometry generator symbol layers and QGIS geometry expressions. For example, this is the expression for the final geometry that is used to draw the small arrows around colored circles:

line_merge( 
  intersection(
    exterior_ring( 
      convex_hull( 
        union( 
          buffer( start_point($geometry), "start_size" ),
          buffer( end_point($geometry), 500000 )
        )
      )
    ),
    exterior_ring( 
      buffer( start_point( $geometry), "start_size" )
    )
  )
)

The expression constructs buffer circles, the belt geometry (convex_hull around buffers), and finally extracts the intersecting part from the start circle and the belt geometry.

Hope you enjoy it!

It’s holiday season, why not share one of your own symbols with the QGIS community?


Color Ramp Improvements in Upcoming QGIS 3.0

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! 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.

QGIS 2.18 packaged for Fedora 23 and 24

qgis-icon_smallThanks to the work of Volker Fröhlich and other Fedora packagers I was able to create RPM packages of QGIS 2.18 Las Palmas for Fedora 23 and 24 using Fedora’s COPR platform.

Repo: https://copr.fedorainfracloud.org/coprs/neteler/QGIS-2.18-Las-Palmas

The following packages can now be installed:

  • qgis 2.18.0
  • qgis-debuginfo 2.18.0
  • qgis-devel 2.18.0
  • qgis-grass 2.18.0
  • qgis-python 2.18.0
  • qgis-server 2.18.0

Installation instructions (run as “root” user or use “sudo”):

su

# Fedora 23, Fedora 24:
dnf copr enable neteler/QGIS-2.18-Las-Palmas
dnf update
# note: the "qca-ossl" package is the OpenSSL plugin for QCA
dnf install qgis qgis-grass qgis-python qca-ossl

Enjoy!

The post QGIS 2.18 packaged for Fedora 23 and 24 appeared first on GFOSS Blog | GRASS GIS Courses.

GDAL 2.1 packaged for Fedora 23 and 24

GDAL logoThe new GDAL 2.1 is now also packaged for Fedora 23 and 24 which is possible due to the tireless efforts of various Fedora packagers.

Repo: https://copr.fedorainfracloud.org/coprs/neteler/GDAL/

Installation Instructions:

su

# Fedora 23+24:
# install this extra repo
dnf copr enable neteler/GDAL

# A) in case of update, simply
dnf update

# B) in case of new installation (gdal-devel is optional)
dnf install gdal gdal-python gdal-devel

The post GDAL 2.1 packaged for Fedora 23 and 24 appeared first on GFOSS Blog | GRASS GIS Courses.

QGIS 3.0 + Qt5: Major Improvements in Text Shaping for Complex Languages

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: Oh-ho

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: Haa

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.

The Little Things That Matter: Localizing Numerals in Upcoming QGIS 3.0

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:

I can see!

Style Management Improvements in Upcoming QGIS 3.0

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: style management: what's new

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

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.

QGIS 3.0 + Qt5: Major Improvements in Text Shaping for Complex Languages

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: Oh-ho

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: Haa

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.

The Little Things That Matter: Localizing Numerals in Upcoming QGIS 3.0

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:

I can see!

  • Page 1 of 89 ( 1774 posts )
  • >>

Back to Top

Sponsors