Page 1 of 91 (1812 posts)

  • talks about »

Tags

Last update:
Thu Jun 29 07:20:17 2017

A Django site.

QGIS Planet

QGIS WHY U NO PRINT DEBUG INFO

One of those days today where I burnt more time then I should on something that I din’t know about and spent way to much time searching for the wrong thing.

On a new install of Fedora I couldn’t get my QGIS to output any debug messages, even on my dev build running in the terminal, Qt Creator, or VS Code. Super frustraining to say the least.

Turns out the logging, at least on Fedora for Qt5, is disabled by default. You need to enable it by editing ~/.config/QtProject/qtlogging.ini and adding the following:

[Rules]
default.debug=true

The more you know!


Filed under: Open Source

(Nederlands) Zelf met de BGT in QGIS werken

Sorry, this entry is only available in the Dutch language

3rd QGIS User Conference

This year, we are looking forward to the 3rd installment of our annual QGIS conference and it will be the biggest one yet!

The QGIS community, developers and users are meeting from August 2–11, 2017 in Nødebo at University of Copenhagen’s Forest and Landscape College.

1st user conference in Nødebo 2015

The program consists of the main conference, as well as a developer meeting and multiple workshops, including:

  • QGIS Expressions
  • Plugin development in Python
  • QGIS Server and Web Client
  • QField
  • QGIS cartography

The program is already online. So register and make sure to get a spot in your favorite workshops!

Let’s meet and make QGIS even better!


Even more aggregations: QGIS point cluster renderer

In the previous post, I demonstrated the aggregation support in QGIS expressions. Another popular request is to aggregate or cluster point features that are close to each other. If you have been following the QGIS project on mailing list or social media, you probably remember the successful cluster renderer crowd-funding campaign by North Road.

The point cluster renderer is implemented and can be tested in the current developer version. The renderer is highly customizable, for example, by styling the cluster symbol and adjusting the distance between points that should be in the same cluster:

Beyond this basic use case, the point cluster renderer can also be combined with categorized visualizations and clusters symbols can be colored in the corresponding category color and scaled by cluster size, as demoed in this video by the developer Nyall Dawson:


Gereference a medal

Yesterday I ran the half marathon of Zwolle wearing a hat with the previous QGIS logo. My time was not so special (2:08:47) but the medal I earned was. It shows a simple map of the city of Zwolle. You can see some buildings but which ones? I decided to georerence the medal and add … Continue reading Gereference a medal

Aggregate all the things! (QGIS expression edition)

In the past, aggregating field values was reserved to databases, virtual layers, or dedicated plugins, but since QGIS 2.16, there is a way to compute aggregates directly in QGIS expressions. This means that we can compute sums, means, counts, minimum and maximum values and more!

Here’s a quick tutorial to get you started:

Load the airports from the QGIS sample dataset. We’ll use the elevation values in the ELEV field for the following examples:

QGIS sample airport dataset – categorized by USE attribute

The most straightforward expressions are those that only have one parameter: the name of the field that should be aggregated, for example:

mean(ELEV)

We can also add a second parameter: a group-by field, for example, to group by the airport usage type, we use:

mean(ELEV,USE)

To top it all off, we can add a third parameter: a filter expression, for example, to show only military airports, we use:

mean(ELEV,USE,USE='Military')

Last but not least, all this aggregating goodness also works across layers! For example, here is the Alaska layer labeled with the airport layer feature count:

aggregate('airports','count',"ID")

If you are using relations, you can even go one step further and calculate aggregates on feature relations.


QGIS Layout and Reporting Engine Campaign – a success!

Thanks to the tireless efforts and incredible generosity of the QGIS user community, our crowdfunded QGIS Layout and Reporting Engine campaign was a tremendous success! We’ve reached the funding goal for this project, and as a result QGIS 3.0 will include a more powerful print composer with a reworked code base. You can read more about what we have planned at the campaign page.

We’d like to take this opportunity to extend our heartfelt thanks to all the backers who have pledged to support this project:

We’ve also received numerous anonymous contributions in addition to these – please know that the QGIS community extends their gratitude for your contributions too! This campaign was also successful thanks to The Agency for Data Supply and Efficiency, Denmark, who stepped up and have funded an initial component of this project directly.

We’d also like to thank every member of the QGIS community who assisted with promoting this campaign and bringing it to the attention of these backers. Without your efforts we would not have been able to reach these backers and the campaign would not have been successful.

We’ll be posting more updates as this work progresses. Stay tuned…

 

Upcoming QGIS3 features – exploring the current developer version

There are tons of things going on under the hood of QGIS for the move from version 2 to version 3. Besides other things, we’ll have access to new versions of Qt and Python. If you are using a HiDPI screen, you should see some notable improvements in the user interface of QGIS 3.

But of course QGIS 3 is not “just” a move to updated dependencies. Like in any other release, there are many new features that we are looking forward to. This list is only a start, including tools that already landed in the developer version 2.99:

Improved geometry editing 

When editing geometries, the node tool now behaves more like editing tools in webmaps: instead of double-clicking to add a new node, the tool automatically suggests a new node when the cursor hovers over a line segment.

In addition, improvements include an undo and redo panel for quick access to previous versions.

Improved Processing dialogs

Like many other parts of the QGIS user interface, Processing dialogs now prominently display the function help.

In addition, GDAL/OGR tools also show the underlying GDAL/OGR command which can be copy-pasted to use it somewhere else.

New symbols and predefined symbol groups

The default symbols have been reworked and categorized into different symbol groups. Of course, everything can be customized in the Symbol Library.

