GRASS GIS at OSGeo Community Sprint 2022
OSGeo Community Sprint 2022, Florence, Aug 27-28, 2022.
Introduction
Participation is free of charge and anyone involved or interested in getting involved in OSGeo community projects is welcome.
This year we will try to offer the format an hour with the developer, where we ask seasoned community members to donate time for welcoming new members and introduce them to different projects or guide them through the setup of the development environment or translation tools and get started on the Foss4G journey.
You can choose to contribute to one or more projects. The sky is the limit. There’s always plenty to do – and it’s not all about programming. Translation, documentation, feedback, discussions, and testing are very important for projects! Conference registration is not a prerequisite for participation in the code sprint.
When
The code sprint will be held on 27-28 of August.
Where
The codesprint will be hosted at the University of Florence.
- Centro Didattico Morgagni UniFi in Viale Morgagni 42 -- 44 Firenze (map).
Goals
Wolf
- Finish issues #942 #753 #964 - A unified colorful prompt across all shells
- I need help with windows for testing if color works as expected
- Get clarification on whether issue #970 is up for grabs
- Discuss with Vaclav about introducing sub commands into grass.py, and maybe get it started.
Discuss naming and presentation of GRASS GIS data hierarchy
- Kladivova, Petrasova, Petras, Landa (2022, not published): GRASS GIS was conceived from its very beginning as a powerful geospatial computing tool that emphasized data integrity to deliver accurate results. To achieve consistent results when working with data from different sources, GRASS GIS requires the data to be imported into GRASS data storage and reprojected into a common coordinate reference system (CRS) predetermined by the user for each project. Within each project, called location, data are further organized into subprojects, called mapsets, used for managing different subregions or analyses. Additionally, mapsets have distinct processing settings such as computational extent and resolution. The directory with one or more locations is referred to as GRASS database and is typically named grassdata.
- location and mapset -> project and subproject
- GRASS database (GISDBASE, database directory) -> not needed as a prominent concept; a path, directory (folder) which happens to have one or more projects
- More than just a rename, but different presentation.
- g.project.switch (or g.switch.project) - change current project or subproject
- g.search.path - manage visibility of data in other subprojects
- g.mapset and g.mapsets kept for backwards compatibility
- grass.script.setup.init - add project and subproject keyword arguments; keep location and mapset
- Workspace file (.gxw) -> automatically created in each subproject with the last used GUI state, but still needs to be available as now for things like 3D animations and g.print.ws
- PERMANENT
- permanent versus temporary confusion
- alternative names: default, base, main (if common files are moved to location, there is no need for a specific name at all)
- also as a default subproject (mapset)? Path to project (location) would translate to project/{default}, e.g., project/PERMANENT
Reports
Saturday
You
- ...
Sunday
You
- ...