Hi Stefano, in the context of a virtual WMS service, the only correct combination is unqualified/unqualified, since that's how the layers are presented to the service users in the capabilities document. A client should not make assumptions about how GeoServer is set up internally, the capabilities document is "the bible", the client should only use names mentioned there.
On a more practical note though, I wish GeoServer could make a best effort and make the qualified case work too, because it's annoying to have to write a remote SLD in a different way, depending on how we'll want to use it Cheers Andrea On Fri, Nov 26, 2021 at 3:34 PM stefano pezzi <stefanope...@gmail.com> wrote: > While I was preparing the test case with the release data, I found the > SLD weirdness you suspected. > > The strange behavior is due to the presence or less of the > workspace/namespace as a qualifier of the name of the layer (in WMS > "layers" parameter and in the "Name" element of the NamedLayer inside the > SLD) in combination with the use of the global service or of the virtual > service. > > > > In particular, the behavior for the virtual service has changed: before > v.2.19.3, there was a match only with qualified NamedLayer/Name > (regardless the value of parameter layers) and after it has become the > opposite: the match is obtained only with unqualified NamedLayer/Name in > SLD. > > > > I summarized the results in the following tables: > > > > > > > 2.18.5------------------------------------------------------------------------------------------------- > > > > Global WMS service > > GetMap “layers” parameter > > qualified > > unqualified > > SLD > > <Name> of <NamedLayer> > > qualified > > OK > > KO > (possible layer mismatch or not found) > > unqualified > > KO > > (remote SLD ignored) > > KO > (possible layer mismatch or not found) > > > > > > Virtual WMS service > > GetMap “layers” parameter > > qualified > > unqualified > > SLD > > <Name> of <NamedLayer> > > qualified > > OK > > OK > > unqualified > > KO > > (remote SLD ignored) > > KO > > (remote SLD ignored) > > > > > > > 2.20.1------------------------------------------------------------------------------------------------- > > > > Global WMS service > > GetMap “layers” parameter > > qualified > > unqualified > > SLD > > <Name> of <NamedLayer> > > qualified > > OK > > KO > (possible layer mismatch or not found) > > unqualified > > KO > > (remote SLD ignored) > > KO > (possible layer mismatch or not found) > > > > > > Virtual WMS service > > GetMap “layers” parameter > > qualified > > unqualified > > SLD > > <Name> of <NamedLayer> > > qualified > > KO > > (remote SLD ignored) > > KO > (remote SLD ignored) > > unqualified > > OK > > OK > > > > > None of the behaviors is the right one for me, because in a virtual > service the match should always happen, but should I open a ticket for a > bug or will it be just a warning in the documentation? > > > Cheers, > > Stefano > > > > On Fri, Nov 26, 2021 at 8:22 AM Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> Can't say if it's a bug or you're just hitting a weirdness of the SLD >> library mode that got fixed. >> Please open a ticket sharing a reproducible test case, with data and >> style (possibly against >> the release data directory, otherwise please also share the data >> involved). >> >> Cheers >> Andrea >> >> >> On Thu, Nov 25, 2021 at 8:39 PM stefano pezzi <stefanope...@gmail.com> >> wrote: >> >>> Hi all, >>> >>> I’m using WMS GetMap passing a remote SLD style to be retrieved by the >>> server at the URL specified in the SLD parameter. >>> >>> Everything was fine until version 2.19.3 (GeoTools v.25.3). Starting >>> with this version, the remote SLD seems to be fetched and parsed, but >>> finally the default style configured in the catalogue is applied. >>> >>> The log file has lines like the followings: >>> >>> >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> Request: getServiceInfo >>> >>> 2021-11-25 15:14:43,018 DEBUG [org.geotools.data.util] - >>> CRSConverterFactory can be applied from Strings to CRS only. >>> >>> 2021-11-25 15:14:43,018 DEBUG [org.geotools.data.util] - >>> InterpolationConverterFactory can be applied from Strings to Interpolation >>> only. >>> >>> 2021-11-25 15:14:43,102 TRACE [org.geotools.filter] - processing root Or >>> ogc:Or >>> >>> 2021-11-25 15:14:43,103 TRACE [org.geotools.filter] - looking up Or >>> >>> 2021-11-25 15:14:43,103 TRACE [org.geotools.filter] - a logical filter Or >>> >>> 2021-11-25 15:14:43,103 TRACE [org.geotools.filter] - adding to logic >>> filter PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,103 TRACE [org.geotools.filter] - processing root >>> PropertyIsEqualTo ogc:PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,104 TRACE [org.geotools.filter] - looking up >>> PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,104 DEBUG [org.geotools.filter] - a comparision >>> filter PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,104 DEBUG [org.geotools.filter] - type is 14 >>> >>> 2021-11-25 15:14:43,104 TRACE [org.geotools.filter] - add left value -> >>> [ogc:PropertyName: null]<- >>> >>> 2021-11-25 15:14:43,105 DEBUG [org.geotools.filter] - processing root >>> PropertyName >>> >>> 2021-11-25 15:14:43,105 TRACE [org.geotools.filter] - add right value -> >>> [ogc:Literal: null]<- >>> >>> 2021-11-25 15:14:43,105 DEBUG [org.geotools.filter] - processing root >>> Literal >>> >>> 2021-11-25 15:14:43,105 DEBUG [org.geotools.filter] - processing literal >>> [ogc:Literal: null] >>> >>> 2021-11-25 15:14:43,106 TRACE [org.geotools.filter] - literal elements >>> (1) [ogc:Literal: null] >>> >>> 2021-11-25 15:14:43,106 TRACE [org.geotools.filter] - kid 0 [#text: >>> ESAB11000] >>> >>> 2021-11-25 15:14:43,106 DEBUG [org.geotools.filter] - processing >>> ESAB11000 >>> >>> 2021-11-25 15:14:43,106 TRACE [org.geotools.filter] - adding to logic >>> filter PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,107 TRACE [org.geotools.filter] - processing root >>> PropertyIsEqualTo ogc:PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,107 TRACE [org.geotools.filter] - looking up >>> PropertyIsEqualTo >>> >>> 2021-11-25 15:14:43,107 DEBUG [org.geotools.filter] - a comparision >>> filter PropertyIsEqualTo >>> >>> … >>> >>> >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> showing that the remote Style is being processed (it is a categorized >>> thematization with labels), but at the end the simple default “Polygon” >>> style is applied. I also find this log line, going along the file: >>> >>> >>> >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> >>> 2021-11-25 15:14:43,177 DEBUG [org.geotools.data.shapefile] - The DBF >>> file won't be opened since no attributes will be read from it >>> >>> >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> that demonstrates that the attributes of the shapefile are not useful >>> for the renderization, since a unique simple style is being used. >>> >>> I also checked with version 2.20.0 and 2.20.1 and got the same wrong >>> results, whilst 2.16.0, 2.18.5, 2.19.0, 2.19.1 and 2.19.2 are doing well >>> with the same data and same styles. >>> >>> >>> Stefano >>> _______________________________________________ >>> 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 >>> >>> >>> Geoserver-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-users >>> >> >> >> -- >> >> Regards, >> >> Andrea Aime >> >> == >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> == >> >> Ing. Andrea Aime >> @geowolf >> Technical Lead >> >> GeoSolutions Group >> phone: +39 0584 962313 >> >> fax: +39 0584 1660272 >> >> mob: +39 333 8128928 >> >> https://www.geosolutionsgroup.com/ >> >> http://twitter.com/geosolutions_it >> >> ------------------------------------------------------- >> >> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >> precisa che ogni circostanza inerente alla presente email (il suo >> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >> >> This email is intended only for the person or entity to which it is >> addressed and may contain information that is privileged, confidential or >> otherwise protected from disclosure. We remind that - as provided by >> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >> e-mail or the information herein by anyone other than the intended >> recipient is prohibited. If you have received this email by mistake, please >> notify us immediately by telephone or e-mail >> > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
_______________________________________________ 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 Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
