[GRASS-dev] [GRASS GIS] #2343: GRASS 7: "inf" values break insert statements in v.rast.stats

GRASS GIS trac at osgeo.org
Sat Jan 3 17:05:43 PST 2015


#2343: GRASS 7: "inf" values break insert statements in v.rast.stats
--------------------------+-------------------------------------------------
 Reporter:  sbl           |       Owner:  grass-dev@…              
     Type:  defect        |      Status:  new                      
 Priority:  normal        |   Milestone:  7.0.0                    
Component:  Python        |     Version:  svn-releasebranch70      
 Keywords:  v.rast.stats  |    Platform:  All                      
      Cpu:  All           |  
--------------------------+-------------------------------------------------

Comment(by glynn):

 Replying to [comment:8 neteler]:
 > ...should r62938 be reverted and implemented differently?

 Maybe. It depends upon how much work is involved.

 Infinities are sufficiently rare that it probably doesn't matter how
 they're handled (e.g. r.mapcalc explicitly checks for division by zero,
 log(0) etc and returns null). If it's just a matter of writing
 float_to_string() and string_to_float() functions which deal with them
 correctly (and we know how to write them), it should be done. If there are
 other complexities, or if every supported database has a different
 representation, don't bother.

 Storing NaNs in a database is probably undesirable. I wouldn't assume that
 all databases will implement the same semantics, or even sane semantics
 (the fact that they aren't equal to themselves, that all of x<NaN, x>NaN,
 NaN<x and NaN>x are false, etc tends to wreak havoc with any algorithm
 which isn't expecting them). Code which retrieves values from a database
 is more likely to have been written to handle SQL NULLs correctly than to
 handle NaNs correctly.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2343#comment:9>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list