Page 2 of 90 (1789 posts)

  • talks about »

Tags

Last update:
Thu Apr 27 23:10:27 2017

A Django site.

QGIS Planet

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!

PS: To draw a curved arrow, the line needs to have one intermediate point between start and end – so three points in total. Depending on the intermediate point’s position, the line is more or less curved.


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

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!

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.

Movement data in GIS #4: variations over time

In the previous post, I presented an approach to generalize big trajectory datasets by extracting flows between cells of a data-driven irregular grid. This generalization provides a much better overview of the flow and directionality than a simple plot of the original raw trajectory data can. The paper introducing this method also contains more advanced visualizations that show cell statistics, such as the overall count of trajectories or the generalization quality. Another bit of information that is often of interest when exploring movement data, is the time of the movement. For example, at LBS2016 last week, M. Jahnke presented an application that allows users to explore the number of taxi pickups and dropoffs at certain locations:

By adopting this approach for the generalized flow maps, we can, for example, explore which parts of the research area are busy at which time of the day. Here I have divided the day into four quarters: night from 0 to 6 (light blue), morning from 6 to 12 (orange), afternoon from 12 to 18 (red), and evening from 18 to 24 (dark blue).

 (data credits: GeoLife project,

Aggregated trajectories with time-of-day markers at flow network nodes (data credits: GeoLife project, map tiles: Carto, map data: OSM)

The resulting visualization shows that overall, there is less movement during the night hours from midnight to 6 in the morning (light blue quarter). Sounds reasonable!

One implementation detail worth considering is which timestamp should be used for counting the number of movements. Should it be the time of the first trajectory point entering a cell, or the time when the trajectory leaves the cell, or some average value? In the current implementation, I have opted for the entry time. This means that if the tracked person spends a long time within a cell (e.g. at the work location) the trip home only adds to the evening trip count of the neighboring cell along the trajectory.

Since the time information stored in a PostGIS LinestringM feature’s m-value does not contain any time zone information, we also have to pay attention to handle any necessary offsets. For example, the GeoLife documentation states that all timestamps are provided in GMT while Beijing is in the GMT+8 time zone. This offset has to be accounted for in the analysis script, otherwise the counts per time of day will be all over the place.

Using the same approach, we could also investigate other variations, e.g. over different days of the week, seasonal variations, or the development over multiple years.


Let’s make a big funding push for QGIS 3.0!

In 2017 we are planning to release QGIS 3.0. This new major version will become the basis of the next LTR release (QGIS 3.2) and is set to be a sea-change in the development of QGIS. It will modernize the architecture to get rid of many legacy issues that we were unable to resolve in the minor release series of 2.x releases. For example we are switching to Qt5, Python3 stripping out deprecated API’s, cleaning away many old code artifacts, and making a huge range of under the hood tweaks to improve the performance and stability of QGIS. Here are some of the other key issues that need to be worked on before we can release QGIS 3.0:

  • QGIS Server needs to be updated to work with QGIS 3.0
  • QGIS Composer needs an overhaul

There are many more ‘under the hood’ items like this that we would like sort out before we can release QGIS 3.0.

Recently we announced the winners for our new grant programme which directly funds developers wishing to make improvements to the QGIS project. We would like to amp things up a notch further and thus with this blog post we would like to make this appeal:

  • If you are an individual user please consider making a donation to the project (donations can be made by PayPal or by direct bank transfer).
  • If you work for a company, please consider becoming a project sponsor. Our entry level sponsorship is not a lot of money and will make a great contribution to the project. We are still looking for our first platinum sponsor – perhaps your company could be the first! Here is the list of sponsorship levels for quick reference:
Euros Sponsorship level
27,000+ Platinum Sponsor
9,000+ Gold Sponsor
3,000+ Silver Sponsor
500+ Bronze Sponsor
  • If you are a company that makes use of contract QGIS developers, include in your contracts a provision for the developer to get your new features into the 3.0 code base with a nice set of tests so that the burden does not get passed upstream to volunteer developers to port your features to QGIS 3.0.
  • If you are a company that has in-house QGIS developers, consider allocating some of their time to supporting the QGIS 3.0 development effort.
  • If you are a country user group, please try to hold a funding drive within your user group and pass the funds either to the upstream QGIS.ORG project or support developers who are in your country to do bug fixing and implementation work for QGIS 3.0.

If you have other ideas about how to support the effort we will be glad to hear them! We will put as much money from QGIS.ORG funds as possible into developers that are willing and able to work on the preparation of QGIS 3.0.

A huge thank you to all of those that have already contributed time and money into the effort to get QGIS 3.0 ready for release!


QGIS UK Edinburgh: an overview

6th Scottish QGIS UK user group meeting
Informatics Forum, University of Edinburgh, Edinburgh
3rd November 2016

A full house with all tickets sold. Our biggest event yet. A last minute decision to video the talks. A first ever raffle to raise funds for the QGIS project. More than half the attendees were at a QGIS user group for the first time. All sectors represented and a range of talks from accessible introductions to QGIS functionality to wonderful technical geekery to varied FOSS4G use cases.

Slides

Video: https://youtu.be/kHDZmmzKU4U

How deep is your loch?
Phil Taylor (@scienceandmaps) from CEH opened up the day with a detailed explanation of how he lovingly captured the plumbed depths of four Scottish lochs and turned them into interactive 3D visualisations. You can see his results at http://contours.org.uk/bathymetry

Slides

Video: https://youtu.be/-q021mocJdI

QGIS Server: the good, not-so-good and the ugly
Fiona Hemsley-Flint showed us the exploratory work she and her team have done with QGIS Server as a possible replacement for MapServer and Cadcorp GeognoSIS. QGIS server is capable and can render complex styles and labels well but was generally 5 to 10 times slower than GeognoSIS in rendering the maps.

Slides

Video: https://youtu.be/TPoOOkurtlA

Installing QGIS on a Network
Tom Armitage (@MapNav_Tom) from the University of Edinburgh gave a quick run through of the requirements for installing QGIS 2.14.3 across 3000 computers.

Slides

Video: https://youtu.be/fv3fgI-u084

Mapping narrative: QGIS in the Digital Humanities 
Anouk Lang (@e_a_lang) from the University of Edinburgh explained how mapping and visualisation were used to engage students and explore literature in a different way.

Slides

Video: https://youtu.be/XlADXIrC9PE

QGIS Plug-in for Parallel Processing in Terrain Analysis
Art Lembo (@artlembo) from Salisbury University, Maryland, USA got everyone excited about advances in personal computing power and how graphics cards can be harnessed to speed up spatial processing. The trouble with geographic data is that it is usually a large chunk of data with relatively little processing required. Parallel processing likes small chunks of data that need huge amounts of processing. The plugin hits the limit of the ability of Python to pass through more data. That’s how fast the graphics cards are.

Slides

Video: https://youtu.be/mkDMFiVLdkg

Viewshed analysis and how to find the heart of Scotland
Neil Benny (@bennymapper) from thinkWhere gave a very useful overview of how to use the different tools in QGIS to generate viewsheds which a lot people at the event could see a use for in their workflows. See https://blog.thinkwhere.com/2016/08/25/viewsheds-and-visibility-analysis-in-qgis/ for more information.

Slides

Video: https://youtu.be/LOPuw2-oaPA

qgis2web: geocrustin’
Tom Chadwin (@tomchadwin) from NNPA gave an entertaining talk on how and why he developed the qgis2web plugin. He showed us how to use it and you can see why it is such a popular extension to QGIS.

Video: https://youtu.be/4gyW1aeoTvU

QGIS 3.0, WMTS previews and XYZ support in QGIS 2.18
Pete Wells (@lutraconsulting) from Lutra Consulting gave a more technical talk on some behind the scenes work that they have been doing to make using QGIS 3.0 even better for the user. No more waiting for the base map to load as the WMS server thinks about the request – tiled services quickly and seamlessly fill the screen. For more information see http://www.lutraconsulting.co.uk/blog/2016/10/26/qgis-xyz-tile-wmts-preview/

Video: https://youtu.be/Q83W0XJ2Y3g

Decision Support Systems in Forestry
Stephen Bathgate (@Forestry_Research) from the Forestry Commission gave a real world example of how a GIS, and then an open source GIS infrastructure, delivered improved workflows, better efficiencies and made a smaller workforce more effective.

Slides

Video: https://youtu.be/94_y1qbqk-w

Collecting spatial survey data with Leaflet and OpenStreetMap
Louise Sing (@sing_louise) from Forestry Commission gave a lightning talk on how she used tips learned at previous QGIS user group meetings to put together a simple Leaflet map to collection information about how people use different areas of forest.
Slides

Video: https://youtu.be/-SCvsqy6txU

Indoor 3D routing with QGIS and pgRouting
Tim Manners (@tmnnrs) from Ordnance Survey demonstrated the interactive 3D route solving application created using QGIS and the QGIS2threeJS plugin. It can be used to route between locations spread across multiple floors in a building. It can take into account width and height restrictions such as doorways and lifts and can be used to model mass evacuations of a workforce.

Slides

Video: https://youtu.be/H-v9SXwc3BQ

Using QGIS for wildlife surveys and reporting
Andrew Whitelee (@VerdantWildlife) from Taylor Wildlife lead an interactive talk highlighting the difficulty of undertaking robust repeatable wildlife surveys in the great outdoors. He showed how the use of high quality mapping and GPS tracking improved the quality of the surveys and how much sense the use of open source software made for small enterprises.

Slides

Video: https://www.youtube.com/watch?v=pJhXdYqEmuQ

Them Thar Hills: shadin’, texturin’, blendin’
Ross McDonald (@mixedbredie) from Angus Council gave a lightning talk on different ways to generate hillshaded images from elevation models. Regular hillshaded images can be enhanced by generating texture shaded images. Texture shading enhances the drainage network and the visual hierarchy of the landscape. Blender can be used to create rich shaded relief by modelling real sunlight and reflection across the landscape. See textureshading.com for more information or press F7 in a recent version of QGIS to open the live style dock.

Slides

Video: https://www.youtube.com/watch?v=0nkNgtKGbw4

DOHA: Doha Online Historical Atlas
Michal Michalski from Scottish Government and the DOHA project showcased the mapping work he has been helping with in Doha and the archaeological investigation into the origins of the city. The website is a fantastic example of the integration of different resources including historic maps, photographs, videos and historic records. See http://originsofdoha.org/doha/index.html for more information.

Video: https://www.youtube.com/watch?v=xYegqHRoAic

3D indoor maps with QGIS
Tim Jenks (@eeGeo) from eeGeo gave a short talk on how QGIS and other tools were used to build navigable 3D maps of cities and buildings. See https://www.youtube.com/watch?v=c6T_v_e5Re8 for a demo.

Slides

Tom Armitage closed with some remarks on how open source software works and how the QGIS community supports the QGIS project. Roger Garbett managed the raffle (all 500 tickets sold!) with some great prizes (Splash-Maps voucher, QGIS t-shirt voucher, OS colouring map book, Art Lembo’s text book on geospatial processing, stickers and others) the proceeds of which will go to the QGIS project. There is, after all, no such thing as a free lunch. Even if fantastic and generous sponsors – Ordnance Survey, thinkWhere, Angus Council, Cawdor Forestry, eeGeo and EDINA – give us a lovely selection of food and drink (thanks BlueSkyCatering) and a top-class venue for a brilliant day out.

Slides

Video: https://youtu.be/cVEPbogf0To

The day ended in the Potting Shed with (strong) cask ales and ciders refreshing parched throats. Always a great way to wrap things up.

qgisug_sponsors_white


QGIS 2.18 ‘Las Palmas’ is released!

We are pleased to announce the release of QGIS 2.18 ‘Las Palmas’. The city of Las Palmas de Gran Canaria was the location of our autumn 2015 developer meeting.

This is the last release in the 2.x series. The current Long Term Release (LTR) remains version 2.14.x. This release provides incremental improvements over our previous release. The majority of activity is currently focused towards the development of QGIS 3.0 which is our next generation release planned for the end of the first quarter of 2017.

We would like to thank the developers, documenters, testers and all the many folks out there who volunteer their time and effort (or fund people to do so). From the QGIS community we hope you enjoy this release! If you wish to donate time, money or otherwise get involved in making QGIS more awesome, please wander along to qgis.org and lend a hand!

QGIS is supported by donors and sponsors. A current list of donors who have made financial contributions large and small to the project can be seen on our donors list. If you would like to become and official project sponsor, please visit our sponsorship page for details. Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts. A complete list of current sponsors is provided below – our very great thank you to all of our sponsors!

QGIS is Free software and you are under no obligation to pay anything to use it – in fact we want to encourage people far and wide to use it regardless of what your financial or social status is – we believe empowering people with spatial decision making tools will result in a better society for all of humanity.


  • <<
  • Page 2 of 90 ( 1789 posts )
  • >>

Back to Top

Sponsors