I am using the Geometry Function Filter for the styles used for rendering FeatureTypes of type Geometry because I want polygons to be rendered as polygons and lines as lines and so on.
The problem I'm encountering is that when streaming renderer is making the request to the Datastore it sends those filters as well... In the case of WFS the WFS encodes the filters as xml (See request attachment). At a glance the request looks ok but geoserver throws an exception, I assume it can't handle the functional expression.
(attachments)
Exception.rtf (7.74 KB)
Request.rtf (2.93 KB)
I came across this issue when doing udig / geoserver testing. Another possiblity could be to extend the datastore api to incoporate the notion of "supported" functions, similar to how wfs does in a capabilities document. This way the renderer could be a little smarter about creating function filters. Sending the supported ones directly to the datastore, and post-processing the remaining ones. This would be nice for postgis as we could then encode the functions as sql and pick up the performance benefit.
-Justin
Jesse Eichar wrote:
I am using the Geometry Function Filter for the styles used for rendering FeatureTypes of type Geometry because I want polygons to be rendered as polygons and lines as lines and so on.
The problem I'm encountering is that when streaming renderer is making the request to the Datastore it sends those filters as well... In the case of WFS the WFS encodes the filters as xml (See request attachment). At a glance the request looks ok but geoserver throws an exception, I assume it can't handle the functional expression.
Also Postgis throws exceptions. So basically the Functional filters are made useless by because all the datastores blow up when they are passed one of them.
What should be done?
1. We could make Streaming renderer not pass functional filters on to the datastore. (this would be a stop gap so things will start working again)
2. We could visit each datastore and make sure that each one will either ignore the filters and process them on the client side.
Jesse
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org