OGR select problem

[ksgeograf]

The OGR provider only performs geometry intersection on the feature/filter envelopes. When used in MapGuide, this results in selection and tooltips acting on the objects envelope, rather than the actual feature. I have previously submitted code that filters the unwanted features for intersection tests that are not specified as "envelope intersects". That code used GDal to perform the actual intersection test. The GDal version supplied with FDO binaries does not have GEOS support, because it was causing problems. So the provider is back to behaving odd for selection and tooltips.

I have reworked the code to now use FdoSpatialUtil to perform the intersection test. The patch is attached.

[ksgeograf]

Patch

[traianstanev]

Hi Kenneth,

I reviewed the patch. It looks fine, except for one problem. Since you are handling all spatial operations (not just intersects), you need to zero out the OGR BBOX filter in case of operations like Disjoint, where the OGR BBOX intersection will return the opposite of what you want for the post-process FDO filter.

I can fix this when I apply the patch next week.

Traian

[ksgeograf]

You are right. However, the current OGR implementation only supports "Envelope Intersect" and "Intersect" (look in ApplyFilter).

If the BBOX filter is removed from the OGR call, then there would be extra strain on the OGR provider, since it now recieves all/more features. I guess that would slow down the rendering operation which is purely dependant on envelope intersection.

I guess it could be handled in ApplyFilter, so the geometry filter is cleared if the spatial operation is something other than intersection/envelope intersect.

[traianstanev]

Yes, actually that's what I meant -- only zero out the BBOX filter in case of the operations that need that. However, I had forgotten that the provider explicitly checks for Intersects and BBOX filters... so I guess we just apply the patch as is right now. Eventually we could carry over the query translator from the SQLite provider, which has a more generic implementation, that can handle combinations of filters that are not in any particular order.