Search in layer and project properties

Both the layer properties and the project properties dialog now feature a search field in the top left corner. This nifty little addition makes it much easier to find specific settings fast.

Save images at custom sizes

Last but not least, a long awaited feature: It’s finally possible to specify the exact size and properties of images created using Project | Save as image.

Of course, we still expect many other features to arrive in 3.0. For example, one of the successful QGIS grant applications was for adding 3D support to QGIS. Additionally, there is an ongoing campaign to fund better layout and reporting functionality in QGIS print composer. Please support it if you can!

 


2017 QGIS Governance Update

 

Screen Shot 2017-05-22 at 11.33.46 PM
QGIS Developers and Community Members working on QGIS at our recent meet up in Essen, German,

Dear Voting members (and interested QGIS community members out there)

This is an open letter that was emailed to all QGIS voting members today

Just a quick note from me to thank you for participating in our ‘virtual AGM’ – I know it is a bit of an unusual system but it suits our geographically diverse nature well and we seem to have pretty good participation in the process (though I really encourage those voting members who did not participate to do so next time!).
I have done a bunch of updates on our governance section of the web site so you can find the AGM minutes, annual report, budget etc. all on the site, and I (or whoever is chair) will post them there in future years too so everything is in one place and easy to access. Here with the relevant links:
Since we have approved a new version of the statutes, I have replaced the old PSC page on the web site with the new charter:
Thank you all for the many useful hints, tips and suggestions I regularly receive on how to make things smoother within the project (keep them coming!) – hopefully we will get into a steady routine with this governance now. We have been going through a lot of ramp up trying to get templates, processes, etc in place as we switch over to QGIS.ORG legal entity etc. We appreciate your patience while we figure things out – and a very big thank you to Andreas Neumann and Anita Graser who have pitched in with a lot of administrative work behind the scenes to help get the QGIS legal entity in place!
What’s next? I will be starting the nomination process for 4 new community voting members, soon (one to match each of the incoming country user groups for Norway, Sweden, South Africa and France). At the end of that process we will have 31 voting members.
Soon QGIS.ORG will be in the Swiss Trade Registry, which means we can be VAT registered, can take ownership of the QGIS.ORG trademark (which is currently held in proxy for us) and of course present ourselves as a well governed project, hopefully attractive to large funders who recognize the global good a project like QGIS does!
Regards
timsutton
Tim Sutton
QGIS Project Steering Committee Chair

Essen 2017 QGIS Hackfest

Another great QGIS hackfest is gone, and it’s time for a quick report.

The location has been the Linux Hotel, one of the best places where open source developers could meet, friendly, geek-oriented and when the weather is good, like this time, villa Vogelsang is a wonderful place to have a beer in the garden while talking about software development or life in general.

This is a short list of what kept me busy during the hackfest:

  • fixed some bugs and feature requests on the official QGIS plugin repo that I’m maintaining since the very beginning
  • make the QGIS official plugin repository website mobile-friendly
  • QGIS Server Python Plugin API refactoring, I’ve completed the work on the new API, thanks to the ongoing server refactoring it’s now much cleaner than it was in the first version
  • attribute table bugs: I started to address some nasty bugs in the attribute table, some of those were fixed during the week right after the hackfest
  • unified add layer button, we had a productive meeting where we decided the path forward to implement this feature, thanks to Boundless that is funding the development, this feature is what’s I’m currently working on these days

Thanks to all QGIS donors and funders that made yet another great hackfest possible and in particular to Boundless Spatial Inc. for funding my personal expenses.

 

 

QGIS Composer Rewrite and Layout Engine crowdfund – half way there!

If you’ve been following our recent blog posts, you’ll be aware that we are currently running a crowd funding campaign to extend the capabilities of QGIS’ print composer. You can read full details about this over at the campaign page.

The good news is that we’ve just hit the mid way point of the funds! Many generous backers have stepped up with contributions and we’re well on the way to reaching the funding goal. However, we still need your help make this work a reality.

Right now, what we need most is interested users and community members who will reach out to their local QGIS users and seek more backing for the campaign. We need to publicise the campaign beyond the regular online QGIS community, to the thousands of enterprises and organisations which rely on QGIS for their daily mapping operations. We need community members who can get in contact with these organisations and help convince them that investing back into the open source software they utilise is beneficial (and often will even SAVE them money in the long run, due to the increased productivity that changes like our composer improvements will bring!).

So, while social media reshares have been vital to reaching the current stage, we now need more “hands on” helpers who will take this on. If you know of any organisations which depend on QGIS for their mapping outputs, now’s the time to get in contact with them directly and advise them of this campaign!

 

 

 

Movement data in GIS #6: updates from AGILE2017

AGILE 2017 is the annual international conference on Geographic Information Science of the Association of Geographic Information Laboratories in Europe (AGILE) which was established in 1998 to promote academic teaching and research on GIS.

This years conference in Wageningen was my time at AGILE.  I had the honor to present our recent work on pedestrian navigation with landmarks [Graser, 2017].

If you are interested in trying it, there is an online demo. The conference also provided numerous pointers toward ideas for future improvements, including [Götze and Boye, 2016] and [Du et al., 2017]

On the issue of movement data in GIS, there weren’t too many talks on this topic at AGILE but on the conceptual side, I really enjoyed David Jonietz’ talk on how to describe trajectory processing steps:

Source: [Jonietz and Bucher, 2017]

In the pre-conference workshop I attended, there was also an interesting presentation on analyzing trajectory data with PostGIS by Phd candidate Meihan Jin.

