[GRASS-dev] [GRASS GIS] #3407: v.in.ogr fails to import ESRI Shapefile with empty attribute table cells

[GRASS GIS]

#3407: v.in.ogr fails to import ESRI Shapefile with empty attribute table cells
----------------------+-------------------------
  Reporter:  mikatt   |      Owner:  grass-dev@…
      Type:  defect   |     Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |    Version:  7.2.1
Resolution:           |   Keywords:
       CPU:  x86-64   |   Platform:  Linux
----------------------+-------------------------

Comment (by rouault):

 I'm just speaking about the OGR side of things. With GDAL 2.2, you have 3
 potential states for a field:
 - unset  -> OGR_F_IsFieldSet() == FALSE. OGR_F_GetFieldAsString() will
 return an empty string (it is not allowed to return NULL)
 - set, but NULL -> OGR_F_IsFieldSet() == TRUE and OGR_F_IsFieldNull() ==
 TRUE. OGR_F_GetFieldAsString() will also eturn an empty string
 - set, and not NULL --> OGR_F_IsFieldSet() == TRUE and OGR_F_IsFieldNull()
 == FALSE. An empty string is considered as a not-null set field, so a
 potential return of OGR_F_GetFieldAsString()

 Depending on drivers, they will decide whether to dispatch a field as
 unset, set or set with empty string.
 The shapefile driver as of GDAL 2.2 will set all fields, either to NULL,
 or to a not-NULL set value. Note: for strings, there's no way in .dbf to
 distinguish NULL from empty string, so an empty string is mapped to a NULL
 field (in previous GDAL versions, this was mapped to a unset field)
 The CSV driver has traditionnally mapped an empty field as a an empty
 string, and this hasn't changed in GDAL 2.2

 Hope that clarifies things. Ah nullness and emptyness....

 So perhaps given GRASS constraints and concepts, testing the return of
 OGR_F_GetFieldAsString() against the empty string is good enough if you
 don't need to distinguish between the 3 above states.

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