[GRASS-dev] r.profile limits in Windows 7

[Hamish]

Enrico wrote:

>>  due to strange misbehaviours, we are doing some stress tests on
>>  r.profile under Grass 6.4 and Windows 7
>> 
>>  Case A (less interesting, IMHO):
>> 
>>  r.profile fails with ERROR: G_malloc when the number of pixel queried
>>  is more than 1E6
>>  our test: profile lenght: 300km, res=3 OK, res=2 failure ( example a
>>  river analysis on a lidar-derived DTM)

can you provide the current region settings (g.region -p) and the exact command line parameters used?

r.profile counts "n" as integer, but that should survive well past 1 million.
?

note WinGRASS binaries are still 32 bit, and I see some float rows,cols work around in the r.profile code's do_profile() function.

it would be good to also test in 64 bit linux on a machine with the same amount of RAM.

As Maris noted, please open a bug report for this.


>>  Case B (more interesting):
>> 
>>  r.profile fails when "profile" input is a string larger than 8100
>>  characters (more or less)
>>  I suppose the problem comes from a limit of cmd.exe (8191 characters)
>>  see [0]
>> 
>>  Please, consider that using UTM integer coordinates that means only
>>  300 nodes, and this is not so unusual for profile analysis.
>> 
>>  Probably, using optionally a text file as "profile" input could 
>> solve  the problem without refactoring the module...
...
>>  [0] http://support.microsoft.com/kb/830473


r.profile can read from the standard input stream if you leave off the
profile coordinates option. so:

GRASS> r.profile in=elevation.dem output=- < query_coords.txt

will get you past the command line length limit (and is easier to work
with too). what we should do is explicitly look for "profile=-" for
reading from stdin, to make it more clear that it exists. another
more GUI friendly way is to add a new option for an input file, which
would be mutually exclusive with the profile=[east,north[,east,north,...]
method of using the module.



Hamish