GRASS GIS at OSGeo Community Sprint 2022: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(→‎Goals: sub-sections instead of nested lists for easier editing)
Line 27: Line 27:
== Goals ==
== Goals ==


* Wolf:
=== Wolf ===
** Finish issues [https://github.com/OSGeo/grass/issues/942 #942] [https://github.com/OSGeo/grass/issues/753 #753] [https://github.com/OSGeo/grass/issues/964 #964] - A unified colorful prompt across all shells
* Finish issues [https://github.com/OSGeo/grass/issues/942 #942] [https://github.com/OSGeo/grass/issues/753 #753] [https://github.com/OSGeo/grass/issues/964 #964] - A unified colorful prompt across all shells
*** I need help with windows for testing if color works as expected
** I need help with windows for testing if color works as expected
*** Get clarification on whether issue #970 is up for grabs
** 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 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.''
=== Discuss naming and presentation of GRASS GIS data hierarchy ===
** location and mapset -> project and subproject
* 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.''
** GRASS database (GISDBASE, database directory) -> not needed as a prominent concept; a path, directory (folder) which happens to have one or more projects
* location and mapset -> project and subproject
** More than just a rename, but different presentation.
* GRASS database (GISDBASE, database directory) -> not needed as a prominent concept; a path, directory (folder) which happens to have one or more projects
** g.project.switch (or g.switch.project) - change current project or subproject
* More than just a rename, but different presentation.
** g.search.path - manage visibility of data in other subprojects  
* g.project.switch (or g.switch.project) - change current project or subproject
** g.mapset and g.mapsets kept for backwards compatibility
* g.search.path - manage visibility of data in other subprojects  
** grass.script.setup.init - add project and subproject keyword arguments; keep location and mapset
* g.mapset and g.mapsets kept for backwards compatibility
** 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
* grass.script.setup.init - add project and subproject keyword arguments; keep location and mapset
** PERMANENT
* 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 versus temporary confusion
* PERMANENT
*** alternative names: default, base, main (if common files are moved to location, there is no need for a specific name at all)  
** permanent versus temporary confusion
*** also as a default subproject (mapset)? Path to project (location) would translate to project/{default}, e.g., project/PERMANENT
** 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 ==
== Reports ==

Revision as of 08:27, 27 August 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

  • ...

See also