[fdo-internals] OGR provider and intersection

Gavin Cramer gavin.cramer at autodesk.com
Mon May 12 11:59:03 EDT 2008


This looks like it will work well.  One limitation to keep in mind when performing this secondary spatial filtering in the client is that all of the other query criteria have already been met.  Thus, the spatial filter criterion can only be interpreted as "And" with the other criteria.  E.g. "where inside some_polygon AND parcel_owner = 'Bob'".

FdoIGeometry objects have an internal pool, so it won't really create a new one on the heap every time.  Holding onto it will save a very small cost to find it in the pool though.

Gavin


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, May 12, 2008 10:18 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] OGR provider and intersection


That looks right. The place to put it would be in ReadNext() and check features returned by OGR (which match the BBOX) for true intersection. Also, for performance, it's good to cache the right hand side FdoIGeometry so that it is not created every time.

Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
Sent: Monday, May 12, 2008 9:35 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] OGR provider and intersection

Ok, I'll try that.

I found some code you suggested some time ago, for testing intersection using FDO:

     int fgfLen = "the length of the feature geometry array in bytes";
     const FdoByte* fgf = "the feature geometry, converted to FGF";

     FdoPtr<FdoExpression> exprRight = filter.GetGeometry();
     FdoGeometryValue* gvRight = (FdoGeometryValue*)(exprRight.p);

     FdoPtr<FdoByteArray> baRight = gvRight->GetGeometry();

     FdoPtr<FdoFgfGeometryFactory> gf = FdoFgfGeometryFactory::GetInstance();
     FdoPtr<FdoIGeometry> geomRight = gf->CreateGeometryFromFgf(baRight);
     FdoPtr<FdoIGeometry> geomLeft = gf->CreateGeometryFromFgf(fgf, fgfLen);

     //call on the geometry utility to evaluate the spatial operation
     bool ret = FdoSpatialUtility::Evaluate(geomLeft, filter.GetOperation(), geomRight);

Does that still look plausible?
If so, I'll try to patch the provider once I get a VS 2005 machine up.

Regards, Kenneth Skovhede, GEOGRAF A/S


Traian Stanev skrev:

It's not the provider, it's the GDAL dll. You can drop in a GDAL dll that is compiled with GEOS and it should then work. Another alternative is to make it use the FdoSpatialUtility implementation of Intersects, which presumably is always available when FDO is there.



Traian









-----Original Message-----

From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-

bounces at lists.osgeo.org<mailto:bounces at lists.osgeo.org>] On Behalf Of Kenneth Skovhede, GEOGRAF A/S

Sent: Monday, May 12, 2008 6:21 AM

To: FDO Internals Mail List

Subject: [fdo-internals] OGR provider and intersection



I have used the 3.3.1 release of the SDK (from April).

It seems the OGR provider is back to using Envelope intersection tests,

when "INTERSECTS" is used.

Is the provider compiled without GEOS support?

If so, are there plans to change the build procedure to include GEOS

support?



--

Regards, Kenneth Skovhede, GEOGRAF A/S





_______________________________________________

fdo-internals mailing list

fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>

http://lists.osgeo.org/mailman/listinfo/fdo-internals



_______________________________________________

fdo-internals mailing list

fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>

http://lists.osgeo.org/mailman/listinfo/fdo-internals


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080512/aa68e61f/attachment-0001.html


More information about the fdo-internals mailing list