[gdal-dev] Force bounding box test for spatial filter in OGR
Frank Warmerdam
warmerdam at pobox.com
Fri May 11 16:47:50 EDT 2012
Martin,
I have no objection to your adding a configuration option to control whether
this test in ogrlayer.cpp should be done:
-------------------------------------------------------------------- */
/* Fallback to full intersect test (using GEOS) if we still */
/* don't know for sure. */
/* -------------------------------------------------------------------- */
if( OGRGeometryFactory::haveGEOS() )
{
//CPLDebug("OGRLayer", "GEOS intersection");
return m_poFilterGeom->Intersects( poGeometry );
}
else
return TRUE;
Just preceeding it is logic which does fast tests for
intersection of vertices with simple rectangular envelopes.
This can quickly establish that some geometries do
intersect the envelope.
It occurs to me it would be a huge win in some cases to
extend that so if none of the segments could possible
intersect the envelope then we can be sure there is
no intersection and return FALSE without any use of
GEOS. In fact, I don't see why we can't actually
completely implement intersection tests for geometries
with an envelope "inline" and fairly fast without any use
of GEOS. We would only need to fallback to using GEOS
for complex filter geometries that are not envelopes.
I think if we do this we could avoid any special
configuration options.
Let me know if you want to pursue this. If not, I will.
Best regards,
Frank
On Fri, May 11, 2012 at 1:08 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> Hi all,
>
> when fetching features in OGR with an active spatial filter, first a
> bounding box test is used to resolve simple cases and then exact
> intersection with GEOS is done to determine whether the feature is
> really within the filter (if compiled with GEOS). I would like to have
> an option to force only bounding box test without the expensive GEOS
> intersection.
>
> Motivation: recently I have encountered a shapefile with contour
> lines: 72K features, geometries with lots of vertices. When displaying
> about 1/2 of the layer's extent in QGIS, it takes ~106 seconds to get
> the map rendered! When I temporarily disabled setting of spatial
> filter in OGR provider, the rendering time went down to ~5 seconds.
> That's a great difference, isn't it? I know that this is not the most
> typical case, but still it matters. (For the record, spatial index
> made little to no difference to original time since the contour lines
> are spread out). In general when rendering one does not care so much
> if also features slightly outside of the current extent get fetched -
> they will be clipped by the rendering engine and that is definitely
> faster than the intersection algorithm.
>
> Do you have any suggestions how such option should be implemented -
> e.g. add OGRLayer::setFlags(...) method? Would be such addition
> accepted?
>
> Regards
> Martin
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer
More information about the gdal-dev
mailing list