| 7 | | * Naming: ''GISDBASE'' versus ''grassdata'' versus ''GRASS Database'' versus ''GRASS Database Directory'' versus ''GRASS GIS Database'' versus ''GRASS GIS Spatial Database'' |
| 8 | | * Problem 1: It is hard to understand for beginners that the messing with the data in "grassdata" is not useful and can be harmful. |
| 9 | | * Problem 2: Non-unix users confuse current working directory with "grassdata". |
| 10 | | * Problem 3: The same things is referred to in different ways (GISDBASE, grassdata, GRASS Database Directory, dbase). |
| 11 | | * Problem 4: Instructions often say "set your location and mapset" while they mean "set 'database directory', then location, and then mapset, and optionally also working directory." |
| 12 | | * Problem 5: When setting up "GRASS session" manually, e.g. in Python, GISBASE and GISDBASE look too much alike. |
| 13 | | * Solution: Make it clear that users are dealing with a database and while also emphasizing that the database is spatial as opposed to just attributes (as in GIS vector/spreadsheet tables). |
| 14 | | * Outcome: Consistent naming of "grassdata" in doc, GUI, API (measurable). Clear way of creating instructions for beginners. Improved understating of the concept (long-term). |
| 15 | | * Challenges: name length, strong legacy ("GISDBASE" on many places), backwards compatibility (API changes), convention (such as grassdata) versus naming, different internal naming, relation to location and mapset, GRASS versus GRASS GIS, lowercase letters (as in thing, concept) versus uppercase (as in file format) |
| 16 | | * Consistency is perhaps the main thing needed: |
| 17 | | * GISDBASE is an environment variable and an abbreviated form of "GRASS GIS Database", |
| 18 | | * "dbase=" is an argument to change GISDBASE in several modules (e.g. g.mapset, r.reproject, etc), |
| 19 | | * "grassdata" is a commonly used name of a directory that serves as a GRASS GIS Database. However, a person can have more than one GIS Database or may want to give it a different name. That should be OK. |
| 20 | | * The modules that change GISDBASE should have arguments of "gisdbase=", not "dbase=". That would alleviate considerable confusion |
| 21 | | * When referring to the GIS Database in the interface, we should use the term "GIS Database" (or something similar) consistently. Again, consistency can help with confusion here. |
| 22 | | * Naming: replace the term location (Location, LOCATION) |
| 23 | | * See wiki:wxGUIDevelopment/New_Startup and [https://lists.osgeo.org/pipermail/grass-dev/2018-June/088531.html grass-dev: a proposal to rename location].'' |
| 24 | | * Related: #2681 Remove legacy meaning of LOCATION variable |
| | 7 | ==== Naming of GRASS Database ==== |
| | 8 | |
| | 9 | * ''GISDBASE'' versus ''grassdata'' versus ''GRASS Database'' versus ''GRASS Database Directory'' versus ''GRASS GIS Database'' versus ''GRASS GIS Spatial Database'' versus ''GIS Data Directory'' |
| | 10 | * The Data tab (Data Catalog), avoids it altogether (in 7.4) and says "GRASS locations in /abs/path/here" |
| | 11 | * Problem 1: It is hard to understand for beginners that the messing with the data in "grassdata" is not useful and can be harmful. |
| | 12 | * Problem 2: Non-unix users confuse current working directory with "grassdata". |
| | 13 | * Problem 3: The same things is referred to in different ways (GISDBASE, grassdata, GRASS Database Directory, dbase). |
| | 14 | * Problem 4: Instructions often say "set your location and mapset" while they mean "set 'database directory', then location, and then mapset, and optionally also working directory." |
| | 15 | * Problem 5: When setting up "GRASS session" manually, e.g. in Python, GISBASE and GISDBASE look too much alike. |
| | 16 | * Solution: Make it clear that users are dealing with a database and while also emphasizing that the database is spatial as opposed to just attributes (as in GIS vector/spreadsheet tables). |
| | 17 | * Outcome: Consistent naming of "grassdata" in doc, GUI, API (measurable). Clear way of creating instructions for beginners. Improved understating of the concept (long-term). |
| | 18 | * Challenges: name length, strong legacy ("GISDBASE" on many places), backwards compatibility (API changes), convention (such as grassdata) versus naming, different internal naming, relation to location and mapset, GRASS versus GRASS GIS, lowercase letters (as in thing, concept) versus uppercase (as in file format) |
| | 19 | * Consistency is perhaps the main thing needed: |
| | 20 | * GISDBASE is an environment variable and an abbreviated form of "GRASS GIS Database", |
| | 21 | * "dbase=" is an argument to change GISDBASE in several modules (e.g. g.mapset, r.reproject, etc), |
| | 22 | * "grassdata" is a commonly used name of a directory that serves as a GRASS GIS Database. However, a person can have more than one GIS Database or may want to give it a different name. That should be OK. |
| | 23 | * The modules that change GISDBASE should have arguments of "gisdbase=", not "dbase=". That would alleviate considerable confusion |
| | 24 | * When referring to the GIS Database in the interface, we should use the term "GIS Database" (or something similar) consistently. Again, consistency can help with confusion here. |
| | 25 | |
| | 26 | ==== Naming of Location ==== |
| | 27 | |
| | 28 | * replace the term location (Location, LOCATION) |
| | 29 | * See wiki:wxGUIDevelopment/New_Startup and [https://lists.osgeo.org/pipermail/grass-dev/2018-June/088531.html grass-dev: a proposal to rename location].'' |
| | 30 | * Related: #2681 Remove legacy meaning of LOCATION variable |
