Page 1 of 117 (2326 posts)

  • talks about »

Tags

Last update:
Mon Nov 11 20:50:09 2019

A Django site.

QGIS Planet

SLYR ESRI to QGIS compatibility suite – November 2019 update

It’s a been a month full of huge improvements since the last update, and we have some exciting news to share about our SLYR ESRI to QGIS compatibility suite. With the recently published plugin version 3.7, MXD conversion has moved from a “beta” state to being fully supported and available out-of-the-box for all users!

Based on our massive library of reference files (almost 10,000 files covering a huge range of ArcGIS versions and features!), the tool is now able to successfully convert 96% of LYR files and 94.5% of MXD documents. This is a significant milestone, and with it we decided that MXD conversion support is now stable enough to move out of its previous beta state.

Aside from this milestone, the 3.7 release brings many more enhancements and improvements, including:

  • SLYR now has full support for PMF published map documents created by ArcGIS Publisher, along with a new Processing algorithm to convert from a PMF document to a QGS projects
  • We’ve also added support for converting ArcScene SXD scenes to QGS projects. This conversion is 2-dimensional only for now, but we plan on adding 3D conversion when QGIS’ 3D support further matures.
  • We now convert all data frames contained within MXD documents, instead of just the first data frame. Currently, these are exposed as their own individual groups within the project layer tree (when we enable support for page layout conversion we’ll be automatically creating corresponding map themes from each data frame).
  • We’ve added support for reading many more layer types, including raster catalog layers, topology layers, terrain layers, and LAS dataset layers. While QGIS doesn’t have support for these layer types, we need to fully parse them in order to convert the rest of the MXD document contents. Whenever an unsupported layer type like these are encountered the plugin shows a warning advising users which layers could not be successfully converted.
  • We’ve also added support for reading TIN layers. Although previous QGIS versions had no means to read ESRI tin layers, thanks to work done in the MDAL library the upcoming QGIS 3.10.1 release adds full support for reading these data files! Accordingly, we’ll be unlocking support for converting TIN layers contained within MXD documents following the 3.10.1 release.
  • Full support for WMTS and tiled internet layers
  • Support for reading MXD documents which have repaired by the MXD Doctor utility
  • Support for layers with a geopackage source
  • Conversion of ImageServer based layers (since QGIS only has basic support for ESRI ImageServers, we convert these layers to their equivalent MapServer versions wherever possible)
  • Basic support for representation renderers. Although QGIS has no capability to utilise the symbology linked with a representation renderer, we’ve added support for rendering these layers using any geometry overrides which may be present for the features.
  • Conversion support for simple scale dependent renderers (these are a funny beast, which can’t be created directly through the ArcMap interface and which require custom ArcObjects code to create! That said, we’ve encountered a few examples of these inside our test library so have added support for converting them to the equivalent QGIS rule based renderer).
  • We added a new “random marker fill” symbol type to the upstream QGIS project, which will be available in QGIS 3.12 along with support in SLYR for conversion of ESRI random marker fills.

So what’s next for SLYR? Over the remainder of 2019 we’ll be working furiously toward 100% conversion rates for LYR and MXD files. We’ll also start rolling out conversion support for page layouts to QGIS print layouts, and support for automatic conversion of ArcMap TIN layers to QGIS mesh layers.

Keep an eye on this blog and our Twitter channel for further updates!

 

QGIS Print Layouts Graphs and Charts Campaign – Complete!

Last week saw the exciting release of version 3 of the QGIS DataPlotly plugin, which incorporates all the work done as a result of our Print Layouts Graphs and Charts crowdfunding campaign crowd funding campaign. Now, beautiful charts and graphs are available directly within QGIS print layouts, and all it takes is the easy installation of the “DataPlotly” plugin from your QGIS install!

In this post we’ll showcase the functionality which has been added during this campaign, and which is available today in the plugin.

UI modernisation and tweaks

First up, during our work on this plugin we’ve invested some time in refreshing the plugin’s UI to ensure it follows all the widget conventions used elsewhere in QGIS. Now, the plugin blends seamlessly into your QGIS window, and all the chart setting widgets behave in just the way you’re used to. We’ve also used this opportunity to fix a number of issues the plugin had when running on hi-dpi displays (such as Apple retina displays)!

 

Dynamic charting of selected and visible features

If you’ve used earlier versions of the DataPlotly plugin, you’ll likely notice that there’s many new options shown in the screenshot above. Possibly the most exciting of these is the new “Use only selected features” and “Use only visible features” checkboxes. When either of these options are enabled, then your chart will immediately respond to changes in layer selections or changes to the visible map canvas extent respectively. Previously, interactivity in the plugin only went one way (from the chart to the canvas) – but now the charts are truly interactive, and respond dynamically to changes in the canvas too!

 

Improved handling of “data defined” settings

During the plugin refactoring, we reworked how “data defined” settings are handled within charts. If you’re not familiar with these, “data defined” settings are QGIS’ approach for exposing per-feature control over the map rendering process. In DataPlotly charts, we expose this functionality to allow per-feature control over the chart appearance (e.g., showing different scatter plot dot colors based on feature attributes). The new code uses the same code model as QGIS itself, so data-defined settings in your charts now have full access to the whole suite of QGIS expression functions and variables that you’re used to! Additionally, QGIS data-defined assistants are fully supported in the charts too. Ultimately, this enables some very advanced styling options, such as charts which dynamically change color and appearance on every page of your print atlas…

Charts in print layouts

We’ve previously covered this feature in depth, but the DataPlotly v3 release brings print-layout based charts to the masses! When a chart is inserted into a print layout, some additional options are available for controlling the plot behavior:

These new options allow you to link the chart to a map item within the layout, which lets you filter the content of the chart to only include features visible within the map. If your print layout is setup as an atlas export, you can also filter out included features to only show those which are geographically located inside the current atlas feature.

Our partners from Faunalia demonstrate this in the screencast below:

 

Saving plot configuration

An often-requested functionality previous missing from the plugin was the ability to save and restore plot configuration. Now, plot configuration is automatically saved within your QGIS project and restored when you reopen the project. You no longer have to re-create all your charts from scratch at every session (ouch!). We also added the ability to export chart configuration to XML files, allowing you to share and reuse chart configuration across projects.

Behind the scenes work

Aside from all the wonderful new features added to the plugin, we’ve extensively refactored most of the plugin backend. Unit tests and CI infrastructure have been added, which will ensure the plugin remains stable and regression-free in future releases. The code cleanup and simplification has drastically lowered the barrier of contribution to the project, and we’ve already seen new contributors adding more new features to the plugin as a result of this! (Kudos to Simon Gröchenig, who added the new “Feature subset” expression option you can see in the above screenshots!).

Project sponsors

All this work is thanks to the backers of our crowdfunding campaign. Without their contributions this work would not have been possible! In no particular order, our thanks go out to:

  • Federico Gianoli
  • Papercraft Mountains
  • Liam McCrae
  • Henry Walshaw
  • Raúl Sangonzalo
  • Ferdinando Urbano
  • pitsch-ing.ch
  • Carbon-X
  • Gabriel Diosan
  • Rene Giovanni Borella
  • Enrico Bertonati
  • Guido Ingwer
  • David Addy
  • Gerd Jünger
  • Andreas Neumann
  • Stefano Campus
  • Michael Jabot
  • Korto
  • Enrico Ferreguti
  • Carlo A. Nicolini
  • Salvatore Fiandaca
  • Alberto Grava
  • Hans van der Kwast
  • Ben Hur Pintor
  • Silvio Grosso
  • Nobusuke Iwasaki
  • Alasdair Rae
  • Manori Senanayake
  • Canton de Neuchâtel
  • Matthias Daues
  • Alteri Seculo
  • SunGIS Ltd.
  • Stu Smith
  • Keolis Rennes
  • Gabriel Diosan
  • Aiden Price
  • Giacomo Ponticelli
  • Diane Fritz
  • Gemio Bissolati
  • Claire Birnie
  • Nicolas Roelandt
  • Rocco Pispico
  • Gabriel Bengtsson
  • Birds Eye View
  • Barend Köbben
  • Roberto Marzocchi (GTER)
  • Yoichi Kayama
  • Alessandro Sarretta
  • Luca Angeli
  • Luca Bellani
  • giswelt
  • Stefan Giese
  • Ben Harding
  • Joao Gaspar
  • Romain Lacroix
  • Ryan Cooper
  • Daniele Bonaposta
  • QGIS Swedish User Group
  • Nino Formica
  • Michael Gieding
  • Amedeo Fadini
  • Andrew Hannell
  • Stefano
  • Phil Wyatt
  • Brett Edmond Carlock
  • Transitec

Keep an eye out on the North Road blog for future crowd-funding initiatives. Coming soon: a QGIS Processing grab-bag of ETL modelling improvements!

Folium vs. hvplot for interactive maps of Point GeoDataFrames

In the previous post, I showed how Folium can be used to create interactive maps of GeoPandas GeoDataFrames. Today’s post continues this theme. Specifically, it compares Folium to another dataviz library called hvplot. hvplot also recently added support for GeoDataFrames, so it’s interesting to see how these different solutions compare.

Minimum viable

The following snippets show the minimum code I found to put a GeoDataFrame of Points onto a map with either Folium or hvplot.

Folium does not automatically zoom to the data extent and I didn’t find a way to add the whole GeoDataFrame of Points without looping through the rows individually:

Hvplot on the other hand registers the hvplot function directly with the GeoDataFrame. This makes it as convenient to use as the original GeoPandas plot function. It also zooms to the data extent:

Standard interaction and zoom to area of interest

The following snippets ensure that the map is set to a useful extent and the map tools enable panning and zooming.

With Folium, we have to set the map center and the zoom. The map tools are Leaflet defaults, so panning and zooming work as expected:

Since hvplot does not come with mouse wheel zoom enabled by default, we need to set that:

Color by attribute

Finally, for many maps, we want to show the point location as well as an attribute value.

To create a continuous color ramp for a numeric value, we can use branca.colormap to define the marker fill color:

In hvplot, it is sufficient to specify the attribute of interest:

I’m pretty impressed with hvplot. The integration with GeoPandas is very smooth. Just don’t forget to set the geo=True parameter if you want to plot lat/lon geometries.

Folium seems less straightforward for this use case. Maybe I missed some option similar to the Choropleth function that I showed in the previous post.

QGIS 3.10 A Coruña is released!

We are pleased to announce the release of QGIS 3.10 ‘A Coruña’! A Coruña was the location of our developer meeting and user conference in March 2019.

Installers for all supported operating systems are already out. QGIS 3.10 comes with tons of new features, as you can see in our visual changelog.

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 sustaining members. 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 a sustaining member, please visit our page for sustaining members for details. Your support helps us fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts.

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.

Interactive plots for GeoPandas GeoDataFrames of LineStrings

GeoPandas makes it easy to create basic visualizations of GeoDataFrames:

However, if we want interactive plots, we need additional libraries. Folium (which is built on Leaflet) is a great option. However, all examples for plotting GeoDataFrames that I found focused on point or polygon data. So here is what I found to work for GeoDataFrames of LineStrings:

First, some imports:

import pandas as pd
import geopandas
import folium

Loading the data:

graph = geopandas.read_file('data/population_test-routes-geom.csv')
graph.crs = {'init' :'epsg:4326'}

Creating the map using folium.Choropleth:

m = folium.Map([48.2, 16.4], zoom_start=10)

folium.Choropleth(
    graph[graph.geometry.length>0.001],
    line_weight=3,
    line_color='blue'
).add_to(m)

m

I also tried using folium.PolyLine which seemed like the more obvious choice but does not seem to accept GeoDataFrames as input. Instead, it expects a list of coordinate pairs and of course it expects them to be in the opposite order that Shapely.LineString.coords provides … Oh the joys of geodata!

In any case, I had to limit the number of features that get plotted because Folium refuses to plot all 8778 features at once. I decided to filter by line length because drawing really short lines is pointless for my overview visualization anyway.

Results of the user questionnaire from Sep’19

Last month’s user question focused on QGIS documentation. More specifically, we asked how you learn how to use QGIS. And many of you answered our call. Indeed we collected 824 responses over a period of two weeks:

The answers to the first question show that the top three first sources of information on how to use QGIS features or solve problems are: 1. search engines, 2. Stack Exchange, and 3. the QGIS User Manual:

The answers to the second question show that most respondents look for information around 2-3 times a week:

The third question asked specifically about the official QGIS documentation and answers revealed that most users sometimes or often find answers there:

Overall respondents use the official documentation rather rarely:

Finally, there was an open ended question:

You can download the full responses if you’re interested in the details.

The results and lessons we can learn from the responses are currently being discussed on the community mailing list.

(Nederlands) Oprichting QGIS Gebruikersgroep Nederland

Sorry, this entry is only available in the Dutch language

PostGIS Day 2019 Zürich

Am Donnerstag 14. November findet der PostGIS Day in Zürich statt! Neben topaktuellen News zu den Releases von PostGIS 3, QGIS 3.10 LTR und OpenLayers 6 gibt es Einblicke in die Responsive City Strategie der Stadt Zürich und weitere Themen wie Datentransformationen mit hale studio und Vektor Tiles.

(Fr) Rechercher une adresse avec QGIS

Sorry, this entry is only available in French.

SLYR ESRI to QGIS compatibility suite – October 2019 update

Recently, staff at North Road have been hard at work on our SLYR “ESRI to QGIS compatiblity suite“, and we thought it’s time to share some of the latest exciting updates with you.

While SLYR begun life as a simple “LYR to QGIS conversion tool”, it quickly matured into a full ArcGIS compatibility suite for QGIS. Aside from its original task of converting ESRI LYR files, SLYR now extends the QGIS interface and adds seamless support for working with all kinds of ArcGIS projects and data files. It’s rapidly becoming a must-have tool for any organisation which uses a mix of ESRI and open source tools, or for any organisation exploring a transition away from ArcGIS to QGIS.

Accordingly, we thought it’s well past time we posted an update detailing the latest functionality and support we’ve added to SLYR over the past couple of months! Let’s dive in…

  • Full support for raster LYR file conversion, including unique value renderers, color map renderers, classified renderers, RGB renderers and stretched color ramp renderers:

    From ArcMap…

    …to QGIS!
  • Support for conversion of fill symbol outlines with complex offsets, decorations and dashed line templates
  • Conversion of 3D marker and simple 3D lines to their 2d equivalent, matching ArcMap’s 2D rendering of these symbol types
  • Beta support for converting map annotations and drawings, including custom text labels and reference scale support
  • Label and annotation callout support*
  • Support for converting bookmarks stored in MXD documents*
  • Support for converting ESRI bookmark “.dat” files via drag and drop to QGIS*
  • Correct conversion of OpenStreetMap and bing maps basemap layers
  • SLYR now presents users with a friendly summary of warnings generated during the LYR or MXD conversion process (e.g. due to settings which can’t be matched in QGIS)
  • Added support for MXD documents generated in very early ArcMap versions
  • We’ve added QGIS Processing algorithms allowing for bulk LYR to QLR and MXD to QGS conversion. Now you can run a batch conversion process of ALL MXD/LYR files held at your organisation in one go!
  • Greatly improved matching of converted symbols to their original ArcGIS appearance, including more support for undocumented ArcGIS symbol rendering behavior
  • Support for conversion of text symbols and label settings stored in .style databases*
  • Directly drag and drop layers and layer groups from ArcMap to QGIS to add them to the current QGIS project (maintaining their ArcGIS symbology and layer settings!)*
  • Directly drag and drop layers from ArcCatalog to QGIS windows to open in QGIS*
  • Support for ESRI MapServer layers

