New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OGC Spatial filters fail if GEOS support not enabled #4431
Comments
Sounds like an #ifdef is needed someplace. |
@sdlime should all calls to |
In theory the WFS capabilities should not offer certain spatial operators if GEOS is not enabled and we should throw an exception if one of those are used. We have fall backs (native MapServer) for some operators though (intersect is one example) so I don't think we can simply if-def the whole function. Wonder if we could pop something onto the error stack and return NULL? Otherwise we'd need to refactor the expressions. |
Pushing to 7.0... This should get cleaned up with RFC 91 since the WFS code should just author token sequences. --Steve |
these functions would still need geos is there is no spatial backend. So the if-def would have to check for the layer connection and disable if no geos for a non spatial backend. |
Which if-def are you referring to? From: Michael D. Smith [mailto:notifications@github.com] these functions would still need geos is there is no spatial backend. So the if-def would have to check for the layer connection and disable if no geos for a non spatial backend. — |
Around |
This is an automated commentThis issue has been closed due to lack of activity. This doesn't mean the issue is invalid, it simply got no attention within the last year. Please reopen with missing/relevant information if still valid. Typically, issues fall in this state for one of the following reasons:
|
If geos support is not enabled,
FLTGetSpatialComparisonCommonExpression
will silently create an invalid expression as the GEOS calls it's doing will return empty strings/geometries.The text was updated successfully, but these errors were encountered: