Replacement raster format: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(init)
 
mNo edit summary
Line 4: Line 4:
   specification so that when the change occurs, all the
   specification so that when the change occurs, all the
   components will be in place, pitfalls expected, and
   components will be in place, pitfalls expected, and
   implimentation, when it comes, quick and painless. Most
   the implimentation, when it comes, quick and painless. Most
   importanly it can serve to keep interested parties informed
   importanly it can serve to keep interested parties informed
   and working together instead of in parallel forks.<BR>
   and working together instead of in parallel forks.<BR>

Revision as of 07:13, 3 June 2006

 GRASS's long-standing raster format is overdue for a major overhaul.
Below you will find some ideas and roadmaps for future work.
The idea of this page is to collect ideas and flesh out a specification so that when the change occurs, all the components will be in place, pitfalls expected, and the implimentation, when it comes, quick and painless. Most importanly it can serve to keep interested parties informed and working together instead of in parallel forks.
Any changes to the data format will necessitate a bump in major version number (i.e. from GRASS 6 to GRASS 7) so if possible changes should happen in the same development cycle, and relatively minor changes should be held back in experimental status until a major change is committed.

Core raster format

Lead developer: Glynn Clements

  • Storage in tiles instead of by row.
  • Merge NULL file into main data array.


Directory structure

  • Centralize map components in "$MAPSET/raster/$MAPNAME/*" instead of many "$MAPSET/cell/$MAPNAME",etc. directories.

    Many library functions and modules will need to be updated.
    The GRASS 6 vector format has already been ported to this structure.


Meta-data support

The existing raster meta-data handling is rather weak. (currently stored in $MAPSET/hist/$MAPNAME) Total replacement will be the best option.

Brad Douglas suggests:

 It would be very advantageous to at least support metadata as specified in
 FGDC-STD-012-2002.
 XML is an ideal file format.