(*requires QGIS 3.10 or later)

Over the remainder of 2019, we’ll be hard at work further improving SLYR’s support for MXD document conversion, and adding support for automatic conversion of ArcMap print layouts to QGIS print layouts.

While SLYR is not currently an open-source tool, we believe strongly in the power of open source software, and accordingly we’ve been using a significant portion of the funds generated from SLYR sales to extend the core QGIS application itself. This has directly resulted in many exciting improvements to QGIS, which will become widely available in the upcoming QGIS 3.10 release. Some of the features directly funded by SLYR sales include:

  • A “Segment Center” placement mode for marker line symbols
  • Reworked bookmark handling in QGIS, with a greatly enhanced workflow and usability, and a stable API for 3rd party plugins and scripts to hook into
  • Improved handling of layer symbology for layers with broken paths
  • Auto repair of all other broken layers with a matching data source whenever a single layer path is fixed in a project
  • Support for managing text formats and label settings in QGIS style libraries, allowing storage and management of label and text format presets
  • A new Processing algorithm “Combine Style Databases“, allowing multiple QGIS style databases to be merged to one
  • Adding a “Save layer styles into GeoPackage” option for the “Package Layers” algorithm
  • New expression functions which return file info, such as file paths and base file names
  • Adding new options to autofill the batch Processing dialog, including adding input files using recursive filter based file searches
  • Coming in QGIS 3.12: A new option to set the color to use when rendering nodata pixels in raster layers
  • Coming in QGIS 3.12: A new “random marker fill” symbol layer type, which fills polygons by placing point markers in random locations

You can read more about our SLYR ESRI to QGIS compatibility tool here, or email info@north-road.com to discuss licensing arrangements for your organisation! Alternatively, send us an email if you’d like to discuss your organisations approach to open-source GIS and for assistance in making this transition as painless as possible.

Configure editing form widgets using PyQGIS

PT | EN

As I was preparing a QGIS Project to read a database structured according to the new rules and technical specifications for the Portuguese Cartography, I started to configure the editing forms for several layers, so that:

  1. Make some fields read-only, like for example an identifier field.
  2. Configure widgets better suited for each field, to help the user and avoid errors. For example, date-time files with a pop-up calendar, and value lists with dropdown selectors.

Basically, I wanted something like this:

Peek 2019-09-30 15-04_2

Let me say that, in PostGIS layers, QGIS does a great job in figuring out the best widget to use for each field, as well as the constraints to apply. Which is a great help. Nevertheless, some need some extra configuration.

If I had only a few layers and fields, I would have done them all by hand, but after the 5th layer my personal mantra started to chime in:

“If you are using a computer to perform a repetitive manual task, you are doing it wrong!”

So, I began to think how could I configure the layers and fields more systematically. After some research and trial and error, I came up with the following PyQGIS functions.

Make a field Read-only

The identifier field (“identificador”) is automatically generated by the database. Therefore, the user shouldn’t edit it. So I had better make it read only

Layer Properties - cabo_electrico | Attributes Form_103

To make all the identifier fields read-only, I used the following code.

def field_readonly(layer, fieldname, option = True):
    fields = layer.fields()
    field_idx = fields.indexOf(fieldname)
    if field_idx >= 0:
        form_config = layer.editFormConfig()
        form_config.setReadOnly(field_idx, option)
        layer.setEditFormConfig(form_config)

# Example for the field "identificador"

project = QgsProject.instance()
layers = project.mapLayers() 

for layer in layers.values():
    field_readonly(layer,'identificador')

Set fields with DateTime widget

The date fields are configured automatically, but the default widget setting only outputs the date, and not date-time, as the rules required.

I started by setting a field in a layer exactly how I wanted, then I tried to figure out how those setting were saved in PyQGIS using the Python console:

>>>layer = iface.mapCanvas().currentLayer()
>>>layer.fields().indexOf('inicio_objeto')
1
>>>field = layer.fields()[1]
>>>field.editorWidgetSetup().type()
'DateTime'
>>>field.editorWidgetSetup().config()
{'allow_null': True, 'calendar_popup': True, 'display_format': 'yyyy-MM-dd HH:mm:ss', 'field_format': 'yyyy-MM-dd HH:mm:ss', 'field_iso_format': False}

Knowing this, I was able to create a function that allows configuring a field in a layer using the exact same settings, and apply it to all layers.

def field_to_datetime(layer, fieldname):
    config = {'allow_null': True,
              'calendar_popup': True,
              'display_format': 'yyyy-MM-dd HH:mm:ss',
              'field_format': 'yyyy-MM-dd HH:mm:ss',
              'field_iso_format': False}
    type = 'Datetime'
    fields = layer.fields()
    field_idx = fields.indexOf(fieldname)
    if field_idx >= 0:
        widget_setup = QgsEditorWidgetSetup(type,config)
        layer.setEditorWidgetSetup(field_idx, widget_setup)

# Example applied to "inicio_objeto" e "fim_objeto"

for layer in layers.values():
    field_to_datetime(layer,'inicio_objeto')
    field_to_datetime(layer,'fim_objeto')

Setting a field with the Value Relation widget

In the data model, many tables have fields that only allow a limited number of values. Those values are referenced to other tables, the Foreign keys.

In these cases, it’s quite helpful to use a Value Relation widget. To configure fields with it in a programmatic way, it’s quite similar to the earlier example, where we first neet to set an example and see how it’s stored, but in this case, each field has a slightly different settings

Luckily, whoever designed the data model, did a favor to us all by giving the same name to the fields and the related tables, making it possible to automatically adapt the settings for each case.

The function stars by gathering all fields in which the name starts with ‘valor_’ (value). Then, iterating over those fields, adapts the configuration to use the reference layer that as the same name as the field.

def field_to_value_relation(layer):
    fields = layer.fields()
    pattern = re.compile(r'^valor_')
    fields_valor = [field for field in fields if pattern.match(field.name())]
    if len(fields_valor) > 0:
        config = {'AllowMulti': False,
                  'AllowNull': True,
                  'FilterExpression': '',
                  'Key': 'identificador',
                  'Layer': '',
                  'NofColumns': 1,
                  'OrderByValue': False,
                  'UseCompleter': False,
                   'Value': 'descricao'}
        for field in fields_valor:
            field_idx = fields.indexOf(field.name())
            if field_idx >= 0:
                print(field)
                try:
                    target_layer = QgsProject.instance().mapLayersByName(field.name())[0]
                    config['Layer'] = target_layer.id()
                    widget_setup = QgsEditorWidgetSetup('ValueRelation',config)
                    layer.setEditorWidgetSetup(field_idx, widget_setup)
                except:
                    pass
            else:
                return False
    else:
        return False
    return True
    
# Correr função em todas as camadas
for layer in layers.values():
    field_to_value_relation(layer)

Conclusion

In a relatively quick way, I was able to set all the project’s layers with the widgets I needed.Peek 2019-09-30 16-06

This seems to me like the tip of the iceberg. If one has the need, with some search and patience, other configurations can be changed using PyQGIS. Therefore, think twice before embarking in configuring a big project, layer by layer, field by fields.

Advertisements

QGIS Versioning now supports foreign keys!

QGIS-versioning is a QGIS and PostGIS plugin dedicated to data versioning and history management. It supports :

  • Keeping full table history with all modifications
  • Transparent access to current data
  • Versioning tables with branches
  • Work offline
  • Work on a data subset
  • Conflict management with a GUI

QGIS versioning conflict management

In a previous blog article we detailed how QGIS versioning can manage data history, branches, and work offline with PostGIS-stored data and QGIS. We recently added foreign key support to QGIS versioning so you can now historize any complex database schema.

This QGIS plugin is available in the official QGIS plugin repository, and you can fork it on GitHub too !

Foreign key support

TL;DR

When a user decides to historize its PostgreSQL database with QGIS-versioning, the plugin alters the existing database schema and adds new fields in order to track down the different versions of a single table row. Every access to these versioned tables are subsequently made through updatable views in order to automatically fill in the new versioning fields.

Up to now, it was not possible to deal with primary keys and foreign keys : the original tables had to be constraints-free.  This limitation has been lifted thanks to this contribution.

To make it simple, the solution is to remove all constraints from the original database and transform them into a set of SQL check triggers installed on the working copy databases (SQLite or PostgreSQL). As verifications are made on the client side, it’s impossible to propagate invalid modifications on your base server when you “commit” updates.

Behind the curtains

When you choose to historize an existing database, a few fields are added to the existing table. Among these fields, versioning_ididentifies  one specific version of a row. For one existing row, there are several versions of this row, each with a different versioning_id but with the same original primary key field. As a consequence, that field cannot satisfy the unique constraint, so it cannot be a key, therefore no foreign key neither.

We therefore have to drop the primary key and foreign key constraints when historizing the table. Before removing them, constraints definitions are stored in a dedicated table so that these constraints can be checked later.

When the user checks out a specific table on a specific branch, QGIS-versioning uses that constraint table to build constraint checking triggers in the working copy. The way constraints are built depends on the checkout type (you can checkout in a SQLite file, in the master PostgreSQL database or in another PostgreSQL database).

What do we check ?

That’s where the fun begins ! The first thing we have to check is key uniqueness or foreign key referencing an existing key on insert or update. Remember that there are no primary key and foreign key anymore, we dropped them when activating historization. We keep the term for better understanding.

You also have to deal with deleting or updating a referenced row and the different ways of propagating the modification : cascade, set default, set null, or simply failure, as explained in PostgreSQL Foreign keys documentation .

Nevermind all that, this problem has been solved for you and everything is done automatically in QGIS-versioning. Before you ask, yes foreign keys spanning on multiple fields are also supported.

What’s new in QGIS ?

You will get a new message you probably already know about, when you try to make an invalid modification committing your changes to the master database

Error when foreign key constraint is violated

Partial checkout

