Hi, some time ago on GeoServer devel we discussed the usage of the "loose bbox" hint some jdbc datastores have in light of performance/correctness issues. The discussion is here:
http://www.nabble.com/On-loose-bbox-usage-ts15978561.html#a15980016 The core of the issue is that OGC BBOX is defined to be a shortcut to "intersects", which is computationally expensive compared to a simple bbox vs bbox comparison. In the case of WMS a bbox filter is always present to filter out the geometries that are outside of the current view, but making the full intersects is a serious slow down. A good enough solution (for me at least) was to turn this into a query hint to instruct the datastore to evaluate bbox filters the loose way. This would have left a minor hole, that is, if the SLD contained a BBOX filter, that would have been evaluated the loose way too, which is not optimal. In a perfect world, we'd just want the view bbox filter to be evaluated that way. A different solution would be to add a LooseBBox interface to GeoApi with exactly the semantic of envelope vs envelope comparison. And then have FilterFactory have a looseBbox method. This of course would be a much bigger change, it would be an API change, we'd have to amend all of the filter visitors and sql encoders to deal with it. But on the other side it would be very explicit about what you want. Given that a user can workaround the "bbox filter in sld" issue by using an explicit intersects filter I'm lending more towards the fist solution, that can be implemented in a matter of hours. Any objection? Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
