Opened 6 weeks ago

Closed 6 weeks ago

Last modified 6 weeks ago

#7123 closed defect (fixed)

inconsistant spatial filtering for null or empty geometries

Reported by: Even Rouault Owned by: Even Rouault
Priority: normal Milestone: 2.3.0
Component: OGR_SF Version: unspecified
Severity: normal Keywords:
Cc:

Description

Nyall Dawson pointed to me in 
https://github.com/qgis/QGIS/pull/5501#issuecomment-340934947 about a weird behaviour 
of OGR spatial filtering regarding null and empty geometries.

To make it concrete, consider the following CSV file

id,WKT
1,"POLYGON EMPTY"
2,
3,"POLYGON ((0 0,0 1,1 1,0 0))"


$ ogrinfo test.csv -al -spat 0 0 1 1 -q

Layer name: test
OGRFeature(test):1
  id (String) = 1
  WKT (String) = POLYGON EMPTY
  POLYGON EMPTY

OGRFeature(test):2
  id (String) = 2
  WKT (String) = 

OGRFeature(test):3
  id (String) = 3
  WKT (String) = POLYGON ((0 0,0 1,1 1,0 0))
  POLYGON ((0 0,0 1,1 1,0 0))

$ ogrinfo test.csv -al -spat 1 1 2 2 -q

Layer name: test
OGRFeature(test):2
  id (String) = 2
  WKT (String) = 

OGRFeature(test):3
  id (String) = 3
  WKT (String) = POLYGON ((0 0,0 1,1 1,0 0))
  POLYGON ((0 0,0 1,1 1,0 0))

So features with null geometries (FID 2) are always selected. And for a feature with an empty 
geometry (FID 1), it is selected by the -spat 0 0 1 1 filter since internally the envelope of 
POLYGON EMPTY is computed as xmin=xmax=ymin=ymax=0, but not by -spat 1 1 2 2

If ingesting this file into PostGIS and doing the same test, we get:

$ ogrinfo pg:dbname=autotest test -spat 0 0 1 1 -q

Layer name: test
OGRFeature(test):3
  id (String) = 3
  wkt (String) = POLYGON ((0 0,0 1,1 1,0 0))
  POLYGON ((0 0,0 1,1 1,0 0))

$ ogrinfo pg:dbname=autotest test -spat 1 1 2 2 -q

Layer name: test
OGRFeature(test):3
  id (String) = 3
  wkt (String) = POLYGON ((0 0,0 1,1 1,0 0))
  POLYGON ((0 0,0 1,1 1,0 0))

So null or empty geometries are never selected when a spatial filter is set. This last behaviour 
seems to be the most logical for me, and I'd propose we adopt it for non-SQL based drivers 
as well.
(note: the current behaviour dates back to the initial introduction of spatial filtering in OGR 
per https://trac.osgeo.org/gdal/changeset/7191 , 13 years ago )

Change History (5)

comment:1 Changed 6 weeks ago by Jukka Rahkonen

Not directly related but something to keep in mind - MapServer? by default adds the &&[bounding box] filter which is OK for WMS but with WFS it means that features without geometries are never selected. I do not know how the QGIS WFS server behaves.

Depending on the use case features without geometry/with empty geometry can make sense and in that case the software should not automatically add spatial filter. This ticket is about a case where user explicitly gives a spatial filter and I agree that then empty geometries should not get selected.

comment:2 Changed 6 weeks ago by Even Rouault

You can avoid MapServer? WFS code to emit the spatial filter with "wfs_use_default_extent_for_getfeature" "no" in LAYER.METADATA. This is currently only honoured in practice by the MapServer? OGR backend. But... both the OGR and PostGIS MapServer? backends will anyway skip features with null geometries. So there would be work needed to support such cases, and this OGR change shouldn't have direct impact on this behaviour

comment:3 Changed 6 weeks ago by Even Rouault

Resolution: fixed
Status: assignedclosed

In 40613:

OGRLayer::FilterGeom?(): make sure a feature with a null or empty geometry never matches a spatial filter (fixes #7123)

comment:4 Changed 6 weeks ago by Even Rouault

In 40614:

Adjust test result due to refs #7123 changes

comment:5 Changed 6 weeks ago by Even Rouault

In 40615:

Adjust test result due to refs #7123 changes

Note: See TracTickets for help on using tickets.