| | 5 | === General === |
| | 6 | |
| | 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', then location, and then mapset." |
| | 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) |
