GRASS 8 planning: ideas

For now just a brainstorming zone...

General

Naming of GRASS Database

• GISDBASE versus grassdata versus GRASS Database versus GRASS Database Directory versus GRASS GIS Database versus GRASS GIS Spatial Database versus GIS Data Directory
  • The Data tab (Data Catalog), avoids it altogether (in 7.4) and says "GRASS locations in /abs/path/here"
• Problem 1: It is hard to understand for beginners that the messing with the data in "grassdata" is not useful and can be harmful.
• Problem 2: Non-unix users confuse current working directory with "grassdata".
• Problem 3: The same things is referred to in different ways (GISDBASE, grassdata, GRASS Database Directory, dbase).
• 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."
• Problem 5: When setting up "GRASS session" manually, e.g. in Python, GISBASE and GISDBASE look too much alike.
• 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).
• Outcome: Consistent naming of "grassdata" in doc, GUI, API (measurable). Clear way of creating instructions for beginners. Improved understating of the concept (long-term).
• 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)
• Consistency is perhaps the main thing needed:
  • GISDBASE is an environment variable and an abbreviated form of "GRASS GIS Database",
  • "dbase=" is an argument to change GISDBASE in several modules (e.g. g.mapset, r.reproject, etc),
  • "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.
  • The modules that change GISDBASE should have arguments of "gisdbase=", not "dbase=". That would alleviate considerable confusion
  • 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.

Naming of Location

• replace the term location (Location, LOCATION)
• See wiki:wxGUIDevelopment/New_Startup and ​grass-dev: a proposal to rename location.
• Related: #2681 Remove legacy meaning of LOCATION variable

grass executable

