GRASS 8 planning: ideas

For now just a brainstorming zone...

General

• Naming: GISDBASE versus grassdata versus GRASS Database versus GRASS Database Directory versus GRASS GIS Database versus GRASS GIS Spatial Database
  • 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', then location, and then mapset."
  • 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)

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)

Discussions at Aug 2017:

• add tile support for better large map support (Sentinel, global data, ...), supporting massive parallel computations
  • tiles could then be even stored on different nodes for speed optimization
  • e.g. develop a new virtual raster mapset "VRT" (special like PERMANENT)
    • reading:
      • 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
• ...

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

GUI

• review (again) startup window, setting database/location/mapset, initial (default) location
• single window interface as an option (first step: moving code to controller classes and panels)
• 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

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