Last update:
Sun Dec 22 04:30:26 2024
•
•
•
•
The GRASS GIS 8.4.0RC1 release provides more than 515 improvements and fixes with respect to the release 8.3.2. Please support us in testing this release candidate.
The post GRASS GIS 8.4.0RC1 released appeared first on Markus Neteler Consulting.
The GRASS GIS 8.4.0 release provides more than 520 improvements and fixes with respect to the release 8.3.2.
The post GRASS GIS 8.4.0 released appeared first on Markus Neteler Consulting.
The GRASS GIS 8.3.2 maintenance release contains more than 30 changes compared to 8.3.1. This new patch release includes important fixes and improvements to the GRASS GIS modules and the graphical user interface (GUI), making it even more stable for daily work.
The post GRASS GIS 8.3.2 released appeared first on Markus Neteler Consulting.
According to the definition of software quality given by french Wikipedia
An overall assessment of quality takes into account external factors, directly observable by the user, as well as internal factors, observable by engineers during code reviews or maintenance work.
I have chosen in this article to only talk about the latter. The quality of software and more precisely QGIS is therefore not limited to what is described here. There is still much to say about:
These are subjects that we care a lot and deserve their own article.
I will focus here on the following issue: QGIS is free software and allows anyone with the necessary skills to modify the software. But how can we ensure that the multiple proposals for modifications to the software contribute to its improvement and do not harm its future maintenance?
All developers contributing to QGIS code doesn’t belong to the same organization. They don’t all live in the same country, don’t necessarily have the same culture and don’t necessarily share the same interests or ambitions for the software. However, they share the awareness of modifying a common good and the desire to take care of it.
This awareness transcends professional awareness, the developer not only has a responsibility towards his employer, but also towards the entire community of users and contributors to the software.
This self-discipline is the foundation of the quality of the contributions of software like QGIS.
However, to err is human and it is essential to carry out checks for each modification proposal.
With each modification proposal (called Pull Request or Merge Request), the QGIS GitHub platform automatically launches a set of automatic checks.
Example of proposed modification
Result of automatic checks on a modification proposal
The first of these checks is to build QGIS on the different systems on which it is distributed (Linux, Windows, MacOS) by integrating the proposed modification. It is inconceivable to integrate a modification that would prevent the application from being built on one of these systems.
The first problem posed by a proposed modification is the following “How can we be sure that what is going to be introduced does not break what already exists?”
To validate this assertion, we rely on automatic tests. This is a set of micro-programs called tests, which only purpose is to validate that part of the application behaves as expected. For example, there is a test which validates that when the user adds an entry in a data layer, then this entry is then present in the data layer. If a modification were to break this behavior, then the test would fail and the proposal would be rejected (or more likely corrected).
This makes it possible in particular to avoid regressions (they are very often called non-regression tests) and also to qualify the expected behavior.
There are approximately 1.3 Million lines of code for the QGIS application and 420K lines of test code, a ratio of 1 to 3. The presence of tests is mandatory for adding functionality, therefore the quantity of test code increases with the quantity of application code.
In blue the number of lines of code in QGIS, in red the number of lines of tests
There are currently over 900 groups of automatic tests in QGIS, most of which run in less than 2 seconds, for a total execution time of around 30 minutes.
We also see that certain parts of the QGIS code – the most recent – are better covered by the tests than other older ones. Developers are gradually working to improve this situation to reduce technical debt.
Analogous to using a spell checker when writing a document, we carry out a set of quality checks on the source code. We check, for example, that the proposed modification does not contain misspelled words or “banned” words, that the API documentation has been correctly written or that the modified code respects certain formal rules of the programming language.
We recently had the opportunity to add a check based on the clang-tidy tool. The latter relies on the Clang compiler. It is capable of detecting programming errors by carrying out a static analysis of the code.
Clang-tidy is, for example, capable of detecting “narrowing conversions”.
Example of detecting “narrowing conversions”
In the example above, Clang-tidy detects that there has been a “narrowing conversion” and that the value of the port used in the network proxy configuration “may” be corrupted. In this case, this problem was reported on the QGIS issues platform and had to be corrected.
At that time, clang-tidy was not in place. Its use would have made it possible to avoid this anomaly and all the steps which led to its correction (exhaustive description of the issue, multiple exchanges to be able to reproduce it, investigation, correction, review of the modification), meaning a significant amount of human time which could thus have been avoided.
A proposed modification that would validate all of the automatic checks described above would not necessarily be integrated into the QGIS code automatically. In fact, its code may be poorly designed or the modification poorly thought out. The relevance of the functionality may be doubtful, or duplicated with another. The integration of the modification would therefore potentially cause a burden for the people in charge of the corrective or evolutionary maintenance of the software.
It is therefore essential to include a human review in the process of accepting a modification.
This is more of a rereading of the substance of the proposal than of the form. For the latter, we favor the automatic checks described above in order to simplify the review process.
Therefore, human proofreading takes time, and this effort is growing with the quantity of modifications proposed in the QGIS code. The question of its funding arises, and discussions are in progress. The QGIS.org association notably dedicates a significant part of its budget to fund code reviews.
More than 100 modification proposals were reviewed and integrated during the month of December 2023. More than 30 different people contributed. More than 2000 files have been modified.
Therefore the wait for a proofreading can sometimes be long. It is also often the moment when disagreements are expressed. It is therefore a phase which can prove frustrating for contributors, but it is an important and rich moment in the community life of a free project.
To be continued !
As a core QGIS developer, and as a pure player OpenSource company, we believe it is fundamental to be involved in each step of the contribution process.
We are investing in the review process, improving automatic checks, and in the QGIS quality process in general. And we will continue to invest in these topics in order to help make QGIS a long-lasting and stable software.
If you would like to contribute or simply learn more about QGIS, do not hesitate to contact us at [email protected] and consult our QGIS support proposal.
Open source software projects thrive on the contributions of the community, not only for the code, but also for making the software accessible to a global audience. One of the critical aspects of this accessibility is the localization or translation of the software’s messages and interfaces. In this context, Weblate (https://weblate.org/) has proven to be […]
The post Translating Open Source Software with Weblate: A GRASS GIS Case Study appeared first on Markus Neteler Consulting.
What’s new in a nutshell The GRASS GIS 8.3.1 maintenance release provides more than 60 changes compared to 8.3.0. This new patch release brings in important fixes and improvements in GRASS GIS modules and the graphical user interface (GUI) which stabilizes the new single window layout active by default. Some of the most relevant changes […]
The post GRASS GIS 8.3.1 released appeared first on Markus Neteler Consulting.
You may be wondering where Oslandia’s name is coming from ? Or maybe you already know ? In this article we focus on the “OS” part of Oslandia : OpenSource !
Oslandia positions itself as IT expert in the field of OpenSource geographical information systems. QGIS is namely one of the proheminent opensource softwares for the geospatial industry. This position is a key element of our business model.
But do you know how we work behind the scene ? This article will give you an opportunity to discover some of our contributions to the OpenSource ecosystem.
Our general business model is based on projects we carry out for our clients. They fund us to design and implement solutions adapted to their needs and requirements. Part of these developments consist in core development of Opensource software. This allows us to contribute actively to FOSS4G components.
But this funding method makes it complicated to fund maintenance, or new exploratory developments, as well as communication, community management or other tasks necessary for healthy opensource projects.
As a consequence, we introduced at Oslandia a mechanism of internal OpenSource project grants.
These grants constitute self-investment from the company into the OpenSource ecosystem, and can be applied to new projects, research and development or existing projects.
This mechanism has multiple interests :
These OpenSource grants consist in a large range of possible tasks, as we often say : “Opensource projects are not only code”. Instead of developers, we prefer the term contributors. Development, code review, maintenance, documentation, community management, communication, each collaborator can choose the type of task to focus on.
We differentiate software maintenance grants and opensource project grants. We call the latter “OpenSource mini-projects”
Software maintenance consists in refactoring, bugfixing, packaging, release management… All these tasks need dedicated time which is difficult to fund directly on client’s project.
Opensource mini-projects grants are specific opensource proposal which can be submitted by any collaborator on any subject. We then vote on the best proposal and the team can start working on the subject within the allocated budget.
We allocate around 5% of the global production time to software maintenance grants. Our Opensource maintenance grant for 2022 is therefore approximately 190 days of work. It mainly focus on QGIS, PostGIS, QWC2, Giro3D and a few other components we actively maintain.
We also allocate 5% of the global production time to opensource mini-projects grants. It represents an additional 190 days of work for 2022.
Oslandia therefore invests almost 400 days of work into the OpenSource ecosystem, outside of direct contributions for client’s projects.
OpenSource mini-projects grants are submitted by Oslandia’s collaborators and focus on various task and thematics : innovation, development, design, prototyping, communication or any other kind of Opensource contribution.
Proposals have to define goals, deliverables, planning, team and needed budget. Then we evaluate the proposals given the following criteria :
We then vote on best proposal and manage these mini-projects just as a client project.
The maintenance grant on QGIS allowed us to work on the following tasks :
During the year of 2022, we worked on the following mini-projects :
In 2023 we will continue to work on these projects, and others ! for example pg_featureserv, py3dtiles, infoclimat website, MapProxy, pgRouting…
This investment mechanism allows Oslandia to be an opensource “pure player” and contribute actively to these OpenSource projects and to the OpenSource ecosystem as a whole.
Should you be interested in our contribution model, or if you have any question regarding our internal OpenSource grant program, do not hesitate to contact us : [email protected] !
This is an update release of the GRASS GIS 8.0 series. Download source code tarball at https://grass.osgeo.org/grass80/source/grass-8.0.1.tar.gz https://grass.osgeo.org/grass80/source/grass-8.0.1.md5sum For further release details (bug fixes and enhancements), see https://trac.osgeo.org/grass/wiki/Grass8/NewFeatures80 The GRASS GIS 8.0.1 release provides more than 20 fixes and improvements with respect to the release 8.0.0. What’s Changed Important fixes utils/mkhtml: fix print warning/fatal message […]
The post GRASS GIS 8.0.1 released appeared first on Markus Neteler Consulting.
Overview of changes After more than 3 year of development the first stable release GRASS GIS 8.0.0 is available. Efforts have concentrated on making the user experience even better, providing many new useful additional functionalities to modules and further improving the graphical user interface. Breaking news: new graphical user interface with entirely rewritten startup sequence! […]
The post GRASS GIS 8.0.0 released! Finally… appeared first on Markus Neteler Consulting.
After more than 3 year of development the first stable release GRASS GIS 8.0.0 is available. Efforts have concentrated on making the user experience even better, providing many new useful additional functionalities to modules and further improving the graphical user interface.
Breaking news: new graphical user interface with entirely rewritten startup sequence!
This re-establishes user experience compatibility with QGIS and other connected software packages.
The GRASS GIS 8.0.0 release provides more than 1,300 fixes and improvements with respect to the release 7.8.6.
With the introduction of the semantic label raster metadata class, the temporal database was modified to version 3. Hence, to be able to read and process GRASS 7.x space-time datasets, users will be prompted to run t.upgrade. If users want to read newly created space-time datasets back in GRASS 7.x, they can run t.downgrade.
Launching the software
The user experience of the graphical user interface has been completely rewritten: no more clumsy selection screens – just enter the menu system directly!
And on command line, GRASS GIS now starts versionless, i.e. as grass.
See https://github.com/OSGeo/grass/releases/tag/8.0.0RC2
Thanks to all contributors!
The post GRASS GIS 8.0.0RC2 released appeared first on Markus Neteler Consulting.
What’s new in a nutshell 
As a follow-up to the previous GRASS GIS 7.8.4 we have published the new release GRASS GIS 7.8.5 with more than 80 improvements. This minor release offers new wxGUI fixes across the tree. Also the addon extension manager received various stability fixes. VRT raster map with tiled raster maps can now be properly exported and imported in the native GRASS GIS raster format.
The overview of new features in the 7.8 release series is available at new features in GRASS GIS 7.8. See also our detailed announcement with the full list of changes and bugs fixed at https://trac.osgeo.org/grass/wiki/Release/7.8.5-News.
Binaries/Installer download:
Source code download:
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. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics or in the cloud. 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, Dec 2020
The post GRASS GIS 7.8.5 released appeared first on Markus Neteler Consulting.
Call for Participation for FOSDEM 2021 geospatial devroom
Submission Deadline: 26.12.2020
FOSDEM is the largest free and open source developers meeting in Europe, with 8000+ participants. It normally takes place in Brussels (Belgium).
FOSDEM 2021 will be an online event. We will have a geospatial devroom again. The geospatial devroom will be on Saturday, 6 February 2021. In 2021 it will be our opportunity to bring our global community to FOSDEM.
The geospatial devroom is the place to talk about the state of the art of open, geo-related data, free and open source geospatial software and its ecosystem. This includes standards and tools, e.g. spatial databases, online mapping tools, geospatial services, used for collecting, storing, delivering, analysing, and visualizing geodata.
We are looking for you to be part of the geospatial devroom. The geospatial devroom aims to host talks about geospatial topics, GIS, and geodata projects, standards and open data.
Please submit your talk till 26. December 2020.
You find detailed information about the CfP at:
https://www.osgeo.org/foundation-news/osgeo-at-fosdem-2021-online-call-for-participation/
We hope you will submit a talk or come around at FOSDEM 2021.
See you at FOSDEM 2021
The post OSGeo at FOSDEM 2021 (Online) – Call for Participation for the geospatial devroom appeared first on Markus Neteler Consulting.
GRASS GIS is an open source geoinformation system which is developed by a globally distributed team of developers. Besides the source code developers also message translators, people who write documentation, those who report bugs and wishes and more are involved.
While GRASS GIS is under development since 1982 (no typo!) it has been put into a centralized source code management system in December 1999. Why so late? Because the World Wide Web (WWW) became available in the 1990s along with tools like browsers and such, followed by the development of distributed source code management tools. We moved on 29th Dec 1999 (think Y2K bug) the entire code into our instance of CVS (Concurrent Versioning System). With OSGeo being founded in 2006, we migrated the CVS repository to SVN (Subversion for the source code management) and trac (bug and wish tracker) on 8 Dec 2007. See here for historic details on our various bug trackers.
Now, after more than 10 years using SVN/trac time had come to move on and join the large group of projects managing their source code in git (see also our related Wiki page on migration). Git comes with numerous advantages, yet we needed to decide which hosting platform to use. Options where github.com, gitlab.com, gitlab or gitea on OSGeo infrastructure, or other platforms. Through a survey we found out that the preference among contributors is GitHub. While not being open source itself it offers several advantages: it is widely known (good to get new developers interested and involved), numerous OSGeo projects are hosted there under the GitHub “OSGeo organization“.
If all fails (say, one day GitHub no longer being a reasonable choice) the import of our project from GitHub to GitLab is always possible. Indeed, we meanwhile mirror our code on OSGeo’s gitea server.
Relevant script code and migration ticket:
Relevant steps:
What special about it:
What’s missing
A series of links had to be updated. Martin Landa invested days and days on that (thanks!!). He used the related GDAL efforts as a basis (Even Rouault: thanks!). As the date for the trac migration we selected 2007-12-09 (r25479) as it was the first SVN commit (after the years in CVS). The migration of trac bugs to github (i.e. transfer of trac ticket content) required several steps:
Link updates in the ticket texts:
Transferring:
Given GRASS GIS’ history of 35+ years we had to invest major effort in identifying and mapping user names throughout the decades (see also bug tracker history). The following circumstances could be identified:
We came up with several lookup tables, aiming at catching all variants. Just a “few” hours to dig in old source code files and in emails for finding all the missing email addresses…
We cleaned up the trac component of the bug reports, coming up with the following categories which have to be visually grouped by color since the label list is just sorted alphabetically in github/gitlab:
Note that the complete issue migration is still to be done (as of Nov. 2019). Hopefully addressed at the GRASS GIS Community Sprint Prague 2019.
In order to avoid users being flooded by emails due to the parsing of user contributions which normally triggers an email from github) we reached out to GitHub support in order to temporarily disable these notifications until all source code and selected issues were migrated.
The issue conversion rate was 4 min per trac bug to be converted and uploaded to github. Fairly slow but likely due to the API rate limit imposed and the fact that the migration script above generates a lot of API requests rather than combined ones..
Note to future projects to be migrated: use the new gihub import API (unfortunately we got to know about its existence too late in our migration process).
Here out timings which occurred during the GRASS GIS project migration from SVN to github:
In order to guide the user when reporting new issues, we will develop a small template – forthcoming.
We changed the settings from SVN post-hook to Github commit notifications and they flow in smoothly into the grass-commit mailing list. Join it to follow the development.
Overall, after now several months of using our new workflow we can state that things work fine.
The post Remarks on SVN-trac to GitHub migration appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
Few months ago, Oslandia launched QGIS lab’s , a place to advertise our new ideas for QGIS, but also a place to help you find co funders to make dreams become reality.
The first initiative is about label selective masking, a feature that will allow us to achieve even more professional rendering for our maps.
Thanks to the commitment of the Swiss QGIS user group and local authorities, this work is now funded !
We now can start working hard to deliver you this great feature for QGIS 3.10
Thanks again to our funders
A last word, this is not a classical crowd funding initiative, but a classical contract for each funder.
No more reason not to contribute to free and open source software!
On February 4, 2006 OSGeo held its first meeting in Chicago, with 25 participants representing 18 groups and over 20 different Open Source GIS projects, and 39 others participating via Internet Relay Chat. During the meeting, participants made important decisions in the formation and organization of the foundation, including the name, structure and purpose. The consensus reached in Chicago opened the way for the establishment of a productive and representative foundation.
Today we are happy to announce that the we have meanwhile over 32,800 unique subscribers in the huge list of over 290 OSGeo mailing lists!
And: check out the web site of the OSGeo foundation.
… see here for the growing list of events
The post Happy birthday OSGeo! appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
We are pleased to announce the GRASS GIS 7.4.2 release
What’s new in a nutshell
After a bit more than four months of development the new update release GRASS GIS 7.4.2 is available. It provides more than 50 stability fixes and improvements compared to the previous stable version 7.4.1. An overview of the new features in the 7.4 release series is available at New Features in GRASS GIS 7.4.
Efforts have concentrated on making the user experience even better, providing many small, but useful additional functionalities to modules and further improving the graphical user interface. Segmentation now support extremely large raster maps. Dockerfile and Windows support received updates. Also the manual was improved. For a detailed overview, see the list of new features. As a stable release series, 7.4.x enjoys long-term support.
Binaries/Installer download:
Source code download:
More details:
See also our detailed announcement:
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, October 2018
The post GRASS GIS 7.4.2 released appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
What’s new in a nutshell
This is the first release candidate of the upcoming major release GRASS GIS 7.2.0.
The new GRASS GIS 7.2.0RC1 release provides more than 1900 stability fixes and manual improvements compared to the stable releases 7.0.x.
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 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:
http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures (overview of new 7 stable release series)
First time users may explore the first steps tutorial after installation.
About GRASS GIS
The Geographic Resources Analysis Support System (http://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, October 2016
The post GRASS GIS 7.2.0RC1 released appeared first on GFOSS Blog | GRASS GIS Courses.
