[postgis-devel] [PostGIS] #200: Resolution reduction built-in to gdal2wktraster script

[PostGIS]

#200: Resolution reduction built-in to gdal2wktraster script
------------------------+---------------------------------------------------
  Reporter:  mloskot    |       Owner:  mloskot                              
      Type:  task       |      Status:  assigned                             
  Priority:  high       |   Milestone:                                       
 Component:  wktraster  |     Version:  trunk                                
Resolution:             |    Keywords:  overview,pyramid,resolution,reduction
------------------------+---------------------------------------------------
Comment (by mloskot):

 Re-organized command line options (r4226).

 Status summary:
  * script is more oriented on regular blocking processing now
  * to request regular blocking, use -k,--block-size option
 {{{
 ./gdal2wktraster.py -r test.tif -t test -k 256x256
 }}}
  * to request overview (level), use -l,--overview-level option:
 {{{
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 2
 }}}
  * if level = 1 base raster is generated, not an overview
 {{{
 ./gdal2wktraster.py -r test.tif -t test -k 256x256
 or
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 1
 }}}
  * if regular blocking requested, then single execution == single input
 raster == single level (overview) generation. In order to generate base
 raster (level=1) and overview levels 2,4,8 user has to run 4 processes
 separately:
 {{{
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 1
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 2
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 4
 ./gdal2wktraster.py -r test.tif -t test -k 256x256 -l 8
 }}}
  * The approach of multi-process execution may change in future to
 generate all oberviews in single step with all levels specified as ''-l 2
 4 8''. However, current version may easily benefit of
 [http://blip.tv/file/2232410 parallel execution].
  * After such a big change of how gdal2wktraster performs the raster
 crunching job, it's obvious bugs are in there and (re)testing is required.

 I'm not closing this ticket yet and I will after I'm sure and happy with
 what I've done.

 BTW, somebody could refactor the script to a nice modularised one, with
 i.e. WKTRasterCoverage class that encapsulates the whole job of cutting
 usable as a standalone module. Then the rest of processing becomes
 simpler. Volunteers?

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/200#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS