UPDATE: segment lib,i.rectify, r.cost, r.drain,r.surf.cont

[Pierre de Mouveaux]

Hello,

some new modules have been updated to the Grass floating point and null data
raster API. These will be in the soon to be annouced Grass5.0 beta7 release.


I.rectify and i.rectify2 
---------------
are now working. Port to Grass 5.0 was started last summer by Luca Palmiri
(palmeri at ux1.unipd.it) and Bill Hugues. I finished the work ;).
Now, Grass 5.0 versions of i.rectify an i.rectify2 supports rectification of
maps that are in a different projection than the projection in the target
location. (x,y-> tmerc, for instance).

segment library
-----------
This grass library allows buffered random access to areas of a map that
don't spans entiere rows (i.e. a square in the midle of a map). It  has been
cleaned up from severall assumption about the cell data size of raster files
(integer), and is again a generic data independant library (that was clearely
the initial intent of the creators of this lib). Now, several modules, like
r.surf.contour, should "automagically" work again in Grass 5.0.

r.surf.contour
----------
works again on integer cell files, thanks to the updated segment library. This
module still needs to be updated to support the new Grass 5.0 floating point
raster format, and thus only works with integer cell files.

r.cost and r.drain
------------
have been updated to support the new floating point/null cell Grass 5.0 raster
format. A more efficient use of the segment library and a brand new b-tree
memory allocator gives a r.cost speed improvement from 50% to 400-500%,
depending on the initial conditions. (thought, it will more likely be about
50-75%. Experiences with very large and complex files are welcome!). There are
some new options to handle null cells, and there are also updated man pages
and tcltkgrass modules. 

Notes on null cell handling in r.cost and r.drain:
---------------------------------
In r.cost, null cells are excluded from calculus by default, and are copied
verbatim in the output, behaving like a mask. i.e., the algorithm calculates
accumulated costs along a path the goes **around** the null cells ("holes" in
the map).  
A new option, 'null_value', allows to assign a positive floating point cost
value to the input null cells (like a 'reclass' on these null cells). Then for
instance, assigning a 0.0 cost to null cells makes them "transparent" to the
r.cost algorithm, i.e. these cells only averages (smallest cost) and spreads
the accumulated cost value around the limits of the null cells area.  In this
case, input null cells are no more translated to null cells in the output map,
as they actually holds a clculated cost value. To change this behaviour, a new
flag '-n' allows to keep input null cells verbatim into the output map at the
end of the process (behaving like a mask). 

The output map will be of the same format (integer, float or double) than the
input map.

In r.drain, the same behaviour have been implemented: input null calls are
excluded from the minimum cost path evaluation, i.e, the paths will go
"around" a null cell areas, if any.  
A new option, 'null_value' allows to assign a floating point value to the null
cells. Then, for instance, assigning a 0.0 value to input null cells will allow
the algorithm to cross transparently the null cells area in the map. The
resulting output map is an integer cell file, with '1' along the calculated
path, and 0 valued null cells everywhere else.

Please, note that the default behaviour of r.cost and r.drain as not been
changed, so Grass 4.x scripts using r.cost and/or r.drain should work
seamlessly with Grass 5.0. 


Thanks to Markus, who conducts the first round of testings, all these updates
are in the CVS repository, and will be in the Grass 5.0 beta7 release due to
come this week. 

Note: at this time, r.cost relies on gcc floating point library definition of
"infinite" fp values. In this case, that only means compatibility with "BSD"
extensions and/or  "ISO C 9x" definitions. This should be available on any
modern compiler. I would be happy to add any compiler specific flags, if
required. 


Best Regards,
Pierre de Mouveaux