The 8.2.0 release of GRASS GIS is now available with results from the GSoC 2021 and many other additions. A new grass.jupyter package is now included for interacting with Jupyter notebooks. Single window graphical user interface is available in GUI settings. r.series and three other modules are newly parallelized. Additionally, the release includes a series of scripting, packaging, and reproducibility improvements.
For all 220+ changes, see our detailed announcement with the full contributors and list of features and bugs fixed at GitHub / Releases / 8.2.0. Special thanks to GSoC students, their mentors, and first-time contributors!
Packages and installers are now available for Windows, macOS, Debian, Fedora, and Gentoo with more coming soon.
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.
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. Enjoy!
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.
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.
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 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).
In episode 86 of MapScaping podcast, Markus Neteler talks about the functionality offered (the topological vector engine, 2D and 3D raster analysis, image processing and available programming interfaces), and whom GRASS GIS is for.
Markus is the cofounder of mundialis, a Bonn based business. He is also the Chairman of the GRASS GIS Project Steering Committee.
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2020-12-13 21:49:292024-01-22 22:21:44MapScaping podcast: GRASS GIS probably doesn’t get the attention it deserves
As a follow-up to the previous GRASS GIS 7.8.3 we have published the new release GRASS GIS 7.8.4 with more than 170 improvements. This minor release again focuses on wxGUI fixes, especially in the animation export, the layer management, 3D visualization and the data catalogue. Many display modules received fixes as well, and the vector digitizer now works as expected.
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).
GRASS GIS 7.8.2 released with updated PROJ 6 and GDAL 3 support
What’s new in a nutshell
As a follow-up to the recent GRASS GIS 7.8.1 we have pusblished the new stable release GRASS GIS 7.8.2.
Besides other improvements, the release contains important PROJ 4/5/6 related datum handling fixes, wxGUI fixes and a fix for the vector import from PostGIS databases.
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).
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.
Early days… from pre-Internet to CVS and SVN
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.
Time to move on: git
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.
file timestamps (which I tried to preserve for decades :-) have been used to reconstruct the source code history (e.g., releasebranch_3_2)
junk files removed (plenty of leftover old binary files, files consisting of a special char only etc)
having this grass-legacy repo available in parallel to the main grass repo which contains the recent source code we have a continuous source code coverage from 1987 to today in git.
size is about 250MB
What’s missing
the 4.3 source code doesn’t have distinct timestamps. Someone must have once packaged without mtime preservation… a pity. Perhaps a volunteer may fix that by carrying over the timestamps from GRASS GIS 4.2 in case the md5sum of a file is identical (or so).
Trac issue migration
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:
links to other tickets (now to be pointed to full trac URL). Note that there were many styles of referring in the commit log message which had to be parsed accordingly
links to trac wiki (now to be pointed to full trac URL)
links source code in SVN (now to be pointed to full trac URL)
images and attachments (now to be pointed to full trac URL)
Transferring:
“operating system” trac label into the github issue text itself (following the new issue reporting template)
converting milestones/tickets/comments/labels
converting trac usernames to Github usernames
setting assignees if possible, set new “grass-svn2git” an assignee otherwise
slowing down transfer to match the 60 requests per second API limit rate at github
Fun with user name mapping
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:
user present in CVS but not in SVN
user present in SVN but not in CVS
user present in both with identical name
user present in both with different name (well, in our initial CVS days in 1999 we often naivly picked our surnames like “martin”, “helena”, “markus”, “michael” … cute yet no scaling very much over the years!) as some were changed in the CVS to SVN migration in 2007, leading to
colliding user names
some users already having a github account (with mostly different name again)
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…
Labels for issues
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:
Issue category:
bug
enhancement
Issue solution (other than fixing and closing it normally):
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:
grass repo: XX hours (all GRASS GIS 7.x code)
grass-legacy repo: XX hours (all GRASS GIS 3.x-6.x code)
NNN issues: XX hours – forthcoming.
New issue reporting template
In order to guide the user when reporting new issues, we will develop a small template – forthcoming.
Email notifications: issues to grass-dev and commits to grass-commit
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.
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2019-12-01 12:03:542023-10-22 18:58:58Remarks on SVN-trac to GitHub migration
Please help us testing the Python3 support in the yet unreleased GRASS GIS trunk (i.e., version “grass77” which will be released as “grass78” in the near future).
Why Python 3?
Python 2 is end-of-life (EOL); the current Python 2.7 will retire in 11 months from today (see https://pythonclock.org). We want to follow the “Moving to require Python 3” and complete the change to Python 3. And we need a broader community testing.
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2019-01-28 00:32:592023-12-07 13:33:49Call for testing: GRASS GIS with Python 3
The 8.2.0 release of GRASS GIS is now available with results from the GSoC 2021 and many other additions. A new grass.jupyter package is now included for interacting with Jupyter notebooks. Single window graphical user interface is available in GUI settings. r.series and three other modules are newly parallelized. Additionally, the release includes a series of scripting, packaging, and reproducibility improvements.
Follow