[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 mmetz):

 Replying to [comment:4 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,

 Constraints and concepts of dbf/sqlite/postgresql/mysql, to be precise.

 As you explained, the OGR dbf driver, which is also used internally in
 GRASS for dbf databases, does not distinguish between unset and NULL, thus
 import with dbf as GRASS database should work as before.

 Regarding import into GRASS, there was no need to distinguish between the
 3 possible states, at least there are no known problems.

 > 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.

 Regarding export from GRASS to OGR, what happens if a field is not
 explicitly set or unset? Is it now unset or set, but NULL? Do we need to
 adjust v.out.ogr using `OGR_F_SetFieldNull()` and/or `OGR_F_UnsetField()`
 instead of not touching the field at all?

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