• Refer to it as grass in the documentation to avoid rewriting grass6 to grass7 to grass8 (or even with minor versions). Request/require packagers to create grass command (they already often do that).
• Use the general "Linux" (POSIX+GNU) standard for options/flags/parameters (of the executable).
  • For example, use -c and --create rather than -create, i.e. avoid long flag to have one dash and provide both alternatives.
  • Supporting current/legacy syntax like -text and -gui might be too difficult (definitely remove from manual).
  • Same for module-like syntax which could be supported as well, e.g. supporting both --create=EPSG:3358 and create=EPSG:3358.
  • Require the order of arguments/operands to be correct (now not enforced).
  • Only exception to the rule should be --help.
  • Possibly use one of Python libraries (​argparse >2.7 and >3.2, ​https://docs.python.org/3.6/library/optparse.html in 2.6 and 3.8? but deprecated since 2.7, ​getopt not recommended for general use).
  • The two dash long options (such as --text) are now in help, messages, and documentation (see r73100, r73263, r73265, and #1665). The one dash long ones (such as -text) are still allowed, but not advertised. The one letter only ones (such as -c) still don't have long equivalent and vice versa).
• Unify GRASS_BATCH_JOB with --exec (don't use the shell=True for it) or possibly depreciate, or even remove it. (Goal: Simpler documentation and implementation.)

Color tables

• There is a lot of color tables. Are all useful? Some are perceptually uniform, but some are quite simple. Are all good enough? For example, Matplotlib has much more color tables. Are we missing some?
• Make clear and easy how users can store and share color tables in a simple way.
• Make the GUI more clear, e.g. integrate the custom color table dialog into the r.colors/... dialogs.

Modules

• Add modules with (pseudo-)random outputs like G7:r.mapcalc with rand() should use seed= to set the seed and -s to get random, non-deterministic result.

Raster library

• organization of raster file storage layout: have one raster folder per map like for vector data or raster3D
  • for fp maps: move fcell to cell, eliminating empty cell file
• implement GRASS_RASTER_TMPDIR_MAPSET like it exists for vector data (GRASS_VECTOR_TMPDIR_MAPSET), i.e. change all .tmp/ to variable in source code in init/grass.py, gis/open.c, gis/file_name.c, raster library
• maintain history as it is already for vector maps
• synchronize metadata between raster and vector maps
• keep track of open raster maps (already done in the R structure)
• Storage in tiles instead of by row (See Grass7/RasterLib)
• Merge NULL file into main data array (See Grass7/RasterLib)
• save more raster metadata like number of non-null cells, mean and stddev (see GDAL)
• Mask:
  • Add support for writing raster data (not only reading)
  • Create a Python and C functions to test its presence (like for 3D mask in C)
  • Add C define specifying its name (like for 3D mask)
  • Add environmental variable similar to WIND_OVERRIDE or GRASS_REGION to use something else as a mask
• add tile support for better large map support (Sentinel, global data, ...), supporting massive parallel computations (based on discussions from Aug 2017)
  • it must be clear why this would better than GDAL vrt combined with r.external
  • tiles could then be even stored on different nodes for speed optimization
  • storage implementation:
    • develop a new virtual raster mapset "VRT" (special like PERMANENT)
    • virtual map: combination between current groups/stds and external maps - map metadata link the other maps, possibly in other mapset (Vaclav: I suggest this (vrt map) rather than vrt mapset or low level (i.e. new format) tiling)
      • something like the segment library opens the appropriate "standard" raster maps
      • different storage nodes possible if maps are different mapsets which are on diff nodes
  • reading:
    • [the above options or] add tile support deeply into raster lib (Rast_get_row())
    • use name scheme? make use of segment library
    • problem: due to row compression always whole row is read even if computation region is smaller
  • writing:
    • it is more complex

Imagery library

• get rid of subgroups. No real need for that... (but overcomplication of usage)
  • or strengthen subgroups. One of options could be auto creating some "magic" subgroups as i.e. "_all" - all raster maps in a group (aka if subgroup is not set, use all maps from group); "_initial" - only imported remote sensing layers (equals "_all" if no new maps are added later); "RGB" - if source is RGB or RGB can be defined (I would love to be able to have an option to choose a group in d.rgb and get RGB subgroup selected as a default instead of searching for separate channels); "MLC" subgroup - see #2483.

Vector library

• keep track of opened vector maps
• keep track of dblinks to not remove table connected to multiple vector maps
• get rid of dbf as database backend
• portability and attribute file management would be much easier if each vector map had its own SQLite database (with the potential for multiple tables) rather than a single database for all vectors and their tables (layers) for the entire mapset
• ...

Python library

• finalize/stabilize Python 3 support
• simplify the startup from Python script (i.e. less steps to start session from Python, possibly includes change in distribution/installation)
• remove deprecated Python functions: ​https://trac.osgeo.org/grass/changeset/67669
• Split grass.pygrass into ctypes-dependent C library wrappers and ctypes-independent module handling.
  • The functionality is not related. The reason why it is together is that it was implemented at the same time.
  • Problems with ctypes should not influence the running the modules.
• Address the confusion between grass as the GRASS GIS Python library and PyGRASS. pygrass seems to be name for everything as py like this usually means Python, but in pygrass the idea was to mean Pythonic as opposed to shell/bash-like grass.script.

GUI

• review (again) startup window, setting database/location/mapset, initial (default) location (wiki:wxGUIDevelopment/New_Startup)
• single window interface as an option (first step: moving code to controller classes and panels) (wiki:wxGUIDevelopment/SingleWindow)
• avoid the need for setting up path to packaged before imports (now we need to mix code and imports), e.g. grassgui package next to grass package
• integrated Addon and GUI toolboxes
• consistently inform user about whether or not an operation uses current computational region

Display modules

• Clarify position of ximgview/wximgview, e.g. integrate them into d.mon. (They are easy to miss and separated from the rest of the functionality.)

Manual pages

• generate Sphinx manuals (rst converter is already in man/)

Bug reports

Blockers

defect type tickets:

#3023

Change default behavior of d.title to draw instead of output text

#3055

Revise monochromatic color tables

task type tickets:

#969

move color structs to colors.h?

#2681

Remove legacy meaning of LOCATION variable

Critical issues

No results

Further issues

• Check overview in: ​https://trac.osgeo.org/grass/milestone/8.0.0