GRASS 8 planning: ideas

For now just a brainstorming zone...

Raster library

• organization of raster file storage layout: have one raster folder per map like for vector data or raster3D
• 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
• keep track of open raster maps
• 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)

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

• 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

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