I’m also looking forward to reading [Wiratma et al., 2017] “On Measures for Groups of Trajectories” because I think that the presentation only scratched the surface.

References

[Du et al, 2017] Du, S., Wang, X., Feng, C. C., & Zhang, X. (2017). Classifying natural-language spatial relation terms with random forest algorithm. International Journal of Geographical Information Science, 31(3), 542-568.
[Götze and Boye, 2016] Götze, J., & Boye, J. (2016). Learning landmark salience models from users’ route instructions. Journal of Location Based Services, 10(1), 47-63.
[Graser, 2017] Graser, A. (2017). Towards landmark-based instructions for pedestrian navigation systems using OpenStreetMap, AGILE2017, Wageningen, Netherlands.
[Jonietz and Bucher, 2017] Jonietz, D., Bucher, D. (2017). Towards an Analytical Framework for Enriching Movement Trajectories with Spatio-Temporal Context Data, AGILE2017, Wageningen, Netherlands.
[Wiratma et al., 2017] Wiratma L., van Kreveld M., Löffler M. (2017) On Measures for Groups of Trajectories. In: Bregt A., Sarjakoski T., van Lammeren R., Rip F. (eds) Societal Geo-innovation. GIScience 2017. Lecture Notes in Geoinformation and Cartography. Springer, Cham


The Inaugural QGIS Australia Hackfest – Noosa 2017

Last week we kicked off the first (of hopefully many) Australian QGIS hackfests Developers Meetings. It was attended by 3 of the core QGIS development team: Nathan Woodrow, Martin Dobias and myself (Nyall Dawson), along with various family members. While there’s been QGIS hackfests in Europe for over 10 years, and others scattered throughout various countries (I think there was a Japanese one recently… but Twitter’s translate tool leaves me with little confidence about this!), there’s been no events like this in the Southern hemisphere yet. I’ve been to a couple in Europe and found them to be a great way to build involvement in the project, for both developers and non-developers alike.

In truth the Australian hackfest plans began mostly an excuse for Nathan and I to catch up with Martin Dobias before he heads back out of this hemisphere and returns to Europe. That said, Nathan and I have long spoken about ways we can build up the QGIS community in Australia, so in many ways this was a trial run for future events. It was based it in Noosa, QLD (and yes, we did manage to tear ourselves away from our screens long enough to visit the beach!).

Nathan Woodrow (@NathanW2), myself (@nyalldawson), and Martin Dobias (@wonder-sk)

Here’s a short summary of what we worked on during the hackfest:

  • Martin implemented a new iterator style accessor for vertices within geometries. The current approach to accessing vertices in QGIS is far from optimal. You either have the choice of an inefficient methods (eg QgsGeometry.asPolyline(), asPolygon(), etc) which requires translations of all vertices to a different data structure (losing any z/m dimensional values in the process), or an equally inefficient QgsAbstractGeometry.coordinateSequence() method, which at least keeps z/m values but still requires expensive copies of every vertex in the geometry. For QGIS 3.0 we’ve made a huge focus on optimising geometry operations and vertex access is one of the largest performance killers remaining in the QGIS code. Martin’s work adds a proper iterator for the vertices within a geometry object, both avoiding all these expensive copies and also simplifying the API for plugins. When this work lands traversing the vertices will become as simple as
for v in geom.vertices():
   ... do something with the vertex!
  • Martin is also planning on extending this work to allow simple iteration over the parts and rings within geometries too. When this lands in QGIS we can expect to see much faster geometry operations.
  • Nathan fixed a long standing hassle with running standalone PyQGIS scripts outside of the QGIS application on Windows. In earlier versions there’s a LOT of batch file mangling and environment variable juggling required before you can safely import the qgis libraries within Python. Thanks to Nathan’s work, in QGIS 3.0 this will be as simple as just making sure that the QGIS python libraries are included in your Python path, and then importing qgis.core/gui etc will work without any need to create environment variables for OSGEO/GDAL/PLUGINS/etc. Anyone who has fought with this in the past will definitely appreciate this change, and users of Python IDEs will also appreciate how simple it is now to make the PyQGIS libraries available in these environments.
  • Nathan also worked on “profiles” support for QGIS 3.0. This work will add isolated user profiles within QGIS, similar to how Chrome handles this. Each profile has it’s own separate set of settings, plugins, etc. This work is designed to benefit both plugin developers and QGIS users within enterprise environments. You can read more about what Nathan has planned for this here.
  • I continued the ongoing work of moving long running interface “blocking” operations to background tasks. In QGIS 3.0 many of these tasks churn away in the background, allowing you to continue work while the operation completes. It’s been implemented so far for vector and raster layer saving, map exports to images/PDF (not composers unfortunately), and obtaining feature counts within legends. During the hackfest I moved the layer import which occurs when you drag and drop a layer to a destination in the browser to a background task.
  • On the same topic, I took some inspiration from a commit in Sourcepole’s QGIS fork and reworked how composer maps are cached. One of my biggest gripes with QGIS’ composer is how slow it is to work with when you’ve got a complex map included. This change pushes the map redrawing into a background thread, so that these redraws no longer “lock up” the UI. It makes a HUGE difference in how usable composer is. This improvement also allowed me to remove those confusing map item “modes” (Cache/Render/Rectangle) – now everything is redrawn silently in the background whenever required.
  • Lastly, I spent a lot of time on a fun feature I’ve long wanted in QGIS – a unified search “locator” bar. This feature is heavily inspired by Qt Creator’s locator bar. It sits away down in the status bar, and entering any text here fires up a bunch of background search tasks. Inbuilt searches include searching the layers within the current project (am I the only one who loses layers in the tree in complex projects!?), print layouts in the project, processing algorithms, and menu/toolbar actions. The intention here is that plugins will “take over” and add additional search functionality, such as OSM place names searching, data catalog searches, etc. I’m sure when QGIS 3.0 is released this will quickly become indispensable!

