|
|
| (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]]
| |