OSM driver: Problem with spatial filter and multipolygons

[damiandixon]

I am seeing some unexpected behavior while using a spatial filter with openstreetmap data.

I have attached 2 screenshots:

-gdalosm_withoutfilter.png: The affected area loaded via OGR, with no spatial filter set ​​ The ​image shows a dotted line – this is the spatial filter. The rendering has gone a bit nuts because of the missing points making a very invalid polygon. Which is why we noticed that there was a problem.

-gdalosm_withfilter.png: The affected area loaded via OGR, with a spatial filter set. The polygon is drawn as expected.​

I would ​have ​expect​ed the returned polygon to extend past the spatial filter. This behavior has not been encountered with any other data format.

My copy of GDAL has not been built against GEOS. This behavior appears to be caused by the spatial filter check in OGROSMDataSrouce::NotifyNodes

--Snip (ogrosmdatasource.cpp line 813)-- void OGROSMDataSource::NotifyNodes(unsigned int nNodes, OSMNode* pasNodes) { ​​

unsigned int i;

const OGREnvelope* psEnvelope =

papoLayers[IDX_LYR_POINTS]->GetSpatialFilterEnvelope();

for(i = 0; i < nNodes; i++) {

/* If the point doesn't fit into the envelope of the spatial filter */ /* then skip it */ if( psEnvelope != NULL &&

!(pasNodes[i].dfLon >= psEnvelope->MinX &&

pasNodes[i].dfLon <= psEnvelope->MaxX && pasNodes[i].dfLat >= psEnvelope->MinY && pasNodes[i].dfLat <= psEnvelope->MaxY) )

continue;

[damiandixon]

gdalosm_withfilter.png

[damiandixon]

gdalosm_withoutfilter

[Even Rouault]

Yes the OSM driver is particular in many ways due to the format itself being not simple feature oriented. I thought this particularilty was already documented, but apparently not.

trunk r34319 "OSM: document particularities of spatial filtering (#6534)"