[gdal-dev] Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Even Rouault-2

Hi,

 

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 )

 

Any thought ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Ari Jolma-2
Even Rouault kirjoitti 01.11.2017 klo 13:02:

Hi,

 

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.

...

 

 

Any thought ?


Yes. Deep ones. If something is 'empty', is it 'a thing'? Can 'nothing' exist? Weird things should be expected to behave weirdly.

I would say such things should disappear, i.e., the PostGIS behavior is logical.

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Edzer Pebesma-2


On 11/01/2017 12:15 PM, Ari Jolma wrote:

> Even Rouault kirjoitti 01.11.2017 klo 13:02:
>>
>> Hi,
>>
>>  
>>
>> 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.
>>
> ...
>>
>>  
>>
>>  
>>
>> Any thought ?
>>
>
> Yes. Deep ones. If something is 'empty', is it 'a thing'? Can 'nothing'
> exist? Weird things should be expected to behave weirdly.

I think of it as the "there is no such thing for which ..." answer to
the question "is there a thing for which ...", e.g. if you'd do a left
join with a spatial predicate and there is no match.

And I agree, "no such thing" should never come out of a spatial filter.

I never understood the value of having all these typed EMPTYs in SFA,
and whether/how they'd differ from NULL geometries in OGR.

>
> I would say such things should disappear, i.e., the PostGIS behavior is
> logical.
>
> Ari
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Nyall Dawson
In reply to this post by Even Rouault-2
On 1 November 2017 at 21:02, Even Rouault <[hidden email]> wrote:

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

My 2c is also that empty/null geometries do NOT intersect a filter
rectangle, and so should not be included here.

Nyall
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposed changed to solve inconsistant spatial filtering for null or empty geometries

Even Rouault-2
In reply to this post by Even Rouault-2

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

 

Done in trunk per https://trac.osgeo.org/gdal/ticket/7123

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev