[GRASS5] features needed for 6.2

Helena Mitasova hmitaso at unity.ncsu.edu
Thu Mar 30 23:31:18 EST 2006


On Mar 30, 2006, at 10:01 PM, Hamish wrote:

>> There already is r.pack/r.unpack in grass wiki add ons written by
>> Hamish http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassAddOns
>>
>> maybe Hamish could submit it to CVS to make it easier for users to
>> find it,
>
>
> No, it shouldn't go into CVS (as is).
>
> 1) it's a quick hack
> 2) I never finished checking if r.in|out.mat was endian-safe
>     (any one with Matlab on a Mac want to try?, turn on g.gisenv  
> debug)
> 3) Because Matlab stores data column by column instead of row by row
> (holdover from FORTRAN I think), the entire map must be loaded into
> memory during processing. Not something we want for a non-specialist
> module. (I don't want to rotate the map 90deg either)

would it be possible to include this as a comment into the script?  
something
like Cedric has done for r.tileset or v.group, just to make the user  
aware or
if somebody wants to re-do it.
>
> A better approach might be to create a new mapset dir in the current
> location, copy over the WIND file from current mapset and PROJ_* files
> from PERMANMENT, switch to the new mapset with g.mapset, 'g.copy @,',
> then switch back to the original mapset and .tar.gz the entire  
> temporary
> mapset.
> ?
>
> Personally I don't use this very often so someone else should take  
> it up
> if they want it.
>
>
> Other candiates for inclusion are r.in.wms/r.in.onearth and
> v.out.ascii.db.

those would be useful to include too.

Helena

> I've never been sure if v.out.ascii.db as the correct
> approach or if a C module doing the same (or modification of  
> v.out.ascii
> itself) would be better.
>
>
> Hamish




More information about the grass-dev mailing list