One existing Qgis-versioning feature is partial checkout. It allows a user to select a subset of data to checkout in its working copy. It avoids downloading gigabytes of data you do not care about. You can, for instance, checkout features within a given spatial extent.

So far, so good. But if you have only a part of your data, you cannot ensure that modifying a data field as primary key will keep uniqueness. In this particular case, QGIS-versioning will trigger errors on commit, pointing out the invalid rows you have to modify so the unique constraint remains valid.

Error when committing non unique key after a partial checkout

Tests

There is a lot to check when you intend to replace the existing constraint system with your own constraint system based on triggers. In order to ensure QGIS-Versioning stability and reliability, we put some special effort on building a test set that cover all use cases and possible exceptions.

What’s next

There is now no known limitations on using QGIS-versioning on any of your database. If you think about a missing feature or just want to know more about QGIS and QGIS-versioning, feel free to contact us at infos+data@oslandia.com. And please have a look at our support offering for QGIS.

Many thanks to eHealth Africa who helped us develop these new features. eHealth Africa is a non-governmental organization based in Nigeria. Their mission is to build stronger health systems through the design and implementation of data-driven solutions.

User question of the Month – Sep’19

After the summer break, we’re back with a new user question.

This month, we want to focus on documentation. Specifically, we’d like to know how you learn how to use QGIS.

The survey is available in English, Spanish, Portuguese, French, Ukrainian, and Indonesian. If you want to help us translate user questions into more languages, please get in touch on the community mailing list!

QGIS Print Layouts Graphs and Charts — Beta Out Now!

Thanks to the success of our recent QGIS Print Layouts Graphs and Charts crowdfunding campaign, staff at North Road and Faunalia have been busy updating and improving the QGIS “DataPlotly” plugin with the goal of allowing beautiful charts inside your print layouts.

We’re super-excited to announce that the beta release of this new functionality is now available! With this beta installed, you’ll see a new icon in your QGIS Print Layout designer window:

Clicking this button will allow you to draw a new plot onto your print layout, just like you would any other standard layout item (like legends, scalebars, etc). Any print layout chart can be customised by right-clicking the chart and selecting “Item Properties“. This will open a panel with settings like position, size, frame, and other standard options. All the magic happens when you click the “Setup Plot” button inside this panel:

This exposes the vast array of styling and charting options available for use. If you’re an existing user of the DataPlotly QGIS plugin, you’ll recognise that these are the same settings you have available when creating interactive plots alongside the main map canvas. Every setting is now available for use in print layouts!

 

To grab the beta, head over to https://github.com/ghtmtt/DataPlotly/releases/tag/v3.9-beta and download the DataPlotly.zip file. Then, inside QGIS, select the Manage and Install Plugins option from the Plugins menu. Click on the “Install from ZIP” section, and point the dialog at your downloaded DataPlotly.zip file. Click “Install Plugin“, and then restart QGIS for good measure. When QGIS restarts you should see the new chart icon inside the print layout designer.

Note that you’ll need a recent QGIS release for this to work correctly — either QGIS 3.8.3 or 3.4.12. (The print layout functionality may not be compatible with earlier releases, as we’ve had to fix several issues inside QGIS itself to get this feature working as designed!). 

We are actively seeking feedback and user testing on this beta release. If you encounter any issues, just head over to https://github.com/ghtmtt/DataPlotly/issues and let us know.

We’ll be further refining this functionality, with the goal of releasing the final non-beta version of the plugin to coincide with the upcoming QGIS 3.10 release.

Happy charting!

PDAL 2.0.1 packaged for Fedora including vertical datums and grids

Cologne city shown as colorized 3D point cloud (data source: openNRW Germany)The latest PDAL release (Point Data Abstraction Library, http://www.pdal.io/, version 2.0.1) has now been packaged for Fedora Linux.
I have cleaned up the dependencies (also the annoying former installation bug with PDAL-devel has been resolved).

The installation is as simple as this (the repository is located at Fedora’s COPR):

# enable and install PDAL
sudo dnf copr enable neteler/pdal
sudo dnf install PDAL PDAL-libs PDAL-vdatums

# if you want to compile other software like GRASS GIS with PDAL support, then you also need
sudo dnf install PDAL-devel
# Now, run PDAL:
pdal-config --version
pdal --help

Enjoy!

The post PDAL 2.0.1 packaged for Fedora including vertical datums and grids appeared first on GFOSS Blog | GRASS GIS and OSGeo News.

Movement data in GIS #24: MovingPandas hands-on tutorials

Last week, I had the pleasure to give a movement data analysis workshop at the OpenGeoHub summer school at the University of Münster in Germany. The workshop materials consist of three Jupyter notebooks that have been designed to also support self-study outside of a workshop setting. So you can try them out as well!

All materials are available on Github:

  • Tutorial 0 provides an introduction to the MovingPandas Trajectory class.
  • Tutorials 1 and 2 provide examples with real-world datasets covering one day of ship movement near Gothenburg and multiple years of gull migration, respectively.

Here’s a quick preview of the bird migration data analysis tutorial (click for full size):

Tutorial 2: Bird migration data analysis

You can run all three Jupyter notebooks online using MyBinder (no installations required).

Alternatively or if you want to dig deeper: installation instructions are available on movingpandas.org

The OpenGeoHub summer school this year had a strong focus on spatial analysis with R and GRASS (sometimes mixing those two together). It was great to meet @mdsumner (author of R trip) and @edzerpebesma (author of R trajectories) for what might have well been the ultimate movement data libraries geek fest. In the ultimate R / Python cross-over,  0_getting_started.Rmd

Both talks and workshops have been recorded. Here’s the introduction:

and this is the full workshop recording:

QGIS 3.10 Loves GeoPDF!

Recently, we’ve been working on an exciting development which is coming soon in QGIS 3.10… support for Geospatial PDF exports! This has been a long-desired feature for many QGIS users, and it was only made possible thanks to a group of financial backers (listed below). In this post, we’re going to explore these new features and how they improve your QGIS PDF outputs.

Geospatial PDFs can now be created either by exporting the main QGIS map canvas, or by creating and exporting a custom print layout. For instance, when you select the “Save Map as PDF” option from the main QGIS window, you’ll see a new group of Geospatial PDF related options:

At its most basic, Geospatial PDF is a standard extension to the PDF format which allows for vector spatial datasets to be embedded in PDF files. If the “Include vector feature information” checkbox is ticked when creating a Geospatial PDF output, then QGIS will automatically include all the geometry and attribute information from features visible within the page. So if we export a simple map to PDF, we’ll get an output file which looks just like any old regular PDF map output…

…but, we can also pull this PDF back into QGIS and treat it just like any other vector data source! In the screenshot below we’re using the Identify tool to query on of the polygons and see all the attribute information from the original source layer.

This ability adds a lot of value to PDF exports. Anyone who has ever been supplied a non-spatial PDF as a “spatial dataset” will attest to the frustrations these cause… but if you create proper Geospatial PDFs instead, then there’s no loss of the valuable underlying spatial information or feature attributes! Furthermore, if these PDFs are opened within Acrobat Reader, tools are enabled which allow users to query features interactively.

Another nice benefit which comes with Geospatial PDF output is that layers can be interactively toggled on or off in the PDF viewer. The screenshot below shows a Geospatial PDF file created from a simple QGIS map. On the left we have a list of the layers in the PDF, each of which can be turned on or off inside the PDF viewer!

The really nice thing here is that, thanks to the underlying smarts in the GDAL library which is responsible for the actual Geospatial PDF creation, the PDF renders identically to our original QGIS map. While labels turn on and off alongside their corresponding map layer, they are still correctly stacked in the exact same way as you see in the QGIS window. Furthermore, the created PDFs keep labels and vector features as vector artwork… so there’s absolutely no loss in quality when zooming in to the map! These files look GREAT!

On that same note… the sponsorship allowed us to tackle another related issue, which is that in previous QGIS versions PDF (or SVG) exports would always export every single vertex from any visible feature! Ouch! This meant that if you had a complex polygon boundary layer, you would potentially be creating a PDF with millions of vertices per feature, even though most of these would be overlapping and completely redundant at the exported map’s scale. Now, QGIS automatically simplifies vector features while exporting them (using an appropriate, effectively invisible, level of simplification). The dramatically reduces the created file sizes and speeds up opening them and navigating them in other applications (especially Inkscape). (There’s an option at export time to disable this simplification, if you have a specific reason to!).

Creating Geospatial PDFs from print layouts gives even more options. For a start, whenever a print layout is exported to Geospatial PDFs, we ensure that the created PDF correctly handles stacking of layers alongside any other print layout items you have. In the image below we see a custom print layout which includes interactive layer visibility controls. If a layer is toggled, it’s hidden only from the map item — all the other surrounding elements like the title, north arrow and scalebar remain visible:

That’s not all though! When exporting a print layout to Geospatial PDF, QGIS also hooks into any map themes you’ve setup in your project. If you select to include these themes in your output, then the result is magical! The screenshot below shows the export options for a project with a number of themes, and we’ve chosen to export these themes in the PDF:

Opening the resultant PDF shows that our layer control on the left now lists the map themes instead of individual layers. Viewers can switch between these themes, changing the visibility of layers and their styling to match the QGIS map theme from the project! Additionally, you can even expand out a theme and expose layer-by-layer visibility control. Wow! This means you could create a single PDF output file which includes an environmental, social, cadastral, transport, …. view of your map, all in the one file.

Lastly, there’s even control for fine-tuning the combination of layers which are exposed in the output PDF file and which ones should be toggled on and off together. In the screenshot below we’ve opted to group the “Aircraft” and “Roads” map layers into a single logical PDF group called “Transport”. 

The resultant PDF respects this, showing an entry in the interactive layer tree for “Transport” which toggles both the aircraft and roads layers together:

So there you go — the power of Geospatial PDF, coming your way in QGIS 3.10!

One semi-related benefit of this work is that it gave us an opportunity to rework how “layered” exports from print layouts are created. This has had a significant flow-on impact on the existing ability to create layered SVG outputs from QGIS. Previously, this was a rather fragile feature, which created SVGs with lots of issues – overlapping labels, incorrectly stacked layers, and last-but-not-least, non-descriptive layer names! Now, just like Geospatial PDF exports, the layered SVG exports correctly respect the exact look of your map, and have much more friendly, descriptive layer names:

This should significantly reduce the amount of housekeeping required when working on these layered SVG exports. 

This work was funded by:

  • Land Vorarlberg
  • Municipality of Vienna
  • Municipality of Dornbirn
  • Biodiversity Information Service for Powys and BBNP Local
  • Kanton Zug
  • Canton de Neuchâtel
  • Canton de Thurgovia

North Road are leading experts in extending the QGIS application to meet your needs. If you’d like to discuss how you can sponsor development of features or fixes which you want in QGIS, just contact us for further details!

 

 

FOSS4G 2019 Bucharest

Reporting back from the annual international FOSS4G conference, which took place in Bucharest this year.

Select by location: what about those geometric predicates?

Currently, there’s around 20 persons in Bucharest working on QGIS development during the Contributors Meeting. And because the name of the hackfest is changed from developers meeting to contributors meeting, I now feel welcome too (as a non-coding contributor). So what can I do, as a non-coding QGIS fan? Write documentation! I just started with … Continue reading Select by location: what about those geometric predicates?

Introducing new QGIS macOS packages

We now have signed packages for macOS. You can find these packages published on the official QGIS download page at http://download.qgis.org.

Rationale

In addition to being a very powerful and user-friendly open source GIS application, QGIS can be installed on different operating systems: MS Windows, macOS, various flavours of Linux and FreeBSD. 

Volunteers help with generating the installers for those platforms. The work is highly valuable and the scale of effort put into packaging over the years is often underappreciated. QGIS has also grown significantly over the years and so has its complexity to package relevant libraries and 3rd party tools to the end-users.

QGIS has been packaged on OSX/macOS for many years, making it one of the few GIS applications you can use on this platform. This is largely thanks to the tireless work of William Kyngesburye (https://www.kyngchaos.com/software/qgis/) who has shouldered the task of compiling QGIS and its dependencies and offering them as disk images on the official QGIS website. The packages for each new release are available within days for all supported macOS versions.

Unlike most other operating systems, macOS can only be run on Apple hardware. This is a barrier for developers on other platforms who wish to compile and test their code on macOS. For other platforms, QGIS developers have automated packaging, not only for the major releases but also for daily code snapshots (aka nightly or master builds). Availability of the daily packages has allowed testers to identify platform-specific issues, well before the official release.

Apple also has a system of software signing so that users can verify if the packages are securely generated and signed by the developers. Up until now, signed macOS packages were not available, resulting in users who are installing QGIS needing to go into their security preferences and manually allow the QGIS application to be run. 

A new approach

In October 2018, Lutra Consulting started their work on packaging QGIS for macOS. The work has been based on OSGeo tap on Homebrew. Homebrew is a ‘bleeding edge’ package manager similar to those provided by Gentoo or Arch Linux. The packages by Lutra bundle the various libraries and resources on which QGIS depends into a single QGIS.app application bundle.  The packages were made available in late 2018 for QGIS official releases and master. QGIS Mac users have eagerly tested and reported various issues and the majority of them were resolved in early 2019.

Following the successful launch of the prototype packages and in discussion with other developers, it was agreed to transfer the ownership of the packaging infrastructure and scripts (https://github.com/qgis/QGIS-Mac-Packager) to QGIS.org. Using the new infrastructure and OSGeo Apple developers certificate, all QGIS ‘disk images’ (installers) have been available since late May 2019.

What are the main difference between the new installers and the ones offered by Kyngchaos? The new installer offers:

  • 3 clicks to install: download, accept Terms & Conditionss, drop to /Application
  • All dependencies (Python, GDAL, etc)  are bundled within the disk image
  • Signed by OSGeo Apple certificate
  • Availability of nightly builds (master)
  • Scripts for bundling and packaging are available on a public repository
  • Possibility of installing multiple versions (e.g. 3.4 LTR, 3.8 and master) side-by-side

There are some known issues:

For a full list, see: https://github.com/qgis/QGIS-Mac-Packager

Further work

We hope that by providing the new installers, macOS users will have a better experience in installing and using QGIS. Ideally, with the availability of nightly builds and being more accessible to new users, more software bugs and issues will be reported and this will help to improve QGIS overall.

Maintaining and supporting macOS costs more compared with other platforms. As QGIS is one of the only viable GIS applications for macOS users in an enterprise environment, we encourage you and your organisation to become a sustaining member to help assure the continued availability and improvement of the macOS packages in the long term.

Future plans

In future we plan to migrate the packaging process to use Anaconda QGIS packages as the source for package binaries. We also would like to integrate macOS builds into the Travis-CI automated testing that happens whenever a new GitHub pull request is submitted so that we can validate that the macOS packages do not get any regressions when new features are introduced.

Conclusion

With this work, we now have nightly builds of the upcoming release (‘master’) branch available for all to use on macOS. We now have signed packages and we have an automated build infrastructure that will help to ensure that macOS users always have ready access to new versions of QGIS as they become available. You can find these packages published on the official QGIS download page at http://download.qgis.org. A huge thanks to the team at Lutra Consulting for taking this much-needed work, and to William Kyngesburye for the many years that he has contributed towards the macOS/OSX QGIS packaging effort!

 

  • Page 1 of 117 ( 2326 posts )
  • >>

Back to Top

Sponsors