The upcoming QGIS 3.0 locator bar

Big thanks go out to Nathan’s wife, Stacey, who organized most of the event and without whom it probably would never have happened, and to Lutra Consulting who sponsored an awesome dinner for the attendees.

We’d love this to be the first of many. The mature European hackfests are attended by a huge swath of the community, including translators, documentation writers, and plugin developers (amongst others). If you’ve ever been interested in finding out how you can get more involved in the project it’s a great way to dive in and start contributing. There’s many QGIS users in this part of the world and we really want to encourage a community of contributors who “give back” to the project. So let Nathan or myself know if you’d be interested in attending other events like this, or helping to organize them locally yourself…

More QGIS 3.0 Improvements: Saving Map Canvas as Image & PDF

(This blog post might as well have been titled “QGIS ❤ Wallpapers”)

Over the span of a week, QGIS received a set of improvements which greatly improved the canvas’ save as image function, as well as a brand new save as PDF feature.

Queue the usual slide of improvements: Improvements ovewview

Adding output resolution, width and height settings effectively frees users from the confine of their physical screen. Being able to fine tine the width and height in pixel also helps cartographers producing maps best-fitted for web-based content.

Saving as PDF feature is a real time saver, offering a fast path to vector export of maps without the need to go through creating a composer, adding a map item, etc.

All of these improvements are very useful to improve quick n’ dirty map export. It is however no replacement to the powerful QGIS composers. On that front, a QGIS core developer at North Road has launched a crowd funding campaign to modernize composers. For those cartographers out there publishing maps on various media forms (print, online, ebooks), seriously consider supporting this campaign.

GRASS GIS 7.2.1 released

We are pleased to announce the update release GRASS GIS 7.2.1

GRASS GIS 7.2.1 in actionWhat’s new in a nutshell

After four months of development the new update release GRASS GIS 7.2.1 is available. It provides more than 150 stability fixes and manual improvements compared to the first stable release version 7.2.0. An overview of new features in this release series is available at New Features in GRASS GIS 7.2.

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

Binaries/Installer download:

Source code download:

More details:

See also our detailed announcement:

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, May 2017

The post GRASS GIS 7.2.1 released appeared first on GFOSS Blog | GRASS GIS Courses.

Best practices for writing Python QGIS Expression Functions

Recently there have been some questions and discussions about python based expression functions and how parameters like [crayon-595402d3ddc3f729058887-i/]  need to be used. So I thought I’d quickly write down how this works. There is some intelligence If the geometry or a

QGIS Expressions Engine: Performance boost

Expressions in QGIS are more and more widely used for all kinds of purposes. For example the recently introduced geometry generators allow drawing awesome effects with modified feature geometries on the fly. The last days at the QGIS developer meeting

Report from the Essen dev meeting

From 28th April to 1st May the QGIS project organized another successful developer meeting at the Linuxhotel in Essen, Germany. Here is a quick summary of the key topics I’ve been working on during these days.

New logo rollout

It’s time to get the QGIS 3 logo out there! We’ve started changing our social media profile pictures and Website headers to the new design: 

Resource sharing platform 

In QGIS 3, the resource sharing platform will be available by default – just like the plugin manager is today in QGIS 2. We are constantly looking for people to share their mapping resources with the community. During this developer meeting Paolo Cavallini and I added two more SVG collections:

Road sign SVGs by Bertrand Bouteilles & Roulex_45 (CC BY-SA 3.0)

SVGs by Yury Ryabov & Pavel Sergeev (CC-BY 3.0)

Unified Add Layer button

We also discussed the unified add layer dialog and are optimistic that it will make its way into 3.0. The required effort for a first version is currently being estimated by the developers at Boundless.

TimeManager

The new TimeManager version 2.4 fixes a couple of issues related to window resizing and display on HiDPI screens. Additionally, it now saves all label settings in the project file. This is the change log:

- Fixed #222: hide label if TimeManager is turned off
- Fixed #156: copy parent style to interpolation layer
- Fixed #109: save label settings in project
- Fixed window resizing issues in label options gui
- Fixed window resizing issues in video export gui
- Fixed HiDPI issues with arch gui

Call for presentations and workshop proposals: QGIS Conference 2017

NOTE: Deadline for proposals is May 15 2017

We are going back to Nødebo! Each year we combine one of our QGIS Developer Meetings with a User Conference. The User Conference is a great opportunity for QGIS users to meet developers and share their experiences – both with developers and with other users. Our first ever User Conference was held in Nødebo, Denmark in 2015 and we are thrilled to be going back to the beautiful venue at the University of Denmark’s Forest and Landscape College.

1k0a4924

The user conference will be combined with the QGIS Developer Meeting and a summer school event, with the first week being focussed on the User Conference, the intermediate weekend on the QGIS Hackfest and the second week on the Summer School. The event will run from the 2nd of August through to the 11th of August 2017.

We would like to invite those who are interested in presenting a talk to apply now (NOTE: Deadline for proposals is May 15 2017). There are four kinds of contributions you can make (see the conference website for full details):

  • 20 minute ‘lightning’ talks
  • 1-2 hour short workshops
  • half and full day workshops
  • posters (which should be presented in the form of a map)

We have identified a number of themes for the User Conference:

  • QGIS Software Development
  • New Technology
  • Business
  • Government/Municipality
  • Science
  • Education

Presenters of full day workshops are eligible for a EUR 1000 reimbursement to offset their costs. You can find out more details at the conference web page (as well as registering your talk / presentation):

https://qgis2017.wordpress.com/presentations/

We are looking forward to seeing a great programme come together for the conference!

 

 

 


QGIS Grant Programme #2 Results

We are extremely pleased to announce the winning proposals for our 2017 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsorsNote: For more context surrounding our grant programme, please see:

Our intent with the QGIS.ORG Grant Programme is to support work from community that would typically not be funded by client/contractor agreements, and that contributes to the broadest possible swathe of our community by providing cross-cutting, foundational improvements to the QGIS Project.

Voting to select the successful projects was carried out by our QGIS Voting Membership. Each voting member was allowed to select up to 6 of the 13 submitted proposals by means of a ranked selection form. The full list of votes are available here (on the first sheet). The second sheet contains the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

Screen Shot 2017-04-30 at 3.23.08 PM

A couple of extra notes about the voting process:

  • The PSC has an ongoing program to fund documentation so elected to fund the processing documentation work separately from the grant programme (note *1).
  • Voting was carried out based on the technical merits of the proposals and the competency of the applicants to execute on these proposals.
  • No restrictions were in place in terms of how many proposals could be submitted per person / organization, or how many proposals could be awarded to each proposing person / organization.
  • Because of the importance of having good packaging systems on each of the three major platforms, the PSC elected to additionally fund the work on MacOS bundling scripts (note *2).
  • Although the budget for the grant programme was €20,000.00, the total amount for the four winning proposals is €19,800.00, with an additional €5, 800.00 being made available to support the processing work and and MacOS packaging work.
  • Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We had great participation in the voting process. Of the 27 voting members, 23 registered their votes.

Screen Shot 2017-04-20 at 4.11.45 PM
On behalf of the QGIS.ORG project, I would really like to thank everyone who submitted proposals for this call. There were many interesting proposals that I believe would be of great benefit to QGIS and I hope others perusing the proposals list will use their initiative and funding interesting proposals independently if they can.

Below you can find the detailed proposals of the successful applications – we look forward to seeing the results of their work land in the code base soon!

Details of the approved grant proposals


9 ADD CONSISTENCY TO UI CONTROLS

Proposer: Nyall Dawson

Amount: €1800

Details: Across the QGIS UI, numerous inconsistencies exist in the way different properties like opacity and rotation are exposed to users. These inconsistencies make QGIS harder to use, as behavior from one dialog differs to the behavior in another dialog. Some examples of this include:

  • Rotation of labels is done in the opposite direction in labeling to symbology. Accordingly, an equal rotation value will result in different rotation between labels and symbols.
  • Scales are inconsistently presented, with use of both the scale numerator and denominator in different dialogs. “Minimum” and “Maximum” scales also vary between dialogs, with some dialogs using “minimum” scale as the largest scale and some using “minimum” as the smallest scale. The labeling scale based visibility controls are the biggest offenders here.
  • Controls vary between specifying “opacity”, “transparency” and “alpha”. While these all have similar results, users must adopt values to map “opacity” to “transparency” in different dialogs. This is further compounded by different ranges used for each (eg 0-100%, or 0-255).

Due to the usual API freeze, it has not been possible to fix these discrepancies. The current API break introduced with version 3.0 allow a window for addressing these issues and standardizing behavior and API.

Despite the benefits in providing a consistent UI, the work involved in standardizing is fiddly (careful attention must be paid to not breaking existing projects) and repetitive, and unlikely to be undertaken by developers on a volunteer basis.  Furthermore it is highly unlikely that a commercial organisation could justify sponsoring UI standardisation efforts. Without grant funding it is unlikely that these issues will be addressed during the 3.0 development cycle, and the inconsistencies would remain for the lifetime of QGIS 3.x.

In this proposal I will:

  • convert all “transparency” controls to “opacity” controls, and consult with the community to determine the ideal value range presented (0-100% or 0-255) before making all opacity controls use the same range.
  • Ensure that rotation always operates in the same direction.
  • Fix the labeling scale ranges to use the same scale range definitions as layer visibility
  • As much as possible, automatically upgrade existing projects so that they open in QGIS 3.0 without any loss of transparency/rotation/scale settings
  • (As much as possible without large refactoring), adapt the PyQGIS API so for consistent naming and use of opacity/rotation and scale setting/getting methods. Making the API consistent makes scripting QGIS and writing plugins easier.

This proposal relates to the issues described at:

History: No work has currently been undertaken in this regard.

Qualifications: I am currently one of the most active QGIS developers, with a long history of quality contributions to the project. I’m passionate about seeing QGIS 3.0 address these kinds of long standing UI issues which detract from QGIS’ otherwise professional image and ease of use.

Implementation Plan:  The work will be undertaken prior to the QGIS 3.0 feature freeze period.

Proposal Link:


3 EXTEND UNIT TEST COVERAGE FOR GEOMETRY CLASSES

Proposer: Nyall Dawson

Amount: €2000

Details: Since QGIS 2.8, there has been an increased focused on creation of quality automated regression (“unit”) tests designed to flag issues in code before the code is introduced to the QGIS codebase. The increase in stability of recent QGIS versions can be directly attributed to this growth in unit testing. Despite this, many areas of the QGIS codebase remain with little or no unit test coverage.

