[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