[GRASS-dev] [GRASS GIS] #2499: v.in.ogr in does not handle "nan" in attribute tables properly

[GRASS GIS]

#2499: v.in.ogr in does not handle "nan" in attribute tables properly
--------------------------+-----------------------------------------
  Reporter:  sbl          |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.8.3
 Component:  Vector       |    Version:  unspecified
Resolution:               |   Keywords:  v.in.ogr, DBMI, SQLite, nan
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------------------

Comment (by mmetz):

 Replying to [comment:11 sbl]:
 > Here is how it was handeled in Pandas:
 > https://github.com/pandas-dev/pandas/pull/8208
 >
 > As a simple example for reproduction (though not with v.net.centrality)
 you could do:
 >
 > {{{
 > db.execute sql="CREATE TABLE test (column double precision);"
 > db.execute sql="INSERT INTO test VALUES (-nan);"
 > # in contrast to
 > db.execute sql="INSERT INTO test VALUES (NULL);"
 > }}}
 >
 > SQLite seems to have a workaround:
 >
 http://system.data.sqlite.org/index.html/tktview/e06c4caff3c433c80616ae5c6df63fc830825e59
 > But that does not seem to be available in default packages of SQLite and
 other DBMIs seem to struggle With nan/NaN as well… So, this does not seem
 to be trivial...

 The SQLite workaround with !GetAllAsText seems ugly. What works is
 {{{
 db.execute sql="INSERT INTO test VALUES ('-nan');"
 }}}
 but then SQLite converts '-nan' to -0 (zero) which is wrong. Same for
 inf/-inf. Using NULL is also not correct, because NULL means "no entry",
 whereas nan and inf are numbers that can be represented as floating point
 numbers.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2499#comment:12>
GRASS GIS <https://grass.osgeo.org>