Sometimes I prefer to publish my map in gray instead of black. But all newly added QGIS composer items are set to black by default. For changing the colors more easily and rapidly I created the “Turn Gray” plugin. By default it changes all foreground colors (labels and outlines) to gray. But you are free … Continue reading Gray is the new Black
In zwei Wochen beginnt die alljährliche deutschsprachige FOSSGIS Konferenz zum Theme Open Source GIS und OpenStreetMap in Passau. Vom 22.-25. März 2017 wird die FOSSGIS-Konferenz mit Untersützung der Universität Passau in der Dreiflüssestadt Passau stattfinden. Die FOSSGIS-Konferenz ist die im D-A-CH-Raum führende Konferenz für Freie und Open Source Software für Geoinformationssysteme sowie für die Themen OpenStreetMap und Open Data. An vier Tagen werden in Vorträgen für Einsteiger und Experten, Hands-On Workshops und Anwendertreffen Einblicke in neuste Entwicklungen und Anwendungsmöglichkeiten von Softwareprojekten gegeben.
Sourcepole ist wieder mit einem Stand vertreten und lädt zu interessanten Workshops und Vorträgen ein:
- Mittwoch 17:00 - Workshop Entwicklung von QGIS Plugins
- Donnerstag 14:30 (HS 9) - QGIS Server Projektstatus
- Donnerstag 14:30 (HS 11) - Von WMS zu WMTS zu Vektor-Tiles
- Donnerstag 15:00 (HS 9) - QGIS Web Client 2
Wir freuen uns auf eine interessante Konferenz!
In the 1st part of this series, I mentioned the Workshop on Analysis of Movement Data at the GIScience 2016 conference. Since the workshop took place in September 2016, 11 abstracts have been published (the website seems to be down currently, see the cached version) covering topics from general concepts for movement data analysis, to transport, health, and ecology specific articles. Here’s a quick overview of what researchers are currently working on:
- General topics
- Interpolating trajectories with gaps in the GPS signal while taking into account the context of the gap [Hwang et al., 2016]
- Adding time and weather context to understand their impact on origin-destination flows [Sila-Nowicka and Fotheringham, 2016]
- Finding optimal locations for multiple moving objects to meet and still arrive at their destination in time [Gao and Zeng, 2016]
- Modeling checkpoint-based movement data as sequence of transitions [Tao, 2016]
- Transport domain
- Estimating junction locations and traffic regulations using extended floating car data [Kuntzsch et al., 2016]
- Health domain
- Clarifying physical activity domain semantics using ontology design patterns [Sinha and Howe, 2016]
- Recognizing activities based on Pebble Watch sensors and context for eight gestures, including brushing one’s teeth and combing one’s hair [Cherian et al., 2016]
- Comparing GPS-based indicators of spatial activity with reported data [Fillekes et al., 2016]
- Ecology domain
- Linking bird movement with environmental context [Bohrer et al., 2016]
- Quantifying interaction probabilities for moving and stationary objects using probabilistic space-time prisms [Loraamm et al., 2016]
- Generating probability density surfaces using time-geographic density estimation [Downs and Hyzer, 2016]
If you are interested in movement data in the context of ecological research, don’t miss the workshop on spatio-temporal analysis, modelling and data visualisation for movement ecology at the Lorentz Center in Leiden in the Netherlands. There’s currently a call for applications for young researchers who want to attend this workshop.
Since I’m mostly working with human and vehicle movement data in outdoor settings, it is interesting to see the bigger picture of movement data analysis in GIScience. It is worth noting that the published texts are only abstracts, therefore there is not much detail about algorithms and whether the code will be available as open source.
For more reading: full papers of the previous workshop in 2014 have been published in the Int. Journal of Geographical Information Science, vol 30(5). More special issues on “Computational Movement Analysis” and “Representation and Analytical Models for Location-based Social Media Data and Tracking Data” have been announced.
[Bohrer et al., 2016] Bohrer, G., Davidson, S. C., Mcclain, K. M., Friedemann, G., Weinzierl, R., and Wikelski, M. (2016). Contextual Movement Data of Bird Flight – Direct Observations and Annotation from Remote Sensing.
[Cherian et al., 2016] Cherian, J., Goldberg, D., and Hammond, T. (2016). Sensing Day-to-Day Activities through Wearable Sensors and AI.
[Downs and Hyzer, 2016] Downs, J. A. and Hyzer, G. (2016). Spatial Uncertainty in Animal Tracking Data: Are We Throwing Away Useful Information?
[Fillekes et al., 2016] Fillekes, M., Bereuter, P. S., and Weibel, R. (2016). Comparing GPS-based Indicators of Spatial Activity to the Life-Space Questionnaire (LSQ) in Research on Health and Aging.
[Gao and Zeng, 2016] Gao, S. and Zeng, Y. (2016). Where to Meet: A Context-Based Geoprocessing Framework to Find Optimal Spatiotemporal Interaction Corridor for Multiple Moving Objects.
[Hwang et al., 2016] Hwang, S., Yalla, S., and Crews, R. (2016). Conditional resampling for segmenting GPS trajectory towards exposure assessment.
[Kuntzsch et al., 2016] Kuntzsch, C., Zourlidou, S., and Feuerhake, U. (2016). Learning the Trafﬁc Regulation Context of Intersections from Speed Proﬁle Data.
[Loraamm et al., 2016] Loraamm, R. W., Downs, J. A., and Lamb, D. (2016). A Time-Geographic Approach to Wildlife-Road Interactions.
[Sila-Nowicka and Fotheringham, 2016] Sila-Nowicka, K. and Fotheringham, A. (2016). A route map to calibrate spatial interaction models from GPS movement data.
[Sinha and Howe, 2016] Sinha, G. and Howe, C. (2016). An Ontology Design Pattern for Semantic Modelling of Children’s Physical Activities in School Playgrounds.
[Tao, 2016] Tao, Y. (2016). Data Modeling for Checkpoint-based Movement Data.
Greetings wonderful QGIS Users, Developers and Supporters! 2016 was quite an exciting year for QGIS – we released QGIS 2.14LTR which has been a great stable release. We also set the wheels in motion for QGIS 3.0 which we plan to release later this year. QGIS development takes a lot of time and effort – and much of the work is done by volunteers – especially the core project maintenance work which typically does not attract paid-for consulting work like new feature work does.
We are extremely lucky and grateful to have a growing band of sponsors that are helping us to slowly but surely fund more core QGIS project work too. In this post we want to say ‘thank you’ to the many sponsors that have stepped up to the plate when we asked for help and sponsored QGIS. We also want to provide some insight as to what level of funding we receive and hopefully stimulate some friendly enthusiasm to stepping up funding efforts from our users around the world.
Our project treasurer, Andreas Neumann, has been so kind as to compile a very detailed report about the sponsorships and donations received over 2016 which we would like to share with you. Before I share his actual report, let me just clarify that we have two distinct ways of contributing money to the project:
- Donations: You simply nominate an amount you wish to contribute and pay it to the project. Donations are intended as a way for individual users to show their support for QGIS (although we welcome large donations too).
- Sponsorships: Sponsorships are aimed at organizations. We have fixed tiers of contribution (see below) and each tier includes some benefits in terms of marketing exposure for your company or organisation.
QGIS sponsorship can be made at one of four levels:
Higher tier (silver and up) sponsors are included in the footer of our main web site, http://qgis.org e.g.:
If you want to see your company listed there, why not head over to the QGIS Sponsorship page to find out how to become a sponsor?
Some interesting highlights from Andreas’ report:
We had 1128 donations in 2016 amounting to a total of €25108. We had 47 Sponsors in 2016 which raised a total income of €67921. December is the month that attracts the highest income from donations and sponsors (though that may coincide with additional marketing we did calling for sponsors). Looking at contributions by country, Denmark was the highest national contributor in 2016, providing a total of €17795 to the QGIS.ORG project. If you normalize by population, Iceland provided the largest per capita contribution to QGIS, providing €9056 per million people. Iceland also had the highest contribution rate when measured against GDP with ~€154 per billion GDP.
You can read Andreas’ full report in this PDF – a huge thank you to Andreas for preparing this fascinating report, and of course to everyone out there who shared their hard earned money with us – your funding has become a vital enabler for moving the project forward.
(QGIS Project Chair)
It’s been a long time since I last blogged here. Let’s just blame that on the amount of changes going into QGIS 3.0 and move on…
One new feature which landed in QGIS 3.0 today is a processing algorithm for automatic coloring of a map in such a way that adjoining polygons are all assigned different color indexes. Astute readers may be aware that this was possible in earlier versions of QGIS through the use of either the (QGIS 1.x only!) Topocolor plugin, or the Coloring a map plugin (2.x).
What’s interesting about this new processing algorithm is that it introduces several refinements for cartographically optimising the coloring. The earlier plugins both operated by pure “graph” coloring techniques. What this means is that first a graph consisting of each set of adjoining features is generated. Then, based purely on this abstract graph, the coloring algorithms are applied to optimise the solution so that connected graph nodes are assigned different colors, whilst keeping the total number of colors required minimised.
The new QGIS algorithm works in a different way. Whilst the first step is still calculating the graph of adjoining features (now super-fast due to use of spatial indexes and prepared geometry intersection tests!), the colors for the graph are assigned while considering the spatial arrangement of all features. It’s gone from a purely abstract mathematical solution to a context-sensitive cartographic solution.
Let’s explore the differences. First up, the algorithm has an option for the “minimum distance between features”. It’s often the case that features aren’t really touching, but are instead just very close to each other. Even though they aren’t touching, we still don’t want these features to be assigned the same color. This option allows you to control the minimum distance which two features can be to each other before they can be assigned the same color.
The biggest change comes in the “balancing” techniques available in the new algorithm. By default, the algorithm now tries to assign colors in such a way that the total number of features assigned each color is equalised. This avoids having a color which is only assigned to a couple of features in a large dataset, resulting in an odd looking map coloration.
Another available balancing technique is to balance the color assignment by total area. This technique assigns colors so that the total area of the features assigned to each color is balanced. This mode can be useful to help avoid large features resulting in one of the colors appearing more dominant on a colored map.
The final technique, and my personal preference, is to balance colors by distance between colors. This mode will assign colors in order to maximize the distance between features of the same color. Maximising the distance helps to create a more uniform distribution of colors across a map, and avoids certain colors clustering in a particular area of the map. It’s my preference as it creates a really nice balanced map – at a glance the colors look “randomly” assigned with no discernible pattern to the arrangement.
As these examples show, considering the geographic arrangement of features while coloring allows us to optimise the assigned colors for cartographic output.
The other nice thing about having this feature implemented as a processing algorithm is that unlike standalone plugins, processing algorithms can be incorporated as just one step of a larger model (and also reused by other plugins!).
QGIS 3.0 has tons of great new features, speed boosts and stability bumps. This is just a tiny taste of the handy new features which will be available when 3.0 is released!
Dear QGIS Community
Last year we held our first ever call for Grant Proposals and it was a great success. If you are an early adopter using QGIS 3.0 preview builds, you can already try out some of the new capabilities that have arrived in QGIS thanks to these grants.
We are very pleased to announce the second round of Grants is now available to QGIS Contributors. The deadline for this round is Sunday, 19 March 2017. All the details for the Grant are described in the application form, and for more context we encourage you to also read these articles:
- QGIS Grants #1: Call for applications
- Update on the QGIS Grant Programme
- Winning QGIS Grant Proposals for 2016
We look forward to seeing all your great ideas about how to improve QGIS!
QGIS Project Chair
The AutoForm plugin for QGIS automatically sets the edit widget type for the fields of a selected layer based on their data types and foreign keys. This is in order to save the user time they may need to spend on manually editing these widgets. In order for this to work correctly, the layer information must be stored in a PostgreSQL database. Furthermore, foreign keys must have a constraint rule for this to work. The plugin does NOT allow you to set relations. It merely checks for any and takes advantage of them accordingly.
When you have a database with a lot of tables, there should be a way for quickly entering data whithout having to configure the input form for each table first. In Switzerland this a common use case when you import Interlis data with ili2pg based on an official data model.
ili2pg automatically adds reference constraints based on the Interlis model, which is a prerequisite to detect relations in a generic way.
There is already a plugin with a very similar goal: DataDrivenInputMask written by Bernhard Ströbl. Maybe it was bad luck, but we had always troubles when using it. Once we eventually found out the PostgreSQL driver for the
library was missing and another time we failed to use the plugin because we had a socket based connection to PostgreSQL. In both cases we were stuck in the login dialog without a hint why the connection had failed. Another problem is in some cases that the DataDrivenInputMask plugin writes additional metadata into the original database.
So we decided to make our own proof of concept, hopefully avoiding these problems and having the Swiss “ili2pg” use case in mind. A major conceptual difference is, that AutoForm uses the built-in input form functionality of QGIS instead of creating custom dialogs like DataDrivenInputMask does.
Running the plugin
After you have installed the AutoForm plugin (flagged “experimental”) via the QGIS Plugin repository you should see a new option in the
Plugins menu called
AutoForm. Clicking on it will give you the option
Generate Form. Running this with the layer selected will generate your form. If everything is correctly configured, this next step should be easy.
- Select a PostGIS layer from the Layers Panel
- Click on
And thats it! Now if you toggle editing you should see the changes which were made. In my case, this was the result:
If your layer had a foreign key reference to one or multiple other tables, then they too were added automatically to the Layers Panel and their values should be selectable in their according fields.
Behind the Scenes
In order to perhaps help a bit with understanding how this Plugin works, I am adding this section for anyone who is curious. The Plugin follows this process:
- Check if a layer is selected
- If a layer is selected search for any key relationships to other tables
- If a foreign key relationship to another table was found the load that table into the project and set the corresponding fields to a Value Relation WidgetType
- Proceed normally and set the remaining Widgets where applicable
The script checks first if the field has already been changed, so as to prevent user made edits or the previously set Value Relations from being overwritten. Then it takes a look at the typeName() of the field in order to determine which widgettype to assign. For example if the field has the Date Type, it would use the calender widget. It does this for each field in the layer. Should the user wish to make additional changes (or correct any mistakes which might have been made), they can do so in the ‘Fields’ tab of the layer properties.
This plugin is in an early stage and serves as a proof of concept. There is much left to be done, especially in supporting embedded forms for related tables. We also don’t analyze additional metadata written by
ili2pg, which would allow to recognize whether related tables are only lookup tables without the need to embed them as entry forms.
The source code is available on Github. If you are interested in collaborating or maybe sponsoring improvements to this plugin, please contact us!
Dear QGIS community members
At the end of December 2016, we held our inaugural Annual General Meeting (AGM). It should be noted that QGIS AGM’s will be ‘virtual’ meetings conducted as a questionnaire (for voting / raising motions) and then a report such as the one below, with optional follow up email discussion if deemed necessary. The reason for this is that our community is spread far and wide and any attempt at an in-person (physical or virtual) meeting will prove very difficult given the number of different time zones the participants live in. Thus this, and future, AGM reports will be a reflection / summary of the various online activities that constitute the ‘AGM’ and the reports should be read with this understanding in mind. It should also be kept in mind that because we are bootstrapping the QGIS Board, the 2016/ 2017 meetings follow a reduced agenda – the 2018 meeting will commence with the full AGM agenda since we will have a year of financial reporting / board activity etc. behind us. Here follow the minutes:
Minutes of the Inaugural General Assembly (AGM) 2016 – Concluded 22 December 2016
Dear QGIS.ORG voting members,
In December 2016 we held a special Inaugural AGM event in order to bootstrap the new governance structures for QGIS.ORG. The following items were tabled during our special AGM to cater for the needed transition from the old organisation to the new:
Election of incoming board and PSC member replacements
Under our statutes, existing board / PSC members are automatically put forward for re-election during our PSC elections. A call for nominations was held and closed on 15 December 2016. All voting members were elegible to put forward their nominations. The following valid nominations were received (i.e. for candidates who were not already PSC members):
- Régis Haubourg
Subsequent to the call for nominations, an election was held via online vote. Response rate was 20 out of 27 eligible voters. Under our statutes this is considered a quorum. Election results were as follows:
|Position||Name||Votes Received||Max Votes|
|Chair: QGIS Board||Tim Sutton||19||20|
|Vice-Chair: QGIS Board||Paolo Cavallini||12||20|
|Treasurer: QGIS Board||Andreas Neumann||20||20|
|PSC Member||Richard Duivenvoorde||17||20|
|PSC Member||Anita Graser||16||20|
|PSC Member||Jϋrgen Fischer||14||20|
|Honorary PSC Member||Gary Sherman||–||–|
Note that each voting member was allowed 6 votes, but was not allowed to vote for the same person more than once. For the Board Member positions, which were specifically named, the candidate with the greatest number of votes for each role assigned that role. The PSC member positions were calculated based on the total number of votes each candidate received (including those allocated to named board roles). In accordance with our statutes, Gary Sherman remains on the PSC on a permanent basis as Honorary PSC member.
Election of the board chair
Election of the board chair was carried out as part of the general voting process. The successful candidate was Tim Sutton.
Matters brought forward by voting members
There were no matters brought forward by voting members.
Annual AGM for 2017
Now that the special AGM has been held and the Board and PSC constituted, we will hold our first AGM in the first quarter of 2017 (and then each year thereafter will be held in the first quarter). The 2017 AGM will be a reduced format since we will have just elected the PSC and Board,
Agenda for 2017 AGM:
- Approval of the annual report (2016) by the chair
- Approval of the annual financial report (2016)
- Approval of the 2017 budget
- Election of two financial auditors for the upcoming year
- Deal with matters brought forward by voting members
Given the outcomes of the end-2016 AGM, the QGIS Governance now looks like this (click for larger version):
If you have any queries about the QGIS Governance processes, please do not hesitate to ask!
Tim Sutton (QGIS Project Chair)
Today’s post was motivated by a question following up on my recent post “Details of good flow maps“: How to create arrows with gradients from transparent to opaque?
The key idea is to use a gradient fill to color the arrows:
It all seems perfectly straightforward: determine the direction of the line and set the gradient rotation according to the line direction.
But wait! That doesn’t work!
The issue is that all default angle functions available in expressions return clockwise angles but the gradient rotation has to be set in counter-clockwise angles. So we need this expression:
Sorry, this entry is only available in the Dutch language
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.
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:
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:
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:
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:
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:
Finally, we set title, legend, explanatory texts, and background color:
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.
We are pleased to announce the stable release of GRASS GIS 7.2.0
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.
- winGRASS 7.2.0: 32bit standalone installer | 64bit standalone installer
- winGRASS 7.2.0 OSGeo4W – testing area: 32bit OSGeo4W installer | 64bit OSGeo4W installer
- Debian Linux installer
- Fedora Linux installer
- openSUSE Linux
- Ubuntu Linux
- … further binary packages for other Linux distributions and Mac OSX will follow shortly.
Source code download:
- To get the GRASS GIS 7.2.0 source code directly from SVN, see here.
See also our detailed announcement:
- https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures72 (overview of new 7.2 stable release series)
- https://grass.osgeo.org/grass72/manuals/addons/ (list of available addons)
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
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 firstname.lastname@example.org
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
It is our pleasure to announce that the QGIS.org voting members have unanimously agreed to the adoption of the proposed new logo.
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!
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.
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.
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.
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.
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.
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.
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.
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:
Thank you for helping us improve the QGIS experience for everyone!
We’re looking forward to another great year with the QGIS community.
Keep on QGISing!
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
- 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!
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.
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:
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:
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:
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
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.
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 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
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).
Following filetypes are used by the Geopaparazzi app:
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:
- 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
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 @RPanczak and Thomas Gratier @ThomasG77:
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:
- use arrow heads and scale arrow width according to flow,
- enlarge arrow heads for thin flows, and
- use nodes to arrange flows and avoid overlaps of arrow heads and flows
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:
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:
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.
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.