Replacement raster format: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(+category MoveToTrac)
(moved to trac)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{MoveToTrac}}
{{MovedToTrac|Grass7/RasterLib}}
  GRASS's long-standing raster format is overdue for a major overhaul.<BR>
  Below you will find some ideas and roadmaps for future work.<BR>
  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.<BR>
  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.
 
__TOC__
 
see also [[GRASS 7 ideas collection#Raster]]
 
==== Core raster format ====
''Lead developer: Glynn Clements''
 
* Storage in tiles instead of by row.
** Reasoning:  Glynn said on the mailing list: "In most cases, single-level tiled storage will give you close to the same performance with a lot less complexity."
** Function needed to check whether tiles are all null, or all the same value.
** What tile size should be used? Could be user/program specified, or standard value of something like 64x64. If there isn't a fixed value then there should be utility program that can convert tiled rasters to different tile sizes. - [[User:Ferrouswheel|Ferrouswheel]]
* Merge NULL file into main data array.
 
==== Directory structure ====
 
* Centralize map components in "<tt>$MAPSET/raster/$MAPNAME/*</tt>" instead of many "<tt>$MAPSET/cell/$MAPNAME</tt>", etc. directories.
 
Many library functions and modules will need to be updated.
The GRASS 6 vector format has already been ported to this structure.
 
* demo 2-way conversion scripts: [http://wald.intevation.org/tracker/index.php?func=detail&aid=372&group_id=21&atid=205 Gforge patch #372]
 
==== Meta-data support ====
 
The existing raster meta-data handling is rather weak.
(currently stored in <tt>$MAPSET/hist/$MAPNAME</tt>)
Total replacement will be the best option.
 
Brad Douglas suggests:
  ''It would be very advantageous to at least support metadata as specified
  in [http://www.fgdc.gov/standards/projects/FGDC-standards-projects/csdgm_rs_ex/MetadataRemoteSensingExtens.pdf FGDC-STD-012-2002].
  XML is an ideal file format.''
 
Nick Lawrence suggests:
The GIMP project is examining the concept of a general mult-layer bitmap format.
 
[http://create.freedesktop.org/wiki/index.php/General_multilayered_bitmap_exchange_format OpenRaster - Create Wiki]
[http://pippin.gimp.org/OpenRaster/ OpenRaster Sandbox]
 
 
Other suggestions:
* [[Time series in GRASS]] support
 
[[Category:Development]]

Latest revision as of 19:56, 24 April 2010