<br><br><div class="gmail_quote">2008/5/19 Hamish <<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> Yann Chemin wrote:<br>
> > I have some data that reads as "nan", while<br>
> > rare, it may happen when compressing/uncompressing<br>
> > GRASS Locations to ship them across Internet.<br>
<br>
</div>what method are you using to compress/decompress?<br>
..zip? .tar.gz? r.pack/r.unpack?<br>
</blockquote><div><br>Windows zip, ftp download across the World, then Linux unzip.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
if r.pack I think it is safer to use the script in the trac wish patches which converts GRASS <=6 raster dir layout to proposed GRASS 7 $MAPSET/raster/$NAME/element) then tarball up the map's dir, and vice versa. I should probably update r.pack not to use r.{in|out}.mat as that will lose some metadata for sure.<br>
</blockquote><div><br>We will use r.[,un]pack that from now on.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
places in the code to look for accidental creation of nan:<br>
- (x/y) where both the x and y variables could sometimes be 0.<br>
- tan(pi/2)<br>
- r.in.mat/r.out.mat use Matlab's NaN to store grass NULLs<br>
- GRASS nulls + non-core libgis functions meet mixed endian (?)<br>
- ?<br>
<div class="Ih2E3d"></div></blockquote><div><br>hmm, tan() is a suspect here. x==y==0 may also be, shall put tests but more complex.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
> > I would like to know how to deal with them in GRASS<br>
> > raster programming, so that they are:<br>
> > 1 - detected<br>
> > 2 - set to null<br>
<br>
</div>Glynn:<br>
<div class="Ih2E3d">> if (x != x)<br>
> G_set_d_null_value(&x, 1);<br>
><br>
> There is also isnan(), which is in C99, and also specified<br>
> by POSIX:<br>
><br>
> <a href="http://www.opengroup.org/onlinepubs/009695399/functions/isnan.html" target="_blank">http://www.opengroup.org/onlinepubs/009695399/functions/isnan.html</a><br>
><br>
> However, I don't know if it exists on all platforms<br>
> which we care about. MSDN says that MSVCRT has _isnan() (with a<br>
> leading underscore), but it's defined in <float.h> rather than<br>
> <math.h>.<br>
><br>
> The (x != x) test should be portable; OTOH, it's the<br>
> kind of thing that compilers often get wrong, particularly when<br>
> optimising (if you ignore NaN, x!=x is always false).<br>
<br>
<br>
</div>there is a longstanding wish that 'r.null setnull=' could understand nan, so that you could get rid of them. e.g. very rarely r.in.xyz will create them, I am not sure why/how.<br>
<div class="Ih2E3d"></div></blockquote><div><br>would be useful to make coloring of output maps appear... right now nan intefers in the standard colors setup, it seems.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
> For 7.0, I intend to change G_is_[fd]_null_value() to treat<br>
> all NaN values as null, not just the specific bit patterns which<br>
> it currently uses.<br>
<br>
</div>the only reason I could see to keep them as nan not grass-NULL would be for debugging (there is obviously a bug if you get them..).<br>
<font color="#888888"><br>
<br>
Hamish<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Yann Chemin<br>International Rice Research Institute<br>Office: <a href="http://www.irri.org/gis">http://www.irri.org/gis</a><br>Perso: <a href="http://www.freewebs.com/ychemin">http://www.freewebs.com/ychemin</a>