Changes between Version 56 and Version 57 of Grass7/RasterLib


Ignore:
Timestamp:
Apr 24, 2010, 1:03:21 PM (14 years ago)
Author:
martinl
Comment:

fixes

Legend:

Unmodified
Added
Removed
Modified

  • Grass7/RasterLib

    v56 v57  
    1414GRASS's long-standing raster format is overdue for a major overhaul.
    1515
    16  Below you will find some ideas and roadmaps for future work.
     16Below you will find some ideas and roadmaps for future work.
    1717
    18  The idea of this page is to collect ideas and flesh out a
    19  specification so that when the change occurs, all the
    20  components will be in place, pitfalls expected, and
    21  the implimentation, when it comes, quick and painless. Most
    22  importanly it can serve to keep interested parties informed
    23  and working together instead of in parallel forks.
     18The idea of this page is to collect ideas and flesh out a
     19specification so that when the change occurs, all the
     20components will be in place, pitfalls expected, and
     21the implementation, when it comes, quick and painless. Most
     22importantly it can serve to keep interested parties informed
     23and working together instead of in parallel forks.
    2424
    25  Any changes to the data format will necessitate a bump in
    26  major version number (i.e. from GRASS 6 to GRASS 7) so if
    27  possible changes should happen in the same development cycle,
    28  and relatively minor changes should be held back in
    29  experimental status until a major change is committed.
     25Any changes to the data format will necessitate a bump in
     26major version number (i.e. from GRASS 6 to GRASS 7) so if
     27possible changes should happen in the same development cycle,
     28and relatively minor changes should be held back in
     29experimental status until a major change is committed.
    3030}}}
    3131
    … …  
    3434''Lead developer: Glynn Clements''
    3535
    36  * Storage in tiles instead of by row.
    37   * 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."
     36 * Storage in '''tiles''' instead of by row
     37  * 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."
    3838  * Function needed to check whether tiles are all null, or all the same value.
    39   * 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. -
     39  * 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.
    4040   * However, row-oriented storage has the advantage that you can easily skip entire rows when downsampling. Using e.g. 64x1 "tiles" would provide both optimisations, but at the expense of reduced compression, as you need a pointer (8 bytes) for each tile, and the compression has to be restarted for each tile.
    4141 * Merge NULL file into main data array.
    … …  
    4343=== Directory structure ===
    4444
    45  * 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.
     45 * 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.
    4646 * demo 2-way conversion scripts: [http://wald.intevation.org/tracker/index.php?func=detail&aid=372&group_id=21&atid=205 Gforge patch #372]
    4747
    4848=== Meta-data support ===
    4949
    50 The existing raster meta-data handling is rather weak (currently stored in <tt>$MAPSET/hist/$MAPNAME</tt>). Total replacement will be the best option.
     50The existing raster meta-data handling is rather weak (currently stored in {{{$MAPSET/hist/$MAPNAME}}}). Total replacement will be the best option.
    5151
    5252Brad Douglas suggests:
    5353
    54 ''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.''
     54It would be very advantageous to at least support metadata as specified in [http://www.fgdc.gov/standards/projects/FGDC-standards-projects/csdgm_rs_exMetadataRemoteSensingExtens.pdf FGDC-STD-012-2002]. XML is an ideal file format.
    5555
    5656Nick Lawrence suggests:
    5757
    58 The GIMP project is examining the concept of a general mult-layer bitmap format.
     58The GIMP project is examining the concept of a general multi-layer bitmap format.
    5959
    6060 * [http://create.freedesktop.org/wiki/index.php/General_multilayered_bitmap_exchange_format OpenRaster - Create Wiki]