One critical area which has insufficient unit tests is the geometry classes. The geometry classes form the basis of all geometry interpretation, algorithms, and rendering within QGIS. In order to provide stable QGIS releases, it is crucial that these fundamental classes are rock-solid, efficient, and do not suffer regressions between releases.

Some years ago (shortly after the introduction of the new geometry engine, in which support for Z/M values and curved geometries was added) I added full test coverage for the Point and Linestring classes, and partial coverage for the Polygon class. Unfortunately, writing geometry tests is tricky and time consuming. There’s many corner cases with unusual or invalid geometries which need to be tested. The time commitment required prevented me from writing additional tests, and to date the remaining classes (including multi geometries and all curved geometry types) have little or no test coverage.

This proposal covers writing additional unit tests to cover all the remaining geometry classes.

It is important to note that unit tests do NOT ensure bug free software. Unit tests only protect existing logic and avoid regressions when the covered parts of the code base are changed in future releases. Despite this disclaimer, the process of creating unit tests usually stress-tests existing code and in itself CAN reveal existing bugs. This was certainly the case when the existing tests for Point and Linestring classes were added – creation of the tests alone resulted in many fixed bugs and stabler Point and Linestring geometry handling.

History: This work would continue on from work I begun a number of years ago to provide 100% unit test coverage for the base geometry classes.

Qualifications: I have a long history of quality contributions to the QGIS project, and am currently one of the most prolific committers to the QGIS codebase. I have a long history with adding unit tests to QGIS and advocating for their increased usage amongst developers.

Implementation Plan: This work would be targeted to the QGIS 3.0 release, and would be committed to the codebase prior to the feature freeze/bug fixing period leading up to the 3.0 release.

Proposal Link:


8 QGIS 3D

Proposer: Martin Dobias

Amount: €10000

Details: I would like to propose a project that introduces 3D rendering capabilities in QGIS.
To summarize the planned work, the following features can be expected:

  • 2D view of map canvas rendered on the graphics hardware (GPU) allowing smooth zooming and panning of map view
  • 3D perspective view of the map
  • generation of 3D terrain model from DEM (digital elevation model) layers
  • map layers rendered as a texture on top of the 3D terrain
  • support for true 3D rendering of vector layers rather than having just flat appearance
  • map view widget that is dockable in the main window and synchronized with the main map canvas
  • support for picking (identification) of objects in 3D view and X/Y/Z coordinate display
  • support for 3D map view in map composer

The overall target is to introduce an extensible framework for 3D map view within QGIS, so that in the future developers can add various 3D rendering techniques for map data, using custom geometries and materials (which may involve writing own vertex/fragment shaders), possibly even allowing multi-pass rendering for advanced effects (e.g. to render shadows cast by buildings with a particular sun position).
3D support in QGIS is not only about adding the extra dimension to the rendering: it is also about making it possible to use graphics hardware for rendering of map in 2D – making map browsing even more pleasant and faster at the same time. Rendering 2D maps with OpenGL also opens the door to various new graphical effects that would be otherwise very expensive

to achieve by using just CPU for map rendering.
This proposal does not assume addition of new geometry types like polyhedral surface (with read support for those) into QGIS – the aim of the work is to get 3D rendering engine running and new geometry types may be added at some point later.

State of the art

QGIS features very good 2D rendering capabilities, however its 3D support has been very limited. Prior work on 3D in QGIS includes:

  • Globe plugin – a C++ plugin developed by Matthias Kuhn and Sourcepole based on OpenSceneGraph and osgEarth libraries. OpenSceneGraph is a generic toolkit that provides higher-level abstraction on top of OpenGL, making it easier to develop 3D applications than directly using low-level OpenGL interfaces.OsgEarth project then builds on top of OpenSceneGraph and provides a toolkit for working with geographical data: it has a terrain engine that combines elevation layers into a terrain, applies textures from “image” layers and adds feature layers with true 3D objects.The plugin acts as a bridge from QGIS environment and feeds scene data into osgEarth to do the 3D rendering.
  • Qgis2threejs plugin – a Python plugin developed by Minoru Akagi. It is able to export QGIS project (with various configuration options) into a HTML page that uses three.js library to render map in 3D within web browser using WebGL.
  • Horao – developed by Oslandia. It is a standalone 3D viewer based on OpenSceneGraph that may be controlled by a QGIS plugin to display map from QGIS in 3D environment. It has explicit support for true 3D geometries in PostGIS.

While these projects solve some use cases for 3D rendering of map data, each of them have their own limitations. For example, osgEarth library used by Globe plugin has its own data access and rendering of vector features implementation, duplicating QGIS code and not having parity in their capabilities. Moreover it has been difficult over time to keep the build working on all platforms supported by QGIS. The main limitation of Qgis2threejs plugin is the fact that the 3D view is exported to web browser, so the user cannot use benefits of having 3D view tightly integrated with the rest of QGIS. The fact that Horao has a standalone viewer

application results in similar limitations as when using Qgis2threejs (although it has some degree of integration with QGIS application).

