Converting SLD to CQL sounds complicated. We use SQL Views to accomplish things like full text search, since the semantics of CQL don't lend well to it. Or at least, we haven't found a way to do it with CQL (without adding custom filters). SQL Views allow you to simplify the API for the client side. It may not need to know too much of how to build CQL expressions.
Jason Newmoyer Newmoyer Geospatial Solutions 843.606.0424 [email protected] On Tue, Sep 25, 2018 at 12:31 PM César Augusto Ribeiro <[email protected]> wrote: > Hey Rusu, > Great assumptions (except I don't bother about scale dependency atm). > > More details about the project: > > - Angular 6 frontend, with addition of LeafletJS; > - Yes, the layers/overlays in question are WMS based, consumed throught > github.com/heigeo/leaflet.wms; > - "Attached" with each layer added to the map, there are a couple of > fields, that allows the user to filter such layer; > - The filter task is an application's custom GET request to the WFS > GetFeature related to the layer and based on fields filled by the user > (which are translated into CQL Filters) and it's results are translated to > a Leaflet's GeoJSON layer, just to highlight features in the already > rendered layer. > > I did think about the common practice you mentioned and was wondering: > what if I GET the SLD related to layer (if possible) and maybe transform > it's result into CQL Filters to apply to my WFS GetFeature dynamically > (maybe initially ignoring the scale stuff)? Could be a good thing or you > see it's better to keep the custom search layer? > > Thanks! > > > 2018-09-25 11:40 GMT-03:00 Rusu Sorin <[email protected]>: > >> Hi, >> >> There are some missing information from what you wrote to the list, and >> as always, if possible concrete examples help (especially if your geoserver >> is public) >> >> *My assumptions:* >> You are working with WMS that has a SLD that filters various elements >> in the dataset in order to compose clean maps >> The SLD is probably scale dependennt (various scales show various >> types of data). >> >> *Unknowns*: >> The application/framework you are using to filter the data via WFS >> >> What you would like to see happen is going to be difficult, and is not >> necesserily supported out of the box: >> It is my understanding that the WFS service in geoserver doesn't >> communicate/care/bother with the SLD since it was only designed for use >> with image generation (and GtFeatureInfo, which also relies on retrieving >> data based on rendered output). >> You would basically have to pass the currently active filter in the >> SLD to the WFS in order to first filter out "unwanted/invisible" features, >> and then use the CQL Filter, and WFS feature types are not scale-dependent >> Depending on the application you are using this might be more or less >> achievable. >> A published Geoserver "layer" can be used and reused many times in >> the SLD, giving you the "WMS rendering layers", but the published dataset >> will only be a single FeatureType in the WFS (publishing all the data from >> the source). >> >> Common practice would have you designing a custom "search" layer >> where only the "searchable" features should be configured. >> >> Sorin RUSU >> >> >> Pe marți, 25 septembrie 2018 17:26:15 EEST, carrbrpoa < >> [email protected]> a scris: >> >> >> I'm trying to "search" for things in a GeoServer published layer, through >> an >> webmapping app. >> >> For that, I'm using WFS/GetFeature, applying CQL Filters as needed. The >> problem is that the style of the published layer omits some features >> (SLD's >> rules) and seems that WFS/GetFeature is not aware of that. >> >> Based on that, the results of the WFS/GetFeature can point to features >> otherwise hidden for SLD's rules (what I don't want, actually). >> >> Do you have any suggestions for that? >> >> Thanks in advance! >> >> >> >> -- >> Sent from: >> http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html >> >> >> _______________________________________________ >> Geoserver-users mailing list >> >> Please make sure you read the following two resources before posting to >> this list: >> - Earning your support instead of buying it, but Ian Turton: >> http://www.ianturton.com/talks/foss4g.html#/ >> - The GeoServer user list posting guidelines: >> http://geoserver.org/comm/userlist-guidelines.html >> >> If you want to request a feature or an improvement, also see this: >> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer >> >> >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-users >> >> > > > -- > Atenciosamente, > > César Augusto R. Ribeiro > _______________________________________________ > Geoserver-users mailing list > > Please make sure you read the following two resources before posting to > this list: > - Earning your support instead of buying it, but Ian Turton: > http://www.ianturton.com/talks/foss4g.html#/ > - The GeoServer user list posting guidelines: > http://geoserver.org/comm/userlist-guidelines.html > > If you want to request a feature or an improvement, also see this: > https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer > > > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-users >
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
