[GRASS5] timeseries: null file, r3

[Helena Mitasova]

> Glynn,
>
> can you implement this change so that it gets into the next release, 
> if there are no objections?
> I have always thought that 0 as NULL has been gone with GRASS4,
> I find it pretty confusing (even in GRASS4* it has always caused all 
> kinds of problems).
> I work almost exclusively with FP maps so I did not realize
> that this behavior is still there.
>
> thank you,
>
> Helena
>
>
>  On Nov 23, 2005, at 12:54 PM, Glynn Clements wrote:
>
>>
>> Joel Peter William Pitt wrote:
>>
>>> I need to store many thousands of maps for different model simulation
>>> runs as each has at least 25 maps in a timeseries.
>>>
>>> Currently running 100 replications of a 25 year model on a 2000x2000
>>> region results in about 2.1 gig.
>>> This on its own is okay, but I need to run sensitivity analyses on a
>>> range of parameters, meaning each value I test for a parameter gives 
>>> a
>>> location of 2.1 gig!
>>>
>>> Checking out the actual data files however shows that the cell files 
>>> are
>>> only about 60k each. The problem is the uncompressed null bitmasks 
>>> that
>>> are 700k each. Now, I can explicitly remove the null bitmask using
>>> "r.null -r", but I was wondering if the null mask will just get
>>> automatically created next time I run a GRASS command?
>>
>> The null file is created when the map is created, or via r.null.
>>
>>> Also, I'm under the impression that if there is no null bitmask then
>>> values equal to 0 in the cell file are interpreted as nulls, is this
>>> right?
>>
>> For integer maps, yes. If a FP map doesn't have a null bitmap, all
>> cells are valid.
>>
>> This is for compatibility with 4.3, which didn't have null bitmaps. It
>> didn't have FP maps either, so compatibility isn't an issue there.
>>
>> This behaviour could easily be removed; see the following code in
>> get_null_value_row_nomask() in lib/gis/get_row.c:
>>
>> 	    if (read_null_bits(null_fd, fcb->null_work_buf,
>> 			       i+fcb->min_null_row, fcb->cellhd.cols, fd) < 0)
>> 	    {
>> 		if (fcb->map_type == CELL_TYPE)
>> 		{
>> 		    /*
>> 		      If can't read null row, assume  that all map 0's are nulls
>> 		      use allocated G__.mask_buf to read map row */
>> 		    get_map_row_nomask(fd, (void *) G__.mask_buf, 
>> i+fcb->min_null_row,
>> 				       CELL_TYPE);
>> 		    for (j = 0; j < G__.window.cols; j++)
>> 		    {
>> 			if (G__.mask_buf[j] == 0)
>> 			    flags[j] = 1;
>> 			else
>> 			    flags[j] = 0;
>> 		    }
>> 		}
>> 		else /* fp map */
>> 		{
>> 		    /* if can't read null row, assume  that all data is valid */
>> 		    G_zero(flags, sizeof(char) * G__.window.cols);
>> 		    /* the flags row is ready now */
>> 		}
>> 	    } /*if no null file */
>>
>> To disable the behaviour, replace the above block with:
>>
>> 	    if (read_null_bits(null_fd, fcb->null_work_buf,
>> 			       i+fcb->min_null_row, fcb->cellhd.cols, fd) < 0)
>> 	    {
>> 		/* if can't read null row, assume  that all data is valid */
>> 		G_zero(flags, sizeof(char) * G__.window.cols);
>> 		/* the flags row is ready now */
>> 	    } /*if no null file */
>>
>> 4.3 is old enough that we could probably just remove that behaviour
>> altogether. It just requires anyone using maps which were created
>> using 4.3 to add a null bitmap with r.null.
>>
>>> Is there anyway to specify NOT creating a null mask when creating a
>>> map?
>>
>> No.
>>
>> -- 
>> Glynn Clements <glynn at gclements.plus.com>
>>
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
>>
> Helena Mitasova
> Dept. of Marine, Earth and Atm. Sciences
> 1125 Jordan Hall, NCSU Box 8208,
> Raleigh NC 27695
> http://skagit.meas.ncsu.edu/~helena/
>
>
Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/