This campaign covers stage 1 of a large, ongoing project to modernise and expand on QGIS’ print composer and layout facilities.
Campaign concluded successfully 31 May 2017
Hall of fame
Current contributors to this work include:
- Swiss QGIS User group (funded preliminary work in refactoring how compositions are handled and stored within projects)
- QGIS Grant Program (2016) (funded preliminary work allowing for a flexible property framework which will be used within the project)
- Land Vorarlberg, Austria
- Tudor Bărăscu
- Oester Messtechnik GmbH, Thun, Switzerland
- Ferdinando Urbano, Italy
- Alta ehf, Reykjavik, Iceland
- Trage Wegen, Belgium
- QGIS Denmark User Group, Denmark
- Debuco Techniek B.V., Netherlands
- The QWAT Project
- QGIS Sweden User Group, Sweden
- Andreas Neumann
- Kristianstads kommun, Sweden
- City of Vevey, Switzerland
- Kanton Thurgau, Switzerland
- Ricardo Pinho, Portugal
- Portugese QGIS User Group, Portugal
- Waymotion, Portugal
- Lloyd Analytics LLC, USA
- Canton of Neuchâtel, Switzerland
- Hartmut Dickel, Switzerland
How it works
Crowd funding operates by multiple organisations (or individuals!) each pledging to contribute part of the campaign’s funding goals. The composer refactoring is a large, extensive, and complex undertaking and accordingly we require 30,000€ to make this feature a reality. You can contribute part (or all) of these funds. If the funding goal is NOT reached, then no contributions are payable and the feature will not be added to QGIS.
This campaign is being targeted to the QGIS 3.0 release. To allow time for completion of the work and sufficient user testing prior to release, the deadline for the campaign is May 31 2017.
If you’d like to see the next generation of QGIS’ print composer, then your contributions are vital! Pledge, or publicise, this campaign to help it reach the funding goal before the May 31 deadline!
About the feature
This crowd-funding campaign aims to implement stage 1 of a large, ongoing project to modernise and expand on QGIS’ print composer facilities. Stage 1 consists of:
- An extensive refactoring and rewriting of the print composer. This refactor will be undertaken at the same time as the initial implementation of the reporting framework, and is required to address design issues with the current composer code and to allow for the initial framework of reports. Over time QGIS’ composer functionality has grown extensively, but has now hit a limit where the current code architecture is prohibiting further improvements and important fixes. Before adding a reporting framework to QGIS, it is necessary to refactor and improve large sections of the composer code.
- As part of the refactor, the required API break will also be used to tackle a number of current limitations which cannot be addressed in the current composition code:
- Layouts will be unit aware, allowing for item placement and properties using millimetres, inches, pixels, centimetres, points, etc
- Layouts will have the ability to include mixed page sizes and orientations
- Plugins will be able to create custom composer item types (eg allow utilisation of 3rd party graphing and visualisation libraries)
- Individual layout items can be rasterised without affecting the rest of the layout. For instance, a map which requires rasterisation due to its use of blend modes will not require all other layout items (such as headings, legends, etc) to be rasterised.
- The code refresh will allow more extensive use of data defined layout item properties
- A render caching system will be implemented for items, speeding up use of the layout designer and also paving the way for use of live paint effects on layout items (eg dynamic drop shadows)
- Composition will be split into two types – “Print Layouts”, which mimics the current composer functionality, and “Report Layouts”. (Both will inherit from a single base layout class in the code to avoid unnecessary duplication)
- A Report consists of multiple report layout sections. In the initial implementation, these sections will all be full page sections (or multiple full pages) only. A report has:
- a report header and footer section. Both are full page report layouts, and are included at the start and end of the report respectively. Both can be enabled or disabled as desired
- a specified main “detail layer”. This is analogous to the coverage layer in a composition.
- for each attribute in the detail layer, the report can have “sections”. Features from the detail layer which share the same value for a selected section attribute will be grouped together, and a section header and section footer placed before and after the grouped features respectively. These grouped attributes will also form the sort order order for features from the detail layer.
- Report designer:
- A new dialog “Report Designer” will be created. This will consist of a split view, with the left side showing a text based tree view of the current report structure (including report headers and footers, section headers and footers, and detail sections). This list will also have a toolbar for adding new sections and allow reordering of report sections
- The right side will show properties of the currently selected report section, and include a button for opening the section in a layout designer (composer). Initially, the settings for sections will be:
- Report header and footer: checkbox for enabled or disabled
- Sections: checkbox for header enabled or disabled, checkbox for footer enabled or disabled, combobox for selecting whether the grouped section attribute will be sorted ascending or descending
- Detail: initially no properties
- Clicking the edit button will open a layout designer showing just that section of the report
- The report designer will also have buttons for exporting the entire report to PDF/image/SVG/printer
An example report
To illustrate the above concepts, here’s an example use case for the reporting engine. Imagine you have a layer “cities” which contains populated cities in an area, along with state and country as attributes. This layer will form the “detail layer” (name to be revised) for the report.
At its most basic, a report could have a header and footer and between them a detail section for each feature in the cities layer. Each of these (header, footer, each feature detail section) is like a composition of its own. For stage 1 they will all consist of full pages only. The report would then have pages for:
- report header
- city 1
- city 2
- report footer
Next, reports also have the option of having attribute sections. So, for the city layer, the report could have attribute sections for state and country. The cities layer is then sorted by these attributes, and each attribute section’s headers/footers placed whenever the attribute value changes. The resultant report would contain:
- report header
- header for country “Australia”
- header for state “Victoria”
- city 1
- city 2
- footer for state “Victoria”
- header for state “South Australia”
- city 3
- city 4
- footer for state “South Australia”
- header for state “Victoria”
- footer for country “Australia”
- header for country “New Zealand”
- report footer
Each of these sections is just like a composition of their own, and can contain any arrangement of composer items.
Potential follow up work to this initial first stage includes:
- allowing report sections to utilise project relations, such as repeating sections for each related feature from a child layer
- allowing non full-page sections in reports
- expanding the current composition template facilities to allow for “live” linked templates. Editing the template would then update ALL layouts linked to this live template.
Some important thing to note
- We believe that unit testing leads to stable software, and should be a prerequisite for all sponsored work for QGIS. So it goes without saying that the proposed changes will be soaked in regression unit tests covering the non-GUI portion of the changes to ensure that they are stable and will not break in future QGIS releases! (Seriously – if your developer isn’t implementing regression tests as a standard part of your sponsored features, then you’re only getting half of what you’re paying for and it’s probably time to revisit your contracts)
We understand that it can be difficult for organisations to approve contributing to a crowd-funding effort, so we’re trying to make this process as painless as possible:
- To contribute to the campaign, just email firstname.lastname@example.org and let us know your details and how much you will be contributing to the goal. Due to the administrative burden of processing payments, the minimum pledge we will accept is 200€ (or equivalent).
- We will contact you to discuss payment options – but NO payment is required in advance!
- If (and ONLY if!) the campaign is successful we will invoice you directly for your pledged amount. Payment in full will be required within 14 days of the campaign’s completion. (Please contact us to discuss if you need different payment terms).
- When we have received all pledged funds we will undertake the work detailed above, and provide regular updates as we go.
We believe this system should give organisations confidence that contributing to the campaign carries no risk and is compatible with their organisation’s accounting procedures. If however you have concerns or would like to contribute in another form, just contact us to discuss further!
- What happens if contributions exceed the campaign goal?
If contributions are in excess of the stated goal, we will reinvest the excess back into QGIS by using it to fund some of our other ongoing QGIS contributions, such as the ongoing work writing unit tests to ensure QGIS releases are stable and free from regressions. This will be done in a transparent and accountable way, and we will openly report on the ways additional funds are being used.
This work will be undertaken by North Road’s founder, Nyall Dawson. Nyall has an established history with QGIS development, and in recent years has been one of the most prolific contributors to the project.
At North Road we invest back into the open-source geospatial community. We do large amounts of volunteer fixes and feature additions across the open source geospatial stack, so by investing in us you also help support us improve the open source GIS stack.
We use the software we develop daily, so we take pride in developing stable, polished code with extensive regression testing and refined workflows. We offer long-term support for the code we create, providing proactive fixes and improvements even after a project is complete. Our development record demonstrates the confidence you can place in us for timely delivery of this crowd funding campaign’s product.
Please contact us for any further details on this project or for contributing to this campaign.