https://grasswiki.osgeo.org/w/api.php?action=feedcontributions&feedformat=atom&user=%E2%9A%A0%EF%B8%8FNick+LawrenceGRASS-Wiki - User contributions [en]2026-05-25T15:57:07ZUser contributionsMediaWiki 1.41.0https://grasswiki.osgeo.org/w/index.php?title=Replacement_raster_format&diff=4096Replacement raster format2007-04-19T23:49:43Z<p>⚠️Nick Lawrence: </p>
<hr />
<div> GRASS's long-standing raster format is overdue for a major overhaul.<BR><br />
Below you will find some ideas and roadmaps for future work.<BR><br />
The idea of this page is to collect ideas and flesh out a<br />
specification so that when the change occurs, all the<br />
components will be in place, pitfalls expected, and<br />
the implimentation, when it comes, quick and painless. Most<br />
importanly it can serve to keep interested parties informed<br />
and working together instead of in parallel forks.<BR><br />
Any changes to the data format will necessitate a bump in<br />
major version number (i.e. from GRASS 6 to GRASS 7) so if<br />
possible changes should happen in the same development cycle,<br />
and relatively minor changes should be held back in<br />
experimental status until a major change is committed.<br />
<br />
__TOC__<br />
<br />
==== Core raster format ====<br />
''Lead developer: Glynn Clements''<br />
<br />
* Storage in tiles instead of by row.<br />
** 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."<br />
** Function needed to check whether tiles are all null, or all the same value.<br />
** 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]]<br />
* Merge NULL file into main data array.<br />
<br />
==== Directory structure ====<br />
<br />
* Centralize map components in "<tt>$MAPSET/raster/$MAPNAME/*</tt>" instead of many "<tt>$MAPSET/cell/$MAPNAME</tt>",etc. directories.<BR><BR>Many library functions and modules will need to be updated.<BR>The GRASS 6 vector format has already been ported to this structure.<br />
<br />
<br />
==== Meta-data support ====<br />
<br />
The existing raster meta-data handling is rather weak.<br />
(currently stored in <tt>$MAPSET/hist/$MAPNAME</tt>)<br />
Total replacement will be the best option.<br />
<br />
Brad Douglas suggests:<br />
''It would be very advantageous to at least support metadata as specified<br />
in [http://www.fgdc.gov/standards/projects/FGDC-standards-projects/csdgm_rs_ex/MetadataRemoteSensingExtens.pdf FGDC-STD-012-2002].<br />
XML is an ideal file format.''<br />
<br />
Nick Lawrence suggests:<br />
The GIMP project is examining the concept of a general mult-layer bitmap format.<br />
<br />
[http://create.freedesktop.org/wiki/index.php/General_multilayered_bitmap_exchange_format OpenRaster - Create Wiki]<br />
[http://pippin.gimp.org/OpenRaster/ OpenRaster Sandbox]<br />
<br />
<br />
[[Category:Development]]</div>⚠️Nick Lawrencehttps://grasswiki.osgeo.org/w/index.php?title=User:Nick_Lawrence&diff=4093User:Nick Lawrence2007-04-19T06:30:30Z<p>⚠️Nick Lawrence: </p>
<hr />
<div>Nick Lawrence</div>⚠️Nick Lawrence