Proposed approach
Now that QGIS 3.0 is based on Qt5, we can use some of the great new functionality added recent releases of Qt5. In version 5.5, a new framework for working 3D graphics has been introduced and every major Qt5 release since has been adding more functionality, improving performance, compatibility and stability. The 3D support nicely integrates with the rest of the Qt framework, providing a familiar API and at the same time staying very generic and highly efficient.
The 3D framework provides high level abstractions just like other libraries (e.g. OpenSceneGraph, three.js). 3D scene is built with nodes (called entities) with various components (e.g. transformation, mesh, material).
The idea is to build 3D support in QGIS on top of the Qt 3D framework. From my initial tests of the framework this looks feasible and it will allow us to stick with Qt APIs without requiring extra dependencies.
The work can be divided into the following chunks of work:

  1. Rendering engine core: develop a framework that will do rendering of the map scene in 3D. The engine will have the responsibility of processing raster layers with elevation into a mesh geometry and texturing the mesh with map images rendered by the existing QGIS 2D rendering engine. The engine will support levels of detail (LOD) and tiling in order to be able to display high-resolution data in real time without having to load all the data into memory at the time of scene creation (which may be prohibitively expensive with more complex layers). 3D scene will be dynamically updated as user browses the map, keeping the amount of rendered triangles low while appropriate quality of the terrain for given zoom level.

All of the processing needs to be done in the background, so the user may freely browse the map and the scene will be continuously updated with data (changing between higher/lower detail when zooming, loading more data when moving map).

  1. Handling of user input: controller for camera that will make the camera fly on top of the map. Support for picking will be added to allow identification of objects in the map and display of coordinates at the mouse position.
  1. Integration with QGIS environment: dockable 3D map widget for the main window, synchronization with 2D map canvas, support for printing of 3D views in map compositions.
  1. Advanced 3D rendering techniques: interface that will allow adding new methods for data visualization in 3D and exploration of methods for rendering. By default map layers will be rendered into map image with the existing 2D map renderer – this interface will allow map layers to instead have 3D renderer associated which will provide entities with custom meshes and materials. As a result we will be able to achieve true 3D appearance of objects (e.g. point clouds, trees as 3D models, tesselation of polygons, buildings with extruded geometry and custom texture). Implementation of the advanced techniques is a task with nearly unlimited scope, so the idea is to develop a suitable interface and as the time will allow, implement some techniques.

History: For this proposal I have studied various sources:

  • looked into existing 3D viewer projects related to QGIS
  • explored Qt 3D framework
  • researched some academic papers regarding terrain generation and vector data display

As a proof of concept, I have created a simple prototype in C++ using Qt 3D framework. It displays aerial imagery on top of a terrain model created from a raster layer (DEM) and allows simple camera control. The code is available here: https://github.com/wonder-sk/qgis3d

Qualifications: I have been a core QGIS developer for more than 10 years and I have a very good knowledge of QGIS codebase, especially the existing 2D map rendering pipeline.
Previously when working at the university, on a project for stereo matching (creation of point cloud out of a pair of images) I worked on visualization of 3D data using OpenGL.
Implementation Plan: The plan is to work on the project between May and July 2017. As of now, the plan for QGIS releases (according to the mail from Paolo) is that QGIS 3.0 will have feature freeze in July 2017 and final release in September 2017. If nothing changes in the QGIS release schedule in meanwhile, the 3D support could be integrated into QGIS master branch before the feature freeze and thus released in QGIS 3.0.
If the project would be accepted, the first step will be to develop a prototype of the 3D rendering engine, then prepare a more detailed architecture proposal as a QEP and continue the implementation once the QEP gets accepted by the community. The work progress should be available on a branch in GitHub for anyone interested.
Proposal Link: https://github.com/wonder-sk/qgis3d



6 PROCESSING ALGORITHM DOCUMENTATION

Proposers: Matteo Ghetta, Alexander Bruy

Amount: €4000

Details: This proposal aims to improve the existing Processing algorithms documentation. With the pull request https://github.com/qgis/QGIS/pull/3911 it is possible to add external links for the documentation (both local and remotes). However the effective use of the pull request is not yet included in Processing.

With this proposal the existing code will be incorporated in Processing, allowing to have a Short Help tab (the existing one on the right of the Processing algorithm window) and a Long Help tab (next to the Log tab).

