GRASS-Wiki - User contributions [en]

Talk:GRASS Developer Summit Raleigh 2025

2025-05-24T21:19:55Z

Baharmon: /* Brendan Harmon | Louisiana State University */

{{toc|right}}

Quick links: [[GRASS Developer Summit Raleigh 2025|Meeting page]] | [[#Participant_reports|Reports]] | [[GRASS_Developer_Summit_Raleigh_2025#Sponsors|Sponsors]]

== Organizing Team ==

* Initial planning: Vaclav Petras, Anna Petrasova, Veronica Andreo, Corey White, Lois Utt, Sarah White, Doug Newcomb, Huidae Cho, Veronica Andreo ([[GRASS_Developer_Summit_Raleigh_2025#Organizing_Committee|Organizing Committee]])
* Budget: Vaclav Petras, Lois Utt, Anna Petrasova
* Raising support: Helena Mitasova, Vaclav Petras, Anna Petrasova, Michael Barton, Giuseppe Amatulli ([[NSF POSE Project 2023-2025 Timeline|NSF POSE project]] proposal authors)
* Travel: Lois Utt
* Venue: Vaclav Petras, Lois Utt
* Meals: Lois Utt, Sarah White, Vaclav Petras, Corey White, Anna Petrasova
* Agenda: Vaclav Petras, Huidae Cho, Anna Petrasova
* Wiki page: Vaclav Petras, Anna Petrasova
* Swag: Sarah White, Vaclav Petras, Anna Petrasova, Corey White
* Promotion, invitations, and social media: Vaclav Petras, Sarah White, Corey White, John Vogler
* Lightning talks organization: Vaclav Petras, Zachary Arcaro, John Vogler
* Lightning talk speakers: Vaclav Petras (welcome), Markus Metz and Markus Neteler (talk presented by Vaclav Petras), Anna Petrasova, Veronica Andreo, Robert Dzur, Nick Brady, Huidae Cho, Gregory Power, Doug Newcomb, Caitlin Haedrich
* Photography: Caitlin Haedrich, Māris Nartišs, Pratikshya Regmi
* Portrait photography: Riya, Caitlin Haedrich, Natalie Trso

== Detailed Schedule ==

=== Day 1, Monday, May 19 ===

Location: Talley Student Union, 2610 Cates Ave ([https://www.google.com/maps/place/Talley+Student+Union/data=!4m2!3m1!1s0x0:0x38989377c96adef0?sa=X&ved=1t:2428&ictx=111 map])

Room: 5101-Executive Board Room

Highlighted topic: ''Contributing to GRASS. Getting started. Is it easy to contribute?''

{| class="wikitable"
! Time !! Slot !!
|-
| 8:30-9:00 || Breakfast || Catered breakfast on site. Meet people, and plan your personal agenda for the day.
|-
| 9:00-10:00 || Morning opening sessions || What to expect from the event, contributing to GRASS using Git and GitHub, making your first contribution.
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-11:20 || Self-organized feedback session || i.hyper: Integrating Hyperspectral Imagery Processing into GRASS - Alen Mangafić
|-
| 11:20-11:40 || Self-organized feedback sessions ||
|-
| 11:40-12:00 || Self-organized feedback sessions || Project Image - Vaclav Petras
|-
| 12:00-13:00 || Lunch || Catered food on site.
|-
| 13:00-17:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 18:00 || Dinner || We will walk to [https://www.trophybrewing.com/brewing-pizza Trophy Brewing & Pizza] ([https://maps.app.goo.gl/ggnZ7EvXbWqDUmvP9 directions], 30 min walk from Talley)
|}

=== Day 2, Tuesday, May 20 ===

Location: Talley Student Union, 2610 Cates Ave ([https://www.google.com/maps/place/Talley+Student+Union/data=!4m2!3m1!1s0x0:0x38989377c96adef0?sa=X&ved=1t:2428&ictx=111 map])

Room: 5101-Executive Board Room

Highlighted topics: ''Hydrology and Interfacing with R and QGIS (gathering user feedback, testing, discussing with developers, developing action items)''

{| class="wikitable"
! Time !! Slot !!
|-
| 8:30-9:00 || Breakfast || Breakfast on site. Start the day, meet people, and plan your personal agenda for the day.
|-
| 9:00-10:00 || Morning opening sessions || Introduction to writing GRASS tools, program for the day.
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-11:20 || Self-organized feedback session || fasterRaster R package - Adam Smith
|-
| 11:20-11:40 || Self-organized feedback sessions || Hydography90m + Geocomputation Courses - Giuseppe
|-
| 11:40-12:00 || Self-organized feedback sessions || Flood modelling with grass and itzi ([https://itzi.org]) - Laurent Courty
|-
| 12:00-13:00 || Lunch || [https://maps.app.goo.gl/womSkce9DrE8CTnR8 Case dining hall]
|-
| 13:00-17:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 18:00 || Dinner || [https://maps.app.goo.gl/CQiWoCAQNt1ymZkb7 Served in Jordan Hall at the Center for Geospatial Analytics], evaluate the day's accomplishments, plan and prioritize for the next few days.
|}

=== Day 3, Wednesday, May 21 ===

Location: Talley Student Union, 2610 Cates Ave ([https://www.google.com/maps/place/Talley+Student+Union/data=!4m2!3m1!1s0x0:0x38989377c96adef0?sa=X&ved=1t:2428&ictx=111 map])

Room: 5101-Executive Board Room

Highlighted topic: ''Non-coding contributions, natural language translation, and internationalization.''

{| class="wikitable"
! Time !! Slot !!
|-
| 7:00-9:00 || Breakfast || [https://maps.app.goo.gl/eZ8VK8Mx6TjMt9NP8 Case dining hall]
|-
| 9:00-10:00 || Morning opening sessions || Introduction to non-coding contributions, tutorials, contributing examples, natural language translation and internationalization (procedures, glossaries, code customization, translation).
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-11:20 || Self-organized feedback session || Easier access to GRASS tools - Vaclav Petras
|-
| 11:20-11:40 || Self-organized feedback sessions ||
|-
| 11:40-12:00 || Self-organized feedback sessions || GRASS backend for xarray and temporal framework global variables ([https://github.com/OSGeo/grass/issues/629]) - Laurent Courty
|-
| 12:00-13:00 || Lunch || Served on site. Eat, drink, and continue the discussion from the feedback sessions.
|-
| 13:00-17:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 18:00 || Dinner || [https://maps.app.goo.gl/1E39eySMVaxYJUUS8 Picnic at Pullen Park, shelter #3. In case of bad weather, dinner at the Center for Geospatial Analytics.
|}

=== Day 4, Thursday, May 22 ===

Location: Center for Geospatial Analytics, Jordan Hall, 2800 Faucette Drive ([https://www.google.com/maps/search/Jordan+Hall/@35.7816832,-78.6772765,18z/data=!3m1!4b1?entry=ttu&g_ep=EgoyMDI1MDQyMC4wIKXMDSoJLDEwMjExNDUzSAFQAw%3D%3D map])

Room: 5103 (straight from the two elevators, at the end of the hallway)

Highlighted topic: ''Project vision and computational engine use case.''

{| class="wikitable"
! Time !! Slot !!
|-
| 8:00-9:00 || Breakfast || On site. Start the day, meet people, and plan your personal agenda for the day.
|-
| 9:00-10:00 || Morning opening sessions || Project vision and the computational engine use case (missing features, documentation, user groups).
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-11:20 || Self-organized feedback session || NSF POSE I-Corps Interviews - Corey White
|-
| 11:20-11:40 || Self-organized feedback session || YAIT - Yet Another Interface to Tools - Vaclav Petras
|-
| 11:40-12:00 || Self-organized feedback session || Modernizing Color Tables (Brendan)
|-
| 12:00-13:00 || Lunch || On site. Eat, drink, and continue the discussion from the feedback sessions.
|-
| 13:00-16:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 16:00-17:00 || Lightning talks || Fast-paced talks, showcasing applications of GRASS, room 5111.
|-
| 18:00 || Reception || Connect with researchers, government professionals, and industry collaborators, rooms 5111 and 5119.
|}

=== Day 5, Friday, May 23 ===

Location: James B. Hunt Jr. Library, 1070 Partners Way - Centennial Campus ([https://www.google.com/maps/place/James+B.+Hunt+Jr.+Library/@35.7693736,-78.679167,17z/data=!3m1!5s0x89acf5759f5a31df:0xc547454a0151c440!4m10!1m2!2m1!1shunt+library!3m6!1s0x89acf5759f591f41:0xbe0266269ce37f59!8m2!3d35.7693215!4d-78.6764409!15sCgxodW50IGxpYnJhcnlaDiIMaHVudCBsaWJyYXJ5kgESdW5pdmVyc2l0eV9saWJyYXJ54AEA!16s%2Fm%2F0r4wjf_?entry=ttu&g_ep=EgoyMDI1MDQyMC4wIKXMDSoJLDEwMjExNDUzSAFQAw%3D%3D map])

Room: Faculty Research Commons - 5100 ([https://www.lib.ncsu.edu/hunt/map floor plan])

Highlighted topic: ''GRASS project's future course.''

{| class="wikitable"
! Time !! Slot !!
|-
| 7:45-8:15 || Breakfast || '''Hotel Aloft (2nd floor).''' Search for Lois!
|-
| 9:00-10:00 || Morning opening sessions || GRASS project's future course.
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-12:00 || PSC meeting || Project Steering Committee meets (public).
|-
| 11:00-11:20 || Self-organized feedback session || Your topic here
|-
| 11:20-11:40 || Self-organized feedback sessions || Your topic here
|-
| 11:40-12:00 || Self-organized feedback sessions || Rescheduled for Saturday

|-
| 12:00-13:00 || Lunch || Walk to [https://maps.app.goo.gl/kHVHY62QxTd6wHKd9 On the Oval Culinary Creations]. Eat, drink, and continue the discussion from the feedback sessions.
|-
| 13:00-17:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 18:00 || Dinner || Dinner on your own. Corey White will organize trip to downtown. Bus 41 from Hunt library to hotel and then walk.
|}

=== Day 6, Saturday, May 24 ===

Location: James B. Hunt Jr. Library, 1070 Partners Way - Centennial Campus ([https://www.google.com/maps/place/James+B.+Hunt+Jr.+Library/@35.7693736,-78.679167,17z/data=!3m1!5s0x89acf5759f5a31df:0xc547454a0151c440!4m10!1m2!2m1!1shunt+library!3m6!1s0x89acf5759f591f41:0xbe0266269ce37f59!8m2!3d35.7693215!4d-78.6764409!15sCgxodW50IGxpYnJhcnlaDiIMaHVudCBsaWJyYXJ5kgESdW5pdmVyc2l0eV9saWJyYXJ54AEA!16s%2Fm%2F0r4wjf_?entry=ttu&g_ep=EgoyMDI1MDQyMC4wIKXMDSoJLDEwMjExNDUzSAFQAw%3D%3D map])

'''Take bus 41 at 8.30 from Aloft.'''

Room: Faculty Research Commons - 5100 ([https://www.lib.ncsu.edu/hunt/map floor plan])

Highlighted topics: ''NSF POSE project evaluation.''

{| class="wikitable"
! Time !! Slot !!
|-
| 8:30-10:00 || Breakfast || We will have breakfast (yogurt, granola, pastries) at [https://maps.app.goo.gl/EwzNxeovv4rTivjK9 Lake Raleigh]. Feel free to bring your own coffee.
|-
| 10:00-11:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 11:00-11:20 || Self-organized feedback session || Your topic here (10-minute presentation and 10-minute discussion)
|-
| 11:20-11:40 || Self-organized feedback sessions || Your topic here
|-
| 11:40-12:00 || Self-organized feedback sessions || GRASS tools: core and additional functionality (MartinL)
|-
| 12:00-13:00 || Lunch || Pizza. Eat, drink, and continue the discussion from the feedback sessions.
|-
| 13:00-17:00 || Focus time || Time to work on your laptop, whiteboard solutions with a group, or anything in between.
|-
| 18:00 || Dinner || Player's Retreat.
|}

== Daily tasks for participants ==

* List all the things you are working on in the Participant reports section below. Update the list each day. Include things you work on with other people.
* If you want to discuss something with the whole group, add yourself to a Self-organized feedback sessions slot in the schedule above or tell Vaclav (Vashek) Petras.
* For people with triage access and above: If you are or will be working on an issue or on a PR which is not originally submitted by you, assign yourself to the issue or PR. (You can unassign yourself later if you change your mind.)

== Participant reports ==

Per-person reports from the meeting.

=== Giuseppe Amatulli | Yale University ===

* Testing r.watershed and r.stream.* for handling large datasets
* Running r.flowaccumulation at global level using water direction from hydrography90m
* Preparing the grass tutorial material for the https://www.geomorphometry2025.org/ conference

=== Veronica Andreo | CONICET - Instituto Gulich ===

* [https://github.com/veroandreo?tab=overview&from=2025-05-12&to=2025-05-24 GitHub contributions]
* Enhanced the website footer.
* Sync icons on the Tutorials website footer to those on the main website.
* Fix descriptions and their display on the tutorials website.
* Fix GRASS page on OSGeo website [https://www.osgeo.org/projects/grass-gis/]
** Changed logo, removed GIS from the name, fixed old links.
* Social media posts.
* Discussion about hyperspectral with Alen and Anna.
* Expand the GRASS acronym on the home page.
* Remove GIS from GRASS name on the website.
* Review tutorials by Huidae and Adam Smith.
* Add external tutorials by Huidae and the one from FOSS4G 2024.
* Started adding the time series tutorials.
* Add lightbox class in get-started tutorials so images can be clicked on.
* GRASS PSC admin stuff.
* Participated of the PSC meeting.
* Talk to Tonis Kardi from FOSS4G EU LOC to have a "State of GRASS" talk in the program. Alen will be presenting.
* Gave a lightning talk: GRASS-fed species distribution models.
* Discussed with Brendan, Corey and Mimi about tutorials.

=== Abdullah Azzam | New Mexico State University ===

* Created first PR; fixed broken links on the website [https://github.com/OSGeo/grass-website/pull/538 #538]
* Pushed a new GRASS Addon ''r.curvenumber'' [https://github.com/OSGeo/grass-addons/pull/1403 #1403]

=== Michael Barton | Arizona State University ===

* POSE related activities

=== Laura Belica | NC State University ===

* have been working on developing a workflow-tool tutorial template that facilitates GRASS learners who tend to 'jump in' or have a 'choose your own adventure' approach to learning GRASS (i.e., want to use their data for their study area for their objective from the start). The structure of the tutorial template is a concise, basic, general description/instructions of the workflow with optional links to pertinent explanatory/deeper dive content (e.g., plain language explainers of the tool, options, defaults, etc.) in a variety of formats (e.g., captioned images, short tool demo videos (30 sec to 2 min)) in addition to the more comprehensive resources available (e.g. documentation, examples, tutorials). The main motivation for this approach is to help new and occasional GRASS users avoid some of the common pitfalls and to learn how to find workarounds for some of the unanticipated challenges they may encounter with their specific datasets or use cases so that they can learn as they go. Another motivation for this approach is to facilitate the translation, extension, and updating of workflow tutorials by the community over time (e.g., providing audio and closed captioning for one of the tool-demo videos in another language, replacing an outdated GUI demo with one for the current release, or incorporating a new add-on as an option in the workflow).

* my focus this week is on developing a draft/test tutorial (in Quarto) for a standard hydrological modelling workflow that begins with the crucial pre-work of how to figure out the appropriate project/location, etc. as well as considerations of some of the downstream impacts of resolution, extent, region etc. It may not be ready for sharing by the end of the week, but suggestions and advice are welcomed in advance.

19 May
* discussed a novice user issue with 'moving' vector data from one location to another with Vero and learned a neat GUI option
* revised and added workflow tutorial text

=== Shonil Sateesh Bhide | NC State University ===

* CI optimization

=== Huidae Cho | New Mexico State University ===

* CMake, conda, CI, Mentoring

Monday 5/19
* [https://github.com/OSGeo/grass/pull/5680 CMake: Recognize conda installation path at runtime]: Replaced by [https://github.com/HuidaeCho/grass-conda/blob/master/recipe/post-link.sh conda post-link.sh]
* CMake and Conda Testing on Linux
* CMake Testing on Windows
* Mentoring: Chung-Yuan, Abdullah

Tuesday 5/20
* [https://github.com/OSGeo/grass/pull/5712 CMake: Define custom complex types for MSVC LAPACKE]
* [https://github.com/OSGeo/grass/pull/5713 CMake: Fix build output directories for MSVC]
* CMake and Conda Testing on Linux
* CMake Testing on Windows

Wednesday 5/21
* Translation Talk
* Translation Discussion with Edouard
* Flow Direction Meeting with Ondrej, Ondrej's Student, Martin, and Markus Metz
* CMake and Conda Testing on Linux
* CMake Testing on Windows
* Mentoring: Chung-Yuan, Abdullah

Thursday 5/22
* [https://github.com/OSGeo/grass/pull/5740 CMake: Fix the parameter is incorrect: . error for MSVC]
* Lightning Talk
* CMake and Conda Testing on Linux
* CMake Testing on Windows
* CI: Discussion with Edouard
* Mentoring: Chung-Yuan, Abdullah

Friday 5/23
* CMake and Conda Testing on Linux
* CMake Testing on Windows
* CI: Discussion with Edouard
* Mentoring: Chung-Yuan, Abdullah

Saturday 5/24
* [https://github.com/OSGeo/grass/pull/5771 MSVC: Use the same M_PI_4 value to avoid redefinition warnings]
* CMake Testing on Windows
* Mentoring: Abdullah

=== Edouard Choinière ===

* Quick ideas, way too much for a week: Helping others (may take a reasonable part of the time), managing CI, setting up localization template updating workflow, backporting tool? Pytest/coverage improvements? Discuss and design other projects, to work on during the year. Open to change on other priorities once there, anything that is useful. Maybe make a little progress on high dpi GUI, especially on Windows.

* Weekend before sprint:
** Clear up Renovate PRs to not use CI time during the sprint, reviewing and merging: [https://github.com/OSGeo/grass/pull/5664 #5664], [https://github.com/OSGeo/grass/pull/5665 #5665], [https://github.com/OSGeo/grass/pull/5666 #5666], [https://github.com/OSGeo/grass/pull/5667 #5667], [https://github.com/OSGeo/grass/pull/5668 #5668]
** PR to avoid some CI run time for the sprint: [https://github.com/OSGeo/grass/pull/5670 #5670]
** Reviewed open PRs for PRs that were mergeable before the sprint, updated outdated PRs to avoid having it needing CI time during sprint. Only ended up merging [https://github.com/OSGeo/grass/pull/5658 #5658], but another reviewed one that might still need changes: [https://github.com/OSGeo/grass/pull/5628 #5628]
* Monday May 19, 2025:
** PR got merged: [https://github.com/OSGeo/grass/pull/5670 #5670],[https://github.com/OSGeo/grass/pull/5550 #5550]
** Reviewed PRs: [https://github.com/OSGeo/grass/pull/5671 #5671], [https://github.com/OSGeo/grass/pull/5672 #5672]
** Discussions:
*** Shonil Sateesh Bhid & Shuham on their CI & pytest work and project.
*** Māris Nartišs about a potential issue and improvement for it. Will be discussed in the security reporting tab, also allowing to test the security vulnerability reporting process. + Research on existing solutions
** Reviewed: [https://github.com/OSGeo/grass/pull/5682 #5682], [https://github.com/OSGeo/grass/pull/5660 #5660],
** Reviewed, edited and merged: [https://github.com/OSGeo/grass/pull/3672 #3672]
** Discussed/helped user for: [https://github.com/OSGeo/grass/pull/5678 #5678] and [https://github.com/OSGeo/grass/pull/5684 #5684]
** Long discussion and vision planning for windows scripting with Vaclav, concerning [https://github.com/OSGeo/grass/pull/5624 #5624]. Tested alternatives and tried the consequences of that PR. This older PR finally got merged.
** Created PRs for NSIS installer: [https://github.com/OSGeo/grass/pull/5685 #5685] and also [https://github.com/OSGeo/grass/pull/5686 #5686], which should address [https://github.com/OSGeo/grass/issues/5663 #5663]. Still needs to test it.
** Agreed on convention for titles with Vaclav, unblocking [https://github.com/OSGeo/grass/pull/5341 #5341]
** Found a name with Ondrej and finally merged older PRs of an external contributor [https://github.com/OSGeo/grass/pull/5473 #5473] and [https://github.com/OSGeo/grass/pull/5474 #5474]
* Thursday May 20, 2025:
** Reviewed: [https://github.com/OSGeo/grass/pull/5695 #5695]
** Merged PRs: [https://github.com/OSGeo/grass/pull/5673 #5673], [https://github.com/OSGeo/grass/pull/5691 #5691], [https://github.com/OSGeo/grass/pull/5690 #5690], [https://github.com/OSGeo/grass/pull/5684 #5684],
** Discussed with author of [https://github.com/OSGeo/grass/pull/5660 #5660] and [https://github.com/OSGeo/grass/issues/5659 #5659] about rgb/hsl bug and tests for help.
** Worked with Corey to adjust markdown links for new markdownlint rule, finishing up [https://github.com/OSGeo/grass/pull/5669 #5669]
** Created PRs: [https://github.com/OSGeo/grass/pull/5692 #5692], [https://github.com/OSGeo/grass/pull/5694 #5694], [https://github.com/OSGeo/grass/pull/5689 #5689]
* Wednesday May 21, 2025:
** Created a new set of GitHub rulesets for the required checks, applied with Vaclav. One of them is separated in order to increase velocity during the sprint
** Reviewed the branch protection rules for grass-addons repo with Vaclav. Creating rulesets will be possible after the sprint with the info collected.
** Reviewed the security reporting settings and secret scanning settings with Vaclav for the main grass repo.
** Got shown by Huidae Cho how to update the translation files, and reviewed Weblate settings. No settings changed, but a backup stored for 30 days was kept.
** Created a first implementation of a translation file update workflow
** Tested out the two NSIS installer PRs, the first one, for installing the VC runtime earlier doesn't work as expected, and after more research I don't know enough to fix it. The second PR with High-DPI improvement was correct and got merged [https://github.com/OSGeo/grass/pull/5685 #5685]
** Helped a student set up a grass installation on WSL with conda.
** PRs created: [https://github.com/OSGeo/grass/pull/5736 #5736], [https://github.com/OSGeo/grass/pull/5734 #5734]
** My PRs that got merged: [https://github.com/OSGeo/grass/pull/5685 #5685], [https://github.com/OSGeo/grass/pull/5341 #5341], [https://github.com/OSGeo/grass/pull/5689 #5689]
** Reviewed and merged multiple PRs, restarting failed required checks of the previous night.

=== Laurent Courty ===

* Objectives: An xarray backend for GRASS STRDS. Fixing related issues
* May 20
** Presented itzi
** Uploaded arm64 wheels to PyPI for MacOS and Linux ([https://pypi.org/project/itzi/#files])
** Discussed with other developers about issue #629
* May 21
** Uploaded xarray-grass to PyPI
** Added CI tests to xarray-grass
** Discussed with the group about the xarray-grass backend
** Discussed with the group about solving mapset switching in the temporal framework (issue #629)
** Created PR #5735 to address issue #629
* May 22
** Fix bug in PR #5735
* May 23
** Continue working on xarray-grass
** Discussed with Vashek about the GRASS tool's python interface
* May 24
** Continue working on xarray-grass
** published xarray_grass-0.1.0a2 on PyPI
** Discussed with Vashek about the grass session issues in python

=== Robert S. Dzur | Bohannan Huston, Inc. ===

* r.in.pdal

=== David W. Farris | East Carolina University ===

* A tool to calculate gravity terrain corrections

=== Neel Ghoshal | NC State University ===
• LLM for helping users find tools 
5/19 
• Learnt how to PR (#5674) 
• Setup GRASS on system 
• Found small issue with compilation document 
• Discussed about the possible use case of LLM for helping users find tools 
5/20 
• Learnt about cookie cutter 
• Set up wsl on system 
• Compiled GRASS 
• Listed data sources for LLM training 
5/21 
• Extracted tool information from Markdown files 
• Started off with data cleaning 
5/22 
• Worked on LLM setup 
5/23 
• Ran and finetuned a basic test LLM model for extracted data 

=== Caitlin Haedrich | NC State University ===

* Event photographs, food coordination
* git/github mentoring
* GRASS mentoring
* Lightning Talk preparation
* Preparing workshop for [https://www.geomorphometry2025.org/ Geomorphometry2025]

=== Brendan Harmon | Louisiana State University ===

* Plan: developing ([https://github.com/baharmon/r.earthworks r.earthworks]) addon & tutorials
* Log: [https://github.com/baharmon?tab=overview&from=2025-05-19&to=2025-05-24 GitHub activity]
* Activities: published r.earthworks to addons repo, discussed modernizing colors, & started map algebra tutorials
* Unfinished: develop map algebra tutorials, open issue about modernizing color, start discussion on citations, open issue about v.to.rast bug, etc...

=== Linda Karlovska | Czech Technical University in Prague ===

* Fix uninitialized variables in DOutFile() method: ([https://github.com/OSGeo/grass/pull/5650 PR])
* Update figures related to GUI: ([https://github.com/OSGeo/grass/pull/5651 PR])

Working on integration of the Jupyter notebooks to GUI (work for the whole week :-))

=== Martin Landa | Czech Technical University in Prague ===

* Tutorial: GISMentors courses updated ([https://github.com/OSGeo/grass-tutorials/pull/45 PR])
* libgis: G__usage_markdown() include tool label in metadata if defined ([https://github.com/OSGeo/grass/pull/5677 PR])
* PyGRASS: Module description property not defined always ([https://github.com/OSGeo/grass/pull/5681 PR])
* Website: OpenGeoLabs commercial support ([https://github.com/OSGeo/grass-website/pull/537 PR])
* v.select: create output also when no features found ([https://github.com/OSGeo/grass/pull/5696 PR])
* wxGUI: avoid creating nested list of errors (Graphical modeler) ([https://github.com/OSGeo/grass/pull/5700 PR])
* wxGUI/gmodeler: refactor - move ModelParamDialog to dialogs.py ([https://github.com/OSGeo/grass/pull/5715 PR])
* GUI: make Python editor dockable ([https://github.com/OSGeo/grass/pull/5733 PR])
* r.relief: module label changed to description ([https://github.com/OSGeo/grass/pull/5741 PR])
* GUI: propagate previously defined where option value ([https://github.com/OSGeo/grass/pull/5747 PR])
* GUI: always show 'Close dialog on finish' option ([https://github.com/OSGeo/grass/pull/5751 PR])
* GUI: do not remove parameter value on dialog update event ([https://github.com/OSGeo/grass/pull/5760 PR])
* documentation: add miscellaneous tools too full index (markdown) ([https://github.com/OSGeo/grass/pull/5761 PR])

=== Nicklas Larsson | Hungarian National Museum ===

Planned work: CMake build system; perhaps Conda recipe

[https://github.com/nilason?tab=overview&from=2025-05-19&to=2025-05-24 GitHub activity]

* Preparation for CMake build conforming to Filesystem Hierarchy Standard (FHS), resolving resource paths for both the current and FHS in code. In collaboration with Huidae Cho and with important input from Vaclav Petras ([https://github.com/OSGeo/grass/pull/5630 PR5630])

* Helped young students in build configuration and debugging techniques.

* Discussion with several participants on solutions to publish a GRASS package to Conda-forge.

=== Chung-Yuan Liang ===

* r.horizon
** [https://github.com/OSGeo/grass/pull/4213 PR4213]
** Discussed with Vashek, Anna, and Huidae regarding parallelization performance.
* r.mapcalc
** [https://github.com/OSGeo/grass/pull/5742 PR5742]
** Parallelized a part of r.mapcalc.
** Discussed with Anna and Huidae how to improve the parallelization.
** More work is needed for better efficiency for threads > 4.
* r.univar
** [https://github.com/OSGeo/grass/pull/5748 PR5748], [https://github.com/OSGeo/grass/pull/5750 PR5750]
** Created a test for large data and parallel computations.
** Applied Kahan sum to avoid accumulations of floating point errors.
** Update reference numbers in other testing scripts that use r.univar.
* Discussing how to improve I/O and memory buffers for raster data in the parallelization aspect.

=== Andres Lucero | Bohannan Huston Inc ===

* r.in.pdal

=== Alen Mangafić | Geodetic Institute of Slovenia ===
Monday May 19
* Presentationf of i.hyper, add-on which offers hyperspectral data support in GRASS.
* Architecture of the multi-module addon
Tuesday May 20
* i.hyper.import module: importing EnMAP imagery as 3D raster map
* i.hyper.preproc module: draft
Wednesday May 21
* fixing the i.hyper.import module
* i.hyper.preproc module: implementing Savitzky-Golay filter

=== Helena Mitasova | NC State University ===

* standardized data set and related tutorials
* documentation for interpolation tools
* collaborate/coordinate/discuss hydrology tools (analytics, simulations, soil properties inputs)
* assist with wiki cleanup if needed

Monday May 19
* investigated issues with v.surf.rst documentation in source code, tested and identified fixes needed
* discussed coupling GRASS with Blender versus potree for 3D object rendering with Brendan, Anna and Caitlin (for TL activities and other applications)
* discussed soil data for runoff estimation and other hydro topics, to be worked on on day 2

Tuesday May 20
* worked with Corey on fixing v.surf.rst documentation, discussed ideas for improvements and for documentation / tutorial for cross-valiadation
* discussed suggestions for graphics and examples to be inculded in v.surf.rst docs with Michelle
* discussed new developments in hydrology tools
* experimented with basic/standardized versus specialized data sets for documentation and tutorials

Wednesday May 21
* explored existing tutorials, emailed Paulo about finishing the one on interpolation
* tested NM basic data set with GIS582 class assignment (very cool)
* discussed design of Jnotebooks that would work with various localized data with Caitlin

Thursday May 22
* discussed needed capabilities for a more advanced color ramp processing tool with Brendan
* added further ideas to basic dataset document after talking to Vero - we just need standardized names for the localized tutorials to work
* discussed infiltration fix pull request for r.sim.water with Anna - more work is needed

=== Michael Mulqueen | MassGIS ===

* depth to water, hydro from lidar, etc

=== Māris Nartišs ===

* Taking photos of the event
* Introduced a new GRASS core module r.smooth.edgepreserve
* Discussed architecture of hyperspectral data import and per-processing tool
* Discussed testing and organizing AI modules downloading data from internet
* Prepared and gave a presentation on code preparation for translations (best practice)
* Debugging translation file updating with Edouard
* Changed default multiprocessor setting to always use maximum number of available threads
* Unified max process setting handling in all modules that use default parser parameter
* Discovered and supervised fixing a bug in r.univar parallelization code
* Discussed requirements for raster data reading parallelization (GRASS 9)
* Discussed future features to be implemented (long term view)
* Run modules in tests under valgrind; opened three bug reports, but log file analysis is incomplete

=== Ondřej Pešek | Czech Technical University in Prague ===

* [https://github.com/pesekon2?tab=overview&from=2025-05-19&to=2025-05-24 GitHub activity]
* Refactoring, fixing, improving, discussing g.gui.gmodeler
* Discussing hyperspectral with Alen Mangafic
* Discussing jupyter in single GUI with Linda Karlovska
* PyGRASS
* Docs
* CQ
* Reviewing PRs, PR archeology

=== Vaclav (Vashek) Petras | NC State University ===

* [https://github.com/wenzeslaus?tab=overview&from=2025-05-19&to=2025-05-24 GitHub activity]
* My focus: Getting feedback and ideas for computational engine use case, APIs, funding.
* Summit organizing
* Implementing rebranding on GitHub (repos, teams)
* Feedback session on project image
* Feedback session on easier access to tools
* Discussed LLMs with Neel Ghoshal, Riya
* Discussed session setupp Martin Landa
* Discussed conda with Nicklas Larsson
* Discussed hyperspectral with Alen Mangafić, Veronica Andreo, and Anna Petrasova
* Discussed code for new smoothing tool, integer overflows, translations with Māris Nartišs
* Compared setup of GRASS session and project in fasterRaster, QGIS, and GRASS itself with Adam Smith
* Discussed potential of Pixi for packaging or compilation with Gregory Power
* Discussed itzi model distribution issues with Laurent Courty
* Discussed r.horizon parallelization with Chung-Yuan Liang and Anna Petrasova
* Answered coding and setup questions for Neel Ghoshal, Abdullah Azzam, and Alen Mangafić

=== Anna Petrasova | NC State University ===

* [https://github.com/petrasovaa?tab=overview&from=2025-05-19&to=2025-05-24 GitHub activity]
* plan: mentoring, documentation
* Monday
** discussing hyperspectral implementation with Alen
** helping mentee David Farris implementing his gravity correction addon
* Tuesday
** delivered intro to creating an addon, documentation
** mentoring Alen, Abdullah
** discussing bug in i.his.rgb with Jayneel
** reviews
* Wednesday
** discuss and demonstrate tutorials page
** mentoring Alen, Jayneel
** call with GSoC student
* Thursday
** lightning talk
** discussing openmp implementations for r.horizon, r.mapcalc, default thread number
* Friday
** grass repo README
** reviews

=== Gregory Power | Town of Cary ===

* Documentation

=== Pratikshya Regmi | NC State University ===

* Event photographs and videos
* Opened a pull request to change GRASS GIS to GRASS on the documentation (this was my first contribution to GRASS)
* Worked on preparing the mock document for LLM RAG
* Wrote a tutorial to Visualize Contour Lines with a Color Gradient with Folium.
* Finished mockup document and testing on LLM.

=== Riya | Indian Institute of Technology, Roorkee ===

* I am currently thinking of developing an AI Agent for the grass jupyter library which will help the users with mathematical calculations done in GIS.

=== Jayneel Shah | NC State University ===

* improve the test coverage of imagery modules.

=== Krishna Prasad Sheshadri ===

*

=== Adam Smith | Missouri Botanical Garden ===

Overall: R package fasterRaster (fielding bug reports, adding features)

Monday:
* Assessed scope of fasterRaster issue [https://github.com/adamlilith/fasterRaster/issues/83 83]

Tuesday:
* Created a PR for fasterRaster tutorial on GRASS tutorials page.
* Improved handling of addons, including autodetect and installing when needed, enabling easier creation of addon-dependent methods.
* Presented *fasterRaster* package to group.

Wednesday:
* Created fasterRaster methods for neighborhood matrices, terrain ruggedness index, and multivariate environmental similarity

=== Michelle (Mimi) Stephens | ERDC ===

* Previous work: coupling R and Python scripts for computational analysis in GRASS.
* Current work: Running through GRASS commands to create visual outputs that can be added to the new GRASS 8.5 manual pages - r.mapcalc, v.surf.rst, examples with topographic parameters, LinkedIn requests.
* Tutorial for Windows users to install a WSL2 Linux environment. Creates a conda environment with wxpython, installs GRASS without requiring OSGeo installer. Fast, simple, and minimal install. Resolves various issues encountered in government due to automatic Windows updates, cyber security, vpn routing, user preference, and isolated distro can be completely removed if needed. -> Motivation for WSL2 - wanted more hands-on practice with Unix command line tools for HPC; Docker not allowed, but miniforge and Apptainer are on ERDC's HPC; able to install grass via command line (only on internet-capable HPC systems); AND - For other users that always wanted a more native feel to their grass instance!
* Future work: Presenting on GRASS in JUNE at CERLCON.

=== Corey White | NC State University ===

* JSON, mentoring

=== Doug Newcomb | Semi Retired Cartographer ===

* Discussed hydroflattening method
* Discussed direct point cloud input to v.surf.rst
* Learning git procedures by updating branding (GRASS GIS to GRASS) for raster commands
Tuesday
* Continued updating branding for raster commands
* Started working on tutorial for r.hydro.flatten
Wednesday
* Finalized Data set for for r.hydro.flatten
* Worked on Lightning Talk for Thursday
Thursday
* Continued work on r.hydro.flatten tutorial
* Gave lightning talk on r.hydro.flatten
Friday
* Worked with Rob Dzur on r.hydro.flatten workflow.
* Explored the possibility of using r.resample.bspline for areas with high standard deviation ranges.

* Worked with Rob Dzur on identifying workflow for implimenting USGS GMI, https://www.usgs.gov/ngp-standards-and-specifications/elevation-derived-hydrography-data-acquisition-specifications-16 , in GRASS and connected Rob with USGS contact for GMI.

=== Natalie Trso | Balance Geo LLC ===

* r.sim.water

== Guests and remote participants ==

=== Luís de Sousa | University of Lisbon ===

* Review outstanding PRs
* Prepare GRASS sessions for the OpenGeoHub Summer School

=== Markus Neteler | mundialis ===

* Support full automation of new GRASS manual pages deployment on server (upload artifacts from GitHub to OSGeo servers (grass and download))
* Source code license documentation: Using SPDX License IDs ({{GH-Issues|4190}})
* Support Wiki cleanup
* [https://github.com/neteler?tab=overview&from=2025-05-19&to=2025-05-24 GitHub contributions]

=== Nishant Bansal | Indian Institute of Technology, Varanasi ===

* Review the previous work on JSON during last year’s GSoC, including enhancements and the addition of JSON output support to other modules.

Talk:GRASS Developer Summit Raleigh 2025

2025-05-20T14:07:01Z

Baharmon: /* Day 4, Thursday, May 22 */

Talk:GRASS Developer Summit Raleigh 2025

2025-05-20T14:05:29Z

Baharmon: /* Day 5, Friday, May 23 */

Talk:GRASS Developer Summit Raleigh 2025

2025-05-20T14:04:11Z

Baharmon: /* Brendan Harmon | Louisiana State University */

Talk:GRASS Developer Summit Raleigh 2025

2025-05-20T14:01:57Z

Baharmon: /* Brendan Harmon | Louisiana State University */

Talk:GRASS Developer Summit Raleigh 2025

2025-05-19T14:52:26Z

Baharmon: /* Day 5, Friday, May 23 */

Color tables

2025-02-18T23:12:51Z

Baharmon: Update color link from cvn to GitHub

== About ==
Color tables live in <tt>$GISBASE/etc/colors</tt> (see [https://github.com/OSGeo/grass/tree/main/lib/gis/colors github])

== Modules ==

* {{cmd|r.colors}} ({{cmd|r.colors}} manual in GRASS 7 has colors tables embedded as well as the GUI dialog)
* {{cmd|r.colors.stddev}} ([http://hamish.bowman.googlepages.com/grass_color_maps samples])
* {{cmd|r.colors.out}}
* {{cmd|r3.colors}}
* {{cmd|r3.colors.out}}
* {{cmd|v.colors}}
* {{cmd|v.colors.out}}

* {{cmd|d.legend}}
* {{cmd|d.colortable}}

=== Addons ===

* User contributed color rules in the [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.tools/palettes GRASS Addons repository]
* Convert from [[GMT]] color tables with {{AddonCmd|r.cpt2grass}}
* Use {{AddonCmd|r.colors.quantiles}} to create raster colors rules based on ''n''-quantiles. It uses the [[GRASS_and_Rstat|R and the spgrass6 package]].
* Use {{AddonCmd|r.colors.out_sld}} to export GRASS raster colors rules in OGC SLD template v1.0.0 XML format for Geoserver and the ilk
* Use {{AddonCmd|r.colors.out_vtk}} to export GRASS raster colors rules for use with VTK-based visualization software.

== Repositories ==

* There is an online colormap repository with many fine [[GMT]] (and many others) gradients at
: http://soliton.vm.bytemark.co.uk/pub/cpt-city/

* There are a number of command line tools for working with the GMT .cpt files at
: http://soliton.vm.bytemark.co.uk/pub/jjg/en/code/cptutils/

== Examples ==
=== Built in ===

The numeric values of following color tables can be found in the [https://github.com/OSGeo/grass/tree/main/lib/gis/colors here]

[[Image:Colortable_aspect.png|center]]

[[Image:Colortable_aspectcolr.png|center]]

[[Image:Colortable_bcyr.png|center]]

[[Image:Colortable_bgyr.png|center]]

[[Image:Colortable_byg.png|center]]

[[Image:Colortable_byr.png|center]]

[[Image:Colortable_celsius.png|center]]


[[Image:Colortable_corine_clc.gcolors.png|center]]

[[Image:Colortable_curvature.png|center]]

[[Image:Colortable_differences.png|center]]

[[Image:Colortable_elevation.png|center]]

[[Image:Colortable_etopo2.png|center]]

[[Image:Colortable_evi.png|center]]

[[Image:Colortable_grey.png|center]]

[[Image:Colortable_grey1.0.png|center]]

[[Image:Colortable_grey255.png|center]]

[[Image:Colortable_gyr.png|center]]

[[Image:Colortable_haxby.png|center]]

[[Image:Colortable_ndvi.png|center]]

[[Image:Colortable_population.png|center]]

[[Image:Colortable_precipitation.png|center]]

[[Image:Colortable_rainbow.png|center]]

[[Image:Colortable_ramp.png|center]]

[[Image:Colortable_ryb.png|center]]

[[Image:Colortable_ryg.png|center]]

[[Image:Colortable_sepia.png|center]]

[[Image:Colortable_slope.png|center]]

[[Image:Colortable_srtm.png|center]]

[[Image:Colortable_terrain.png|center]]

[[Image:Colortable_wave.png|center]]

=== Addons ===

These user contributions can be found in the [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.tools/palettes GRASS addons SVN repository]

[[Image:Colortable_palette_chl_etc.gcolors.png|center]]

[[Image:Colortable_palette_sst.gcolors.png|center]]

[[Image:Colortable_palette_GMT_ocean.gcolors.png|center]]

[[Image:Colortable_palette_roygbiv.gcolors.png|center]]

[[Image:Colortable_palette_high_intensity.gcolors.png|center]]

[[Image:Colortable_palette_low_intensity.gcolors.png|center]]

* ''The script used to create these thumbnails can be found on the [[Talk:Color_tables|discussion page]].''

== Using GRASS color palettes in QGIS ==

Most of them can already be found there, you just have to hunt for them. In the raster layer properties window's style tab, select "Singleband pseudocolor" as the type, "Generate new color map", "New color ramp", for ramp type choose "cpt-city", change to the "Sort by Author" tab, and look for "grass". They can also be found in the QGIS section cpt-city's QGIS theme.

If there's a new set of color rules which are not in [[QGIS]], you can prepare a .svg palette file for use with QGIS using the following commands. Consider to then open a ticket in the QGIS issue tracker asking them to add it (and attach the file of course to save someone some work :)

You will need the [http://soliton.vm.bytemark.co.uk/pub/jjg/en/code/cptutils/ ''cptsvg'' command line tool from cptutils] and the GRASS 6 addon module {{AddonCmd|r.out.gmt|version=64}}.

Examples:
<source lang="bash">
g.region n=100 s=0 w=0 e=100 res=1
r.mapcalc "dummy = row()"

r.colors dummy color=roygbiv
r.out.gmt dummy out=roygbiv
rm roygbiv.grd
cptsvg --geometry=300x45 -o roygbiv.svg -v roygbiv.cpt

r.colors dummy rules=~/grass/svn/grass-addons/grass6/raster/r.colors.tools/palettes/palette_sst.gcolors
r.out.gmt dummy out=palette_sst
rm palette_sst.grd
cptsvg --geometry=300x45 -o palette_sst.svg -v palette_sst.cpt
</source>

You can then copy the resulting .svg file into <tt>/usr/share/qgis/resources/cpt-city-qgis-min/grass/</tt> on Linux (or <tt>C:\Program Files\QGIS VERSION\apps\qgis\resources\cpt-city-qgis-min\grass\</tt> on MS Windows).

Another solution to export raster color tables is to slightly tweak the output of {{Cmd|r.colors.out}}, in order to provide QGIS with a regular color chart source file. It might be handy when dealing with maps produced by {{Cmd|r.composite}}, i.e. unregistered color charts. The example bellow may be adapted to ones needs (here the alpha channel defaults to 255):
<source lang="bash">
r.colors.out map=my_raster rules=~/in.colors
cat in.colors|sed 's/:/,/'g|sed 's/ /,/'g|awk 'BEGIN {FS=",";OFS=","};{print $1,$2,$3,$4,255,$1}'>out.colors
</source>

== Loading QGIS color palettes into GRASS ==

The GRASS GIS addon module {{AddonCmd|r.cpt2grass|version=7}} can be used after the ''svgx'' command line program from the <tt>cptutils</tt> package, using [[GMT]]'s .cpt color table format as a go-between:

<source lang="bash">
svgx --output dkbluered.cpt --type cpt /usr/share/qgis/resources/cpt-city-qgis-min/h5/dkbluered.svg
r.cpt2grass in=dkbluered.cpt output=dkbluered.gcolors
</source>

You can then use the *.gcolors file with the {{Cmd|r.colors}} rules= option (or set the color rules directly from the ''r.cpt2grass'' module).

[[Category: Documentation]]
[[Category: Colors]]
[[Category: VTK]]
[[Category: QGIS]]

GRASS Python Scripting Library

2025-02-18T22:18:05Z

Baharmon: /* Uses for read, feed and pipe, start and exec commands */ Fixed broken link

{{Python}}
Python API documentation:

* [https://grass.osgeo.org/grass78/manuals/libpython/ Python API for GRASS GIS 7] and [http://grass.osgeo.org/grass78/manuals/libpython/script_intro.html Python Scripting Library]
* (old: [https://grass.osgeo.org/programming6/pythonlib.html for GRASS GIS 6]: core.py, db.py, raster.py, vector.py, setup.py, array.py task.py)

The GRASS Python Scripting Library can be imported by statement

<source lang=python>
import grass.script as grass
</source>

The other packages such as PyGRASS can be imported in a similar way.

The code in {{src|lib/python/|lib/python}} provides <tt>grass.script</tt> and other packages in order to support GRASS scripts written in Python. The {{src|scripts}} directory of GRASS GIS 7 contains a series of examples actually provided to the end users (while the script in GRASS GIS 6 are shell scripts).

For more general info, see also [[GRASS and Python]] and see also [[Converting Bash scripts to Python]] if you have some Bash scripts you want to rewrite to Python.

=== Calling a GRASS module in Python ===

Imagine, you wanted to execute this command in Python:
<source lang="bash">
r.profile -g input=mymap output=newfile profile=12244.256,-295112.597,12128.012,-295293.77
</source>

All arguments except the first (which is a flag) are keyword arguments, i.e. <tt>arg = val</tt>. For the flag, use <tt>flags = 'g'</tt> (note that "-g" would be the negative of a Python variable named "g"!). So:

<source lang="python">
grass.run_command('r.profile',
input = input_map,
output = output_file,
profile = [12244.256,-295112.597,12128.012,-295293.77]
</source>
or:
<source lang="python">
profile = [(12244.256,-295112.597),(12128.012,-295293.77)]
</source>

i.e. you need to provide the keyword, and the argument must be a valid Python expression. Function <code>run_command()</code> etc accept lists and tuples.

'''What is the proper way to include keyword-arguments tuples?'''

For example, "g.list -f type=rast,vect" translates into:
<source lang="python">
import grass.script as grass
grass.run_command("g.list", flags="f", type="rast,vect")
</source>
or:
<source lang="python">
import grass.script as grass
grass.run_command("g.list", flags="f", type=["rast","vect"])
</source>

The various *_command() functions accept arbitrary keyword arguments. Any keywords which don't have a specific meaning to either the *_command() function or the Popen constructor are treated as arguments to the GRASS module.

'''What is the proper way to use multiple flags?'''

How can I call a module with multiple flags set (e.g., -a and -b) in GRASS-Python?

flags = "ab"

Example:
<source lang="python">
import grass.script as grass
grass.run_command("r.info", flags="eg", map=["elevation"])
</source>

'''Differences between ''run_command()'' and ''read_command()'':'''

* {{pyapi|script|script.core|run_command}} executes the command and waits for it to terminate; it doesn't redirect any of the standard streams.
* {{pyapi|script|script.core|read_command}} executes the command with stdout redirected to a pipe, and reads everything written to it. Once the command terminates, it returns the data written to stdout as a string.

'''How to retrieve error messages from ''read_command()'':'''

None of the existing *_command functions redirect stderr. You can do so with e.g.:

<source lang="python">
import grass.script as grass

def read2_command(*args, **kwargs):
kwargs['stdout'] = grass.PIPE
kwargs['stderr'] = grass.PIPE
ps = grass.start_command(*args, **kwargs)
return ps.communicate()
</source>

This behaves like <tt>read_command()</tt> except that it returns a tuple of (stdout, stderr) rather than just stdout.

== Uses for read, feed and pipe, start and exec commands ==

All of the <tt>*_command</tt> functions use {{pyapi|script|script.core|make_command}} to construct a command
line for a program which uses the {{cmd|g.parser|desc=GRASS parser}}. Most of them then pass
that command line to <tt>subprocess.Popen()</tt> via {{pyapi|script|script.core|start_command}}, except
for {{pyapi|script|script.core|exec_command}} which uses <tt>os.execvpe()</tt>.

[To be precise, they use <tt>grass.Popen()</tt>, which just calls
<tt>subprocess.Popen()</tt> with 'shell=True' on Windows and 'shell=False'
otherwise. On Windows, you need to use 'shell=True' to be able to
execute scripts (including batch files); 'shell=False' only works with
binary executables.]

{{pyapi|script|script.core|start_command}} separates the arguments into those which
<tt>subprocess.Popen()</tt> understands and the rest. The rest are passed to
<tt>make_command()</tt> to construct a command line which is passed as the
"args" parameter to <tt>subprocess.Popen()</tt>.

In other words, {{pyapi|script|script.core|start_command}} is a GRASS-oriented interface to
<tt>subprocess.Popen()</tt>. It should be suitable for any situation where you
would use <tt>subprocess.Popen()</tt> to execute a normal GRASS command (one
which uses the GRASS parser, which is almost all of them; the main
exception is {{cmd|r.mapcalc}} in 6.x).

Most of the others are convenience wrappers around <tt>start_command()</tt>, for common use cases.

* {{pyapi|script|script.core|run_command}} calls the wait() method on the process, so it doesn't return until the command has finished, and returns the command's exit code. Similar to <tt>system()</tt>.

* {{pyapi|script|script.core|pipe_command}} calls <tt>start_command()</tt> with 'stdout=PIPE' and returns the process object. You can use the process' .stdout member to read the command's stdout. Similar to popen(..., "r").

* {{pyapi|script|script.core|feed_command}} calls <tt>start_command()</tt> with stdin=PIPE and returns the process object. You can use the process' .stdin member to write to the command's stdout. Similar to popen(..., "w")

* {{pyapi|script|script.core|read_command}} calls <tt>pipe_command()</tt>, reads the data from the command's stdout, and returns it as a string. Similar to `backticks` in the shell.

* {{pyapi|script|script.core|write_command}} calls <tt>feed_command()</tt>, sends the string specified by the "stdin" argument to the command's stdin, waits for the command to finish and returns its exit code. Similar to "echo ... | command".

* {{pyapi|script|script.core|parse_command}} calls <tt>read_command()</tt> and parses its output as key-value pairs. Useful for obtaining information from {{cmd|g.region}}, {{cmd|g.proj}}, {{cmd|r.info}}, etc.

* {{pyapi|script|script.core|exec_command}} doesn't use <tt>start_command()</tt> but <tt>os.execvpe()</tt>. This causes the specified command to replace the current program (i.e. the Python script), so <tt>exec_command()</tt> never returns. Similar to bash's "exec" command. This can be useful if the script is a "wrapper" around a single command, where you construct the command line and execute the command as the final step. Notes: exec_command() is rarely appropriate. You probably want run_command() instead. On Windows, exec_command() will probably require the ".exe" suffix.

If you have any other questions, you might want to look at the code ({{src|python/grass/script/core.py}}). Most of these functions are only a few lines long.

=== Hints for parse_command() ===

To turn this command
g.rename raster=old_name,new_name
into a g.parse_command() call, you need to consider that it is a function call with three arguments:
# "g.rename"
# raster=old_name
# new_name

The second argument is a keyword argument, the first and third are
positional (non-keyword) arguments. Python doesn't allow positional
arguments to follow keyword arguments; positional arguments come
first, keyword arguments last.

Given the context, it's safe to assume that you want to pass a pair of
map names as the value to the rast= option. This requires explicit
parentheses so that the comma is treated as forming a tuple rather
than as an argument separator:

g.parse_command("g.rename", raster=(old_name,new_name))

The parentheses in a tuple value can only be omitted if it doesn't
result in the comma being ambiguous (as is the case in a function
call).

== Interfacing ==

=== Interfacing with NumPy ===

The {{pyapi|script|script.array|array}} module defines a <code>class array</code> which is a subclass of [http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.html numpy.memmap] that reads/writes the underlying file via {{cmd|r.out.bin}}/{{cmd|r.in.bin}}. Metadata can be read with {{pyapi|script|script.raster|raster_info}}:

Example:

<source lang="python">
import grass.script as grass
import grass.script.array as garray

def main():
map = "elevation"

# read map
a = garray.array(map)

# get raster map info
print(grass.raster_info(map)['datatype'])
i = grass.raster_info(map)

# get computational region info
c = grass.region()
print("rows: %d" % c['rows'])
print("cols: %d" % c['cols'])

# new array for result
b = garray.array()
# calculate new map from input map and store as GRASS raster map
b[...] = (a / 50).astype(int) * 50
b.write("elev.50m")
</source>

The size of the array is taken from the current region ([[computational region]]).

The main drawback of using numpy is that you're limited by available
memory. Using a subclass of <code>numpy.memmap</code> lets you use files which may
be much larger, but processing the entire array in one go is likely to
produce in-memory results of a similar size.

'''NULL (no data) management:'''

For integer maps, the NULL value is -2^31 = -2147483648. For floating-point maps, the NULL value is NaN. Note that the null= parameter for read() and write() specifies the value in the numpy array which is mapped to/from null values in the GRASS raster map.

If you're using floating-point numpy arrays, then use (Note: This assumes that atof() and sscanf("%lf") recognise "nan"; this is the case on Linux, but doesn't appear to work on Windows)
null=numpy.nan

For integer arrays, using
null=-2147483648
will ensure that valid values don't collide with NYLLs.

'''MASK support:'''

Reading and writing use r.out.bin and r.in.bin respectively. r.out.bin respects the MASK.

=== Interfacing with NumPy and SciPy ===

[http://docs.scipy.org/doc/scipy/reference/index.html SciPy] offers simple access to complex calculations. Example:

<source lang="python">
from scipy import stats
import grass.script as grass
import grass.script.array as garray

def main():
map = "elevation"

x = garray.array(map)

# Descriptive Statistics:
print("max, min, mean, var:")
print(x.max(), x.min(), x.mean(), x.var())
print("Skewness test: z-score and 2-sided p-value:")
print(stats.skewtest(stats.skew(x)))
</source>

=== Interfacing with NumPy, SciPy and Matlab ===

One may also use the SciPy - Matlab interface:

r.out.mat input=elevation output=elev.mat

<source lang="python">
### PY ###
import scipy.io as sio
# load data
elev = sio.loadmat('elev.mat')
# retrive the actual array. the data set contains also the spatial reference
elev.get('map_data')
data = elev.get('map_data')
# a first simple plot
import pylab
pylab.plot(data)
pylab.show()
# the contour plot
pylab.contour(data)
# obviously data needs to ne reversed
import numpy as np
data_rev = data[::-1]
pylab.contour(data_rev)
# => this is a quick plot. basemap mapping may provide a nicer map!
#######
</source>

== Usage Examples ==

=== Display example ===
Example of Python script, which is processed by {{cmd|g.parser}}:

<source lang="python">
#!/usr/bin/env python
#
############################################################################
#
# MODULE: d.shadedmap
# AUTHOR(S): Unknown; updated to GRASS 5.7 by Michael Barton
# Converted to Python by Glynn Clements
# PURPOSE: Uses d.his to drape a color raster over a shaded relief map
# COPYRIGHT: (C) 2004,2008,2009 by the GRASS Development Team
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################

#%Module
#% description: Drapes a color raster over a shaded relief map using d.his
#% keyword: display
#% keyword: raster
#%End
#%option
#% key: reliefmap
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of shaded relief or aspect map
#% required : yes
#%end
#%option
#% key: drapemap
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of raster to drape over relief map
#% required : yes
#%end
#%option
#% key: brighten
#% type: integer
#% description: Percent to brighten
#% options: -99-99
#% answer: 0
#%end

import sys
from grass.script import core as grass

def main():
drape_map = options['drapemap']
relief_map = options['reliefmap']
brighten = options['brighten']
ret = grass.run_command("d.his", h_map = drape_map, i_map = relief_map, brighten = brighten)
sys.exit(ret)

if __name__ == "__main__":
options, flags = grass.parser()
main()

</source>

=== Parsing the options and flags ===

{{pyapi|script|script.core|parser}} is an interface to {{cmd|g.parser}}, and allows to parse the ''options'' and ''flags'' passed to your script on the command line. It is to be called at the top-level:

<source lang="python">
if __name__ == "__main__":
options, flags = grass.parser()
main()
</source>

Global variables "options" and "flags" are Python dictionaries containing the options/flags values, keyed by lower-case option/flag names. The values in "options" are strings, those in "flags" are Python booleans. All those variables have to be previously declared in the header of your script.

<source lang="python">
>>> options, flags = grass.parser()
>>> options
{'input': 'my_map', 'output': 'map_out', 'option1': '21.472', 'option2': ''}
>>> flags
{'c': True, 'm': False}
</source>

'''Accessing the --quiet and --verbose flags:'''

See {{pyapi|script|script.core|verbosity}} for the 5 verbosity levels:

<source lang="python">
from grass.script import core as grass

# to hide non-error messages from subprocesses
if grass.verbosity() <= 2:
outdev = open(os.devnull, 'w')
else:
outdev = sys.stdout
</source>

=== Parsing tabular text output ===

Examples in Python for configurable separator for parsing their tabular text output:

* {{src|scripts/m.proj/m.proj.py}}
* {{src|scripts/v.report/v.report.py}}
* {{src|scripts/r.out.xyz/r.out.xyz.py}}
* {{src|scripts/r.tileset/r.tileset.py}}

=== Passing several floats to a single option ===

Example:
<source lang="bash">
python my.module.py input=input output=output myoption=0.1,0.2,0.5
</source>

The values in the "options" dictionary returned from the parser()
function are always strings. You can parse the string with:

<source lang="python">
myoption = map(float, options['myoption'].split(','))
</source>

The option definition in the script should have:

<source lang="python">
#% type: double
#% multiple: yes
</source>

This allows g.parser to validate the option syntax, so you can rely
upon the string being in the correct format. If the values have a
fixed range, you can use e.g.:

<source lang="python">
#% options: 0.0-1.0
</source>

to have the parser check that the values fall within the range.

For more information on option definitions, see:

https://grass.osgeo.org/programming7/gislib.html#Complete_Structure_Members_Table

=== Example for embedding r.mapcalc (map algebra) ===

{{pyapi|script|script.raster|mapcalc}} accepts a template string followed by keyword
arguments for the substitutions, e.g. (code snippets):

<source lang="python">
grass.mapcalc("${out} = ${rast1} + ${rast2}",
out = options['output'],
rast1 = options['raster1'],
rast2 = options['raster2'])
</source>

''Best practice'': first copy all of the options[] into separate variables at the beginning of main(), i.e.:

<source lang="python">
def main():
output = options['output']
raster1 = options['raster1']
raster2 = options['raster2']

...

grass.mapcalc("${out} = ${rast1} + ${rast2}",
out = output,
rast1 = raster1,
rast2 = raster2)
</source>

Performing multiple computations using <tt>grass.script.raster.mapcalc()</tt>:
<source lang="python">
expr = ";".join([
"$out.r = r#$first * $frac + (1.0 - $frac) * r#$second",
"$out.g = g#$first * $frac + (1.0 - $frac) * g#$second",
"$out.b = b#$first * $frac + (1.0 - $frac) * b#$second"])
grass.mapcalc(expr, out=out, first=first, second=second, frac=percent/100.0)
</source>

Hint: multi-line strings can be separated by using a semicolon instead of a newline.

=== Looping over file names stored in an ASCII file ===

When looping over file names stored in an ASCII file and getting the error

WARNING: Illegal filename <map.f1jan.05216.something
>. Character <
> not allowed.

then the line terminators may be the reason.
When you iterate over a file, the strings include the line terminators (e.g. '\n' or '\r\n'). Use e.g.

<source lang="python">
for line in gl:
renamed = line.rstrip().replace('.','_')
...
</source>

to remove any trailing whitespace (including newlines) from each line.

=== Example for parsing raster category labels ===

How to obtain the text labels
<source lang="python">
# dump cats to file to avoid "too many argument" problem:
p = grass.pipe_command('r.category', map = rastertmp, separator = ';', quiet = True)
cats = []
for line in p.stdout:
cats.append(line.rstrip('\r\n').split(';')[0])
p.wait()

number = len(cats)
if number < 1:
grass.fatal(_("No categories found in raster map"))
</source>

=== Example for parsing category numbers ===

'''Q:''' How to obtain the number of cells of a certain category?

'''A:''' It is recommended to use {{pyapi|script|script.core|pipe_command}} and parse the output, e.g.:

<source lang="python">
p = grass.pipe_command('r.stats',flags='c',input='map')
result = {}
for line in p.stdout:
val,count = line.strip().split()
result[int(val)] = int(count)
p.wait()
</source>

=== Example for parsing the region output of a module ===

Some of the GRASS GIS modules are delivering region information (e.g. {{cmd|r.in.xyz}} which scans a LiDAR file for the extent of the point cloud). The retrieved region settings (using '''-g''' flag for script style output) can be parsed in Python:

<source lang="python">
import os
from grass.script import core as gcore

from grass.pygrass.modules.shortcuts import general as g
from grass.pygrass.modules.shortcuts import raster as r

# scan a LiDAR xyz point file for its extent
compregion = gcore.parse_command("r.in.xyz", input="tmp.xyz", separator="space", flags="sg", output="bbox",
parse=(gcore.parse_key_val, {'sep': '=', 'vsep': ' '}))
print(compregion)
# set computational region from LiDAR extent
# hint: we turn here the dictionary to a region by unpacking the dictionary:
g.region(res="1", flags="p", **compregion)
</source>

Note the two '''*''' above which unpack the dictionary (see also the related [https://docs.python.org/2/tutorial/controlflow.html#keyword-arguments Python manual] page).

=== Example for getting the region's number of rows and columns ===

'''Q:''' How to obtain the number of rows and columns of the current region?

'''A:''' It is recommended to use the {{pyapi|script|script.core|region}} function which will create a dictionary with values for extents and resolution, e.g.:

<source lang="python">
#!/usr/bin/env python
#-*- coding:utf-8 -*-
#
############################################################################
#
# MODULE: g.region.resolution
# AUTHOR(S): based on a post at GRASS-USER mailing list [1]
# PURPOSE: Parses "g.region -g", prints out number of rows, cols
# COPYLEFT: ;-)
# COMMENT: ...a lot of comments to be easy-to-read for/by beginners
#
#############################################################################
#
#%Module
#% description: Print number of rows, cols of current geographic region
#% keyword: region
#%end

# importing required modules
import sys # the sys module [2]
from grass.script import core as grass # the core module [3]

# information about imported modules can be obtained using the dir() function
# e.g.: dir(sys)

# define the "main" function: get number of rows, cols of region
def main():

# #######################################################################
# the following commented code works but is kept only for learning purposes

## assigning the output of the command "g.region -g" in a string called "return_rows_x_cols"
# return_rows_x_cols = grass.read_command('g.region', flags = 'g')

## parsing arguments of interest (rows, cols) in a dictionary named "rows_x_cols"
# rows_x_cols = grass.parse_key_val(return_rows_x_cols)

## selectively print rows, cols from the dictionary "rows_x_cols"
# print 'rows=%d \ncols=%d' % (int(rows_x_cols['rows']), int(rows_x_cols['cols']))

# #######################################################################

# faster/ easier way: use of the "grass.region()" function
gregion = grass.region()
rows = gregion['rows']
cols = gregion['cols']

# print rows, cols properly formatted
print 'rows=%d \ncols=%d' % (rows, cols)

# average resolution (in case of non-square pixels)
avg_res=(gregion['nsres'] + gregion['ewres']) / 2.0

# this "if" condition instructs execution of code contained in this script, *only* if the script is being executed directly
if __name__ == "__main__": # this allows the script to be used as a module in other scripts or as a standalone script
options, flags = grass.parser() #
sys.exit(main()) #

# Links
# [1] http://n2.nabble.com/Getting-rows-cols-of-a-region-in-a-script-tp2787474p2787509.html
# [2] http://www.python.org/doc/2.5.2/lib/module-sys.html
# [3] https://grass.osgeo.org/grass78/manuals/libpython
</source>

=== Managing mapsets ===

To check if a certain mapset exists in the active location, use {{pyapi|script|script.core|mapsets}}

<source lang="python">
grass.mapsets(False)
</source>

... returns a list of mapsets in the current location.

=== r.mapcalc example ===

Example of Python script, which is processed by {{cmd|g.parser}}:

The shell script line:

<source lang="bash">
r.mapcalc "MASK = if(($cloudResampName < 0.01000),1,null())"
</source>

would be written like this:

<source lang="python">
import grass.script as grass

...

grass.mapcalc("MASK=if(($cloudResampName < 0.01000),1,null())",
cloudResampName = cloudResampName)
</source>

The first argument to the mapcalc function is a template (see the Python library documentation for [http://docs.python.org/library/string.html string.Template]). Any keyword arguments (other than <tt>quiet</tt>, <tt>verbose</tt> or <tt>overwrite</tt>) specify substitutions.

=== r.mapcalc example: defining a moving window ===

Moving window of 4 cell in every 8 direction and do a boolean comparison. Boolean value (e.g. the result of a comparison) is an integer, with 1 for true, 0 for false.
Then do a r.mapcalc calculation with the moving window.

<source lang="python">

import grass.script as grass

# define a moving window of 4 cell in every 8 direction
#
# map[4,4] map[4,0] map[4,-4]
# map[3,3] map[3,0] map[3,-3]
# map[2,2] map[2,0] map[2,-2]
# map[1,1] map[1,0] map[1,-1]
# map[0,4] map[0,3] map[0,2] map[0,1] x map[0,-1] map[0,-2] map[0,-3] map[0,-4]
# map[-1,1] map[-1,0] map[-1,-1]
# map[-2,2] map[-2,0] map[-2,-2]
# map[-3,3] map[-3,0] map[-3,-3]
# map[-4,4] map[-4,0] map[-4,-4]

# define the offet duplets

offsets = [d
for j in xrange(1,4+1)
for i in [j,-j]
for d in [(i,0),(0,i),(i,i),(i,-i)]]

# >>>offsets
# [(1, 0), (0, 1), (1, 1), (1, -1), (-1, 0), (0, -1), (-1, -1), (-1, 1), (2, 0), (0, 2), (2, 2), (2, -2), (-2, 0), (0, -2), \
# (-2, -2), (-2, 2), (3, 0), (0, 3), (3, 3), (3, -3), (-3, 0), (0, -3), (-3, -3), (-3, 3), (4, 0), (0, 4), (4, 4), (4, -4), \
# (-4, 0), (0, -4), (-4, -4), (-4, 4)]

# define the calculation term

terms = ["(myelevnc[%d,%d] < myelevnc)" % d
for d in offsets]

# >>>terms
# ['(myelevnc[1,0] < myelevnc)', '(myelevnc[0,1] < myelevnc)', '(myelevnc[1,1] < myelevnc)', '(myelevnc[1,-1] < myelevnc)', \
# '(myelevnc[-1,0] < myelevnc)', '(myelevnc[0,-1] < myelevnc)', '(myelevnc[-1,-1] < myelevnc)', '(myelevnc[-1,1] < myelevnc)',\
# '(myelevnc[2,0] < myelevnc)', '(myelevnc[0,2] < myelevnc)', '(myelevnc[2,2] < myelevnc)', '(myelevnc[2,-2] < myelevnc)', \
# '(myelevnc[-2,0] < myelevnc)', '(myelevnc[0,-2] < myelevnc)', '(myelevnc[-2,-2] < myelevnc)', '(myelevnc[-2,2] < myelevnc)', \
# '(myelevnc[3,0] < myelevnc)', '(myelevnc[0,3] < myelevnc)', '(myelevnc[3,3] < myelevnc)', '(myelevnc[3,-3] < myelevnc)', \
# '(myelevnc[-3,0] < myelevnc)', '(myelevnc[0,-3] < myelevnc)', '(myelevnc[-3,-3] < myelevnc)', '(myelevnc[-3,3] < myelevnc)', \
# '(myelevnc[4,0] < myelevnc)', '(myelevnc[0,4] < myelevnc)', '(myelevnc[4,4] < myelevnc)', '(myelevnc[4,-4] < myelevnc)', \
# '(myelevnc[-4,0] < myelevnc)', '(myelevnc[0,-4] < myelevnc)', '(myelevnc[-4,-4] < myelevnc)', '(myelevnc[-4,4] < myelevnc)']

# define the calculation expression

expr = "elevation_percentile4 = (100.0 / 48.0) * (%s)" % " + ".join(terms)

# >>>expr
# elevation_percentile4 = (100.0 / 48.0) * ((myelevnc[1,0] < myelevnc) + (myelevnc[0,1] < myelevnc) + (myelevnc[1,1] < myelevnc) + \
# (myelevnc[1,-1] < myelevnc) + (myelevnc[-1,0] < myelevnc) + (myelevnc[0,-1] < myelevnc) + (myelevnc[-1,-1] < myelevnc) + \
# (myelevnc[-1,1] < myelevnc) + (myelevnc[2,0] < myelevnc) + (myelevnc[0,2] < myelevnc) + (myelevnc[2,2] < myelevnc) + \
# (myelevnc[2,-2] < myelevnc) + (myelevnc[-2,0] < myelevnc) + (myelevnc[0,-2] < myelevnc) + (myelevnc[-2,-2] < myelevnc) + \
# (myelevnc[-2,2] < myelevnc) + (myelevnc[3,0] < myelevnc) + (myelevnc[0,3] < myelevnc) + (myelevnc[3,3] < myelevnc) + \
# (myelevnc[3,-3] < myelevnc) + (myelevnc[-3,0] < myelevnc) + (myelevnc[0,-3] < myelevnc) + (myelevnc[-3,-3] < myelevnc) + \
# (myelevnc[-3,3] < myelevnc) + (myelevnc[4,0] < myelevnc) + (myelevnc[0,4] < myelevnc) + (myelevnc[4,4] < myelevnc) + \
# (myelevnc[4,-4] < myelevnc) + (myelevnc[-4,0] < myelevnc) + (myelevnc[0,-4] < myelevnc) + (myelevnc[-4,-4] < myelevnc)\
# + (myelevnc[-4,4] < myelevnc))

# do the r.mapcalc calculation with the moving window

grass.mapcalc( expr )

</source>

=== Using output from GRASS modules in the script ===

Sometimes you need to use the output of a module for the next step. There are dedicated functions to obtain the result of, for example, a statistical analysis.

Example: get the range of a raster map and use it in {{cmd|r.mapcalc}}. Here you can use {{pyapi|script|script.raster|raster_info}}, e.g.:

<source lang="python">
import grass.script as grass

max = grass.raster_info(inmap)['max']
grass.mapcalc("$outmap = $inmap / $max",
inmap = inmap, outmap = outmap, max = max)
</source>

=== Using output from r.what ===

''Q: How does one return attribute values from a call to the 'r.what' module running in a python script?''

A: If you use <tt>grass.script.raster_what()</tt>, it returns a list of dictionaries.

PyGRASS which requires you to add <tt>stdout_=PIPE</tt>, then you can get the output as a string from <tt>module.outputs.stdout</tt>.

Or using directly the C API through python with (North Carolina dataset example):

<source lang="python">
from grass.pygrass.vector import VectorTopo
from grass.pygrass.raster import RasterRow
from grass.pygrass.gis.region import Region

with RasterRow('elevation', mode='r') as rast:
with VectorTopo('hospitals', mode='r') as hospitals:
region = Region()
for hosp in hospitals:
value = rast.get_value(hosp, region)
if value is not None:
print(hosp.cat, value)
</source>

=== Avoiding a syntax error for r.rescale ===

''Q: How to avoid a syntax error for r.rescale related to "from=" ?

A: "from" is a reserved word, use from_ instead:

<source lang="python">
grass.run_command('r.rescale', input=mis1, output=mis1_8bit, from_='0,2048', to='0,255')
</source>

=== Interface to copying maps (g.copy) ===

Copy a raster map (for vector, replace "rast" with "vect"):

<source lang="python">
grass.run_command('g.copy', rast = (input, output))
</source>

To generalize it, "datatype" is the form of grass data to copy (eg, rast, vect, etc)

<source lang="python">
grass.run_command('g.copy', **{datatype: (input, output)})
</source>

=== Interface to listing maps (g.list) ===

You may use the functions in [https://grass.osgeo.org/grass-stable/manuals/libpython/script.html?highlight=list_grouped#script.core.list_grouped script.core.list_grouped()]:

<source lang="python">
# list all
list_grouped('raster')['PERMANENT']
[..., 'lakes', ..., 'slope', ...

# list with pattern
list_grouped('vect', pattern='*roads*')['PERMANENT']
['railroads', 'roadsmajor']
</source>

For temporal data, see likewise [https://grass.osgeo.org/grass-stable/manuals/libpython/temporal.html?highlight=list_grouped#temporal.gui_support.tlist_grouped temporal.gui_support.tlist_grouped()]

See also [[Python/pygrass#Sample_PyGRASS_scripts|Sample PyGRASS scripts]] for an alternative solution.

=== i.group with patterns as name for input ===

Imagery groups can be populated like this:

<source lang="python">
from grass.pygrass.gis import Mapset

run_command("i.group", group="mygroup", input=mset.glist("raster", pattern="mypattern_*"))
</source>

=== Percentage output for progress of computation ===

A) Within a Python script, the {{pyapi|script|script.core|percent}} module method wraps the <tt>g.message -p</tt> command.

B) If you call a GRASS command within the Python code, you have to parse the output by setting <tt>GRASS_MESSAGE_FORMAT=gui</tt> in the environment when running the command and read from the command's stderr; e.g.

<source lang="python">
import grass.script as grass
env = os.environ.copy()
env['GRASS_MESSAGE_FORMAT'] = 'gui'
p = grass.start_command(..., stderr = grass.PIPE, env = env)
# read from p.stderr
p.wait()
</source>

If you need to capture both stdout and stderr, you need to use threads, select, or non-blocking I/O to consume data from both streams as it is generated in order to avoid deadlock.

ALTERNATIVE:

Redirect both stdout and stderr to the same pipe (and hope that the normal output doesn't include anything which will be mistaken for progress/error/etc messages):

<source lang="python">
p = grass.start_command(..., stdout = grass.PIPE, stderr = grass.STDOUT, env = env)
</source>

=== NULL data management ===

How to analyse if there are only NULL cells in a map:

If a map contains only null cells, its minimum and maximum will be "NULL":

<source lang="bash">
$ r.mapcalc 'foo = null()'
$ r.info -r foo
min=NULL
max=NULL
</source>

Using the Python API, The 'min' and 'max' values in the result of the {{pyapi|script|script.raster|raster_info}} function will be <tt>None</tt>.

=== Counting cells ===

Counting cells is far more expensive than simply determining whether
there are any non-null cells. Counting cells requires reading the
entire map, while the {{cmd|r.info}} approach only needs to read the metadata
files.

If you do need to count cells, {{cmd|r.stats}} is likely to be more efficient than {{cmd|r.univar}}.

A count loop:

<source lang="python">
while grass.raster_info(inmap)['max'] is not None:
...
</source>

=== Display: overlayed map display with labels ===

Example: display a vector map and overlay its labels on top of the map.

If the environment contains the setting GRASS_PNG_READ=TRUE, d.* commands should overlay their output on an existing image (otherwise the first command creates the file map.png but the second command overwrites the file with only the labels). So the following should work:

<source lang="python">
grass.run_command('d.vect', map='my_shape')
env = os.environ.copy()
env['GRASS_PNG_READ'] = 'TRUE'
grass.run_command('d.labels', labels='my_shape_labels', env = env)
</source>

=== Path to GISDBASE ===
In order to a avoid hardcoded paths to GRASS mapset files like the SQLite DB file, you can get the GISDBASE variable from the environment:
<source lang="python">
import grass.script as grass
import os.path

env = grass.gisenv()

gisdbase = env['GISDBASE']
location = env['LOCATION_NAME']
mapset = env['MAPSET']

path = os.path.join(gisdbase, location, mapset, 'sqlite.db')
</source>

=== Parse the GRASS GIS version or revision or path to library ===

In order to a avoid hardcoded versions or to scan the SVN revision of the GRASS GIS version used, you can query the {{cmd|helptext|startup script}}:

'''Variant 1 (pure Python solution) - svn_revision:'''

<source lang="python">
import subprocess
cmd = subprocess.Popen('grass78 --config svn_revision', shell=True, stdout=subprocess.PIPE)
revision = cmd.communicate()[0].rstrip()
print(revision)
# the result is for example: '72327'.
</source>

'''Variant 2 (GRASS GIS-Python solution) - svn_revision:'''

<source lang="python">
import subprocess
import grass.script as grass
cmd = grass.Popen('grass78 --config svn_revision', shell=True, stdout=subprocess.PIPE)
revision = cmd.communicate()[0].rstrip()
print(revision)
# the result is for example: '72327'.
</source>

'''Path to GRASS GIS library (GRASS GIS-Python solution):'''

<source lang="python">
import subprocess
import grass.script as grass
cmd = grass.Popen('grass78 --config path', shell=True, stdout=subprocess.PIPE)
version = cmd.communicate()[0].rstrip()
print(version)
# the result is for example: '/usr/local/grass-7.6.svn'
</source>

=== Creating a new location ===

Use {{pyapi|script|script.core|create_location}} to create a new location.

=== Use Python reserved keyword ===

'''Q:''' ''r.resamp.bspline'' uses 'lambda' as a command line parameter name, but when you try to use it with {{pyapi|script|script.core|run_command}} or {{pyapi|script|script.core|start_command}} you get an error as lambda is a python reserved keyword. How to work around that?

'''A:''' Append an underscore to the name, i.e.:

<source lang="python">
grass.run_command('r.resamp.bspline', lambda_ = ...)
</source>

Note that this follows Python [http://legacy.python.org/dev/peps/pep-0008/#descriptive-naming-styles PEP8] style guide. In GRASS GIS version 6, you have to prepend the underscore.

=== Controlling the PNG display driver ===

Code fragment to control the {{cmd|pngdriver}} in Python:

<source lang="python">
import os
import sys
from grass.script import core as grass
def main():
os.environ['GRASS_PNGFILE'] = filename
os.environ['GRASS_WIDTH'] = str(width)
os.environ['GRASS_HEIGHT'] = str(height)
grass.run_command('d.his', i='elevation_shade', h='elevation')
</source>

=== Sophisticated cleanup procedure ===

Scripts which create several temporary files need a more sophisticated cleanup procedure which deletes all the tmp maps which have been created. This procedure should also work if the script stops (e.g due to an error).

Solution: Define a list of map names which starts out empty and has names appended to it as the names are generated. Code fragment:

<source lang="python">
import atexit, sys
import grass.script as grass

tmp_rast = []

def cleanup():
for rast in tmp_rast:
grass.run_command("g.remove",
flags = 'f',
type = 'raster',
name = rast,
quiet = True)

def main():
...
while ...:
next_rast = ...
tmp_rast.append(next_rast)
...

if __name__ == "__main__":
options, flags = grass.parser()
atexit.register(cleanup)
sys.exit(main())
</source>

=== Using temporary region for computations ===

There are two possible ways how to define temporary region for raster-based computations within your scripts. First method uses environmental variable WIND_OVERRIDE, the second GRASS_REGION, see {{cmd|variables|desc=GRASS variables}} for more info. The key point is to recover the current region when the script is finished or terminated.

* ''First method'' (WIND_OVERRIDE) is implemented as {{pyapi|script|script.core|use_temp_region}}

<source lang=python>
import grass.script as grass

# store the current region settings and installs an atexit
# handler to recover the current region on script termination
grass.use_temp_region()

grass.run_command('g.region', region='detail')

grass.mapcalc('map = 1', overwrite=True)

# after making operations using the temporary region,
# to unset the temporary WIND_OVERRIDE file and remove any
# region named by it, it is possible to use del_temp_region
grass.del_temp_region()
</source>

* ''Second method'' (GRASS_REGION) doesn't store current region settings to any temporary region, it just defines GRASS_REGION which forces GIS Library to use this settings for raster-based computations instead of the settings stored in WIND file (ie. current region). See {{pyapi|script|script.core|region_env}}.

<source lang=python>
import os
import grass.script as grass

# copy environment and define GRASS_REGION environmental variable
# same as `g.region region=detail`
env = os.environ.copy()
env['GRASS_REGION'] = grass.region_env(region='detail')

grass.mapcalc('map = 1', overwrite=True, env=env)
</source>

=== Using predefined constants ===

Some constants are wrapped from C to Python through ctypes.

Example:

<source lang=python>
from grass.lib.gis import GRASS_EPSILON
GRASS_EPSILON
1e-15
</source>

=== Getting a list of wrapped C functions and constants ===

<source lang=python>
import pprint
import grass.lib.gis as grass_gis

# simple list
dir(grass_gis)

# pretty printing
pprint.pprint(dir(grass_gis))
</source>

== Direct Access from wxGUI ==

[[wxGUI]] Layer Manager in GRASS GIS comes with "Python shell" which enables users to type and execute python commands directly in wxGUI environment.

[[Image:wxgui-pyshell.png|center|400px|Embedded interactive Python Shell in wxGUI Layer Manager]]

== See also ==

* [[GRASS GIS Jupyter notebooks]]
* [[Working with GRASS without starting it explicitly‎]]
* Many more tutorials under [[:Category:Python]]