The Short Help tab will be collapsible in order to have a bigger window for the algorithm parameters, while the Long Help tab will point to the on-line existing documentation of Processing for each algorithm (http://docs.qgis.org/testing/en/docs/user_manual/processing_algs/index.html).

The default link of the on-line documentation will be added in the QGIS Settings (thanks to the pull request already merged) in order to have the standard documentation visible but to let the user the choice to overwrite it and load custom paths.

In addition to the code part, this proposal aims also to document the GDAL/OGR provider and the QGIS core algorithms. Existing documentation will be reviewed and pictures will be added when useful, while for algorithm not yet documented, the help will be written from scratch with description and additional pictures.

Currently there are:

  • 49 GDAL/OGR total algorithms, 35 to enhance with pictures, 14 to write from scratch
  • 154 QGIS algorithms, 38 to enhance, 116 to write from scratch

This means a total of 73 algorithm to enhance and 130 to write from scratch.

History: The pull request https://github.com/qgis/QGIS/pull/3911 is already merged and it is worth to make it effective to have nice, rich and translatable documentation for the Processing algorithms.

Qualifications: Matteo Ghetta: working since the release 2.0 on the documentation and made several improvements and pull request to both documentation and Processing code.

Alexander Bruy: core developer since 2010, co-maintainer of the QGIS Processing framework.

Implementation Plan: The code and the documentation will be ready for the QGIS 3 release.

Proposal Link:


5 IMPROVE DEEP RELATIONS WITH POSTGRES EDITING

Proposer: Régis Haubourg

Amount: €6000

Details: QGIS has reached a mature level and offers now a very good framework to create professional applications. One of the main reasons is that QGIS is a very strong client for spatial databases, and in particular with PostgreSQL and postGIS for which it was initially created.

Since version 2.14, QGIS offers the not-so-well-known ability to handle transaction groups, which means it can instantly evaluate triggers on database side, and refresh all layers in the same transaction. This is a big win for usability, but some drawbacks glitches remain, such as the lack of the undo/redo edit buffer, a very raw way of saving (ie quitting edition session) or having the legend cluttered by so many edit symbols (a pen symbol). Current proposal is to go a step beyond to make QGIS even better for PostgreSQL by achieving the following targets:

1 Restore an undo /redo feature by taking advantage of PostgreSQL. If possible we will try to take advantage of PostgreSQL named Savepoints.

2 Allow to have some layers not switching to edit mode in QGIS,  even if they belong to the same connection. These layers will still benefit from the instant refresh, but won’t clutter the legend with the edit pen symbol everywhere, nor risk to load QGIS snapping cache for nothing. A UI for those settings could be an evolution of the current “identify layer” list in the project properties.

3 We would like to submit a mechanism to allow converting error messages raised by the provider, like a RAISE from postgres, into custom user oriented message. Say for instance, instead of a “provider error – duplicate key for… “, QGIS project could be tuned to display first “You tried to insert a feature using the same identifier as another one”.

The error message list and regexp rules would be optionally stored in qgis project or read from a datasource table (for instance when error messages rewrites are shared by other applications). The original error message would be still avaiblable by expanding the details of the messageBar and in the general message log.

4 Cherry on cake point, we wish to have QGIS take advantage of PostgreSQL NOTIFY signals to trigger behavior in QGIS when something changes in the database (see https://www.postgresql.org/docs/9.5/static/sql-notify.html) . A first implementation proposal is to allow a map canvas refresh, but we can imagine really dynamic applications driven by the database events by converting NOTIFY messages into QGIS signals (oh yeah!).

History: In our team, we already use transaction groups for production tools and that is much appreciated. We already use some python logic to catch error message and convert them to more user oriented ones. We frequently develop applications where QGIS is linked with heavy database containing most of the intelligence. Having a really interactive edition process, speaking the same langage as average users, and being able to be triggered from database process will unleashed many possible applications.

Qualifications: Oslandia has three QGIS developers, two of them being core comiters and high  skills with Postgres and Postgis (core comiter too). We believe that developing using thick databases is a major strength of QGIS, and we have great fun getting involved in that area of the code 😉

Implementation Plan:  We currently are quite involved in QGIS 3 server refactoring and major changes such as Auxiliary Storage for project or core solutions for label connectors. We also are involved in applications build on top of QGIS for Water management like QWAT or QGEP. Such changes would benefit immediatly to those project. Our target is to provide those improvements with all necessary unit tests for 3.0 release.

Proposal Link: coming soon..


 

13 UPDATE MACOS CMAKE BUNDLING SCRIPTS

 

Proposer: Larry Shaffer

 

Amount: €1800

 

Details: Currently, the macOS bundling routines (to create a self-contained QGIS.app application) in CMake scripts where created by William Kyngsburye many years ago. Since then, CMake has added many features for bundling, e.g. BundleUtilities ( https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html), that handle similar functionality to what has been arduously maintained in the CMake scripts. While the current setup does function, it is quite antiquated and adding any new QGIS dependencies to be bundled is an error-prone ordeal. I propose to fully update the bundling routines to leverage modern CMake capabilities, since building on macOS usually uses the latest CMake versions. Once completed, anyone with appropriate dependencies should be able to produce a production-ready QGIS.app bundle, including the QGIS project itself.

 

History: I will first build upon the existing work to ensure there is a minimal bundled QGIS.app, then completely refactor the same functionality using a modern CMake code workflow.

 

Qualifications: I have extensive knowledge in CMake and frequently utilize it in my work for my employer, Boundless Spatial. I have already completed a fully bundled QGIS.app distribution by my employer (similar to the first phase of the proposed work here), though Boundless now uses a different installation approach. I have been working for years on the OSGeo4Mac project in anticipation of producing better CMake bundling routines, to ensure the QGIS project can independently produce its own macOS distributions.

 

Implementation Plan: Basic work will follow these steps:

  • Append minimal bundling to existing CMake setup, so there is a least a functioning bundling routine, regardless of whether the proposed work is accomplished in time for the major next release.
  • Ensure the QGIS.app bundle is code-signed
  • Create a new methodology, based upon CMake’s BundlesUtilities, *in-line* next to the existing CMake routines, so both can be used, until there is a valid replacement.
  • Focus on minimal bundling, then add GRASS
  • Continue extending bundling routines to include major Processing providers, e.g. OTB, Saga, TauDEM, etc.
  • Ensure new method’s QGIS.app is properly code-signed
  • Enable bundling on Travis CI infrastructure, via Travis’ cron jobs, thereby adding the capability for the QGIS project to produce fully bundled nightlies of macOS builds.
  • Once new method represents a full replacement, old method will be removed, not just deprecated

 

Intended completion is in time for QGIS 3.0 release and packaging efforts.

 

Since the new method does not affect any existing code, as soon as useable functionality is achieved, it will be merged directly into master, then further code committed as work progresses.

Proposal Link: None at this time. Should I consider a QEP? Not many developers beyond the few existing packagers and experimenters would be involved. I would prefer to write a blog post after the work is completed, though post to the QGIS dev mailing list the intention to do the work, if this proposal is granted.


  • Page 1 of 91 ( 1812 posts )
  • >>

Back to Top

Sponsors