https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
I imagine we will discuss this GISP in today’s geoserver meeting if you would like to join.
On 11 July 2017 at 09:55, David Vick <dvick@…3839…> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Jody Garnett
Thanks David and Torben, this will be a little bit of a challenge to
explain - one wrinkle that may be a challenge is calculating the bounds
when one of these style groups is used.By calculating bounds, I assume you mean in the UI, when defining the
layer group. Off the top of my head, I can think of a couple options:
1. Use the CRS bounds of the LayerGroup when calculating bounds for one
of these groups (since they are ostensibly unknown, and subject to change)
2. Parse the layer names out of the linked style, and then calculate
bounds from there. Given that the calculated bounds for a layer group
typically must be changed manually when the layers change anyways, the fact
that these bounds may become out of date if the style changes seems fine,
and in line with the current behaviour.
Torben
Hi,
I had a quick look at the proposal and I cannot really wrap my head around it, honestly as
I read it it seems hacky but instinctively I blame the way it’s presented instead of the substance.
Could you for example show a step by step of it would be used referring only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer SLD and then make it into a group
with the current UI?
And then again, using the REST API?
Cheers
Andrea
On Tue, Jul 11, 2017 at 7:10 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
I imagine we will discuss this GISP in today’s geoserver meeting if you would like to join.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
–
Jody Garnett
On 11 July 2017 at 09:55, David Vick <dvick@anonymised.com> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
I think we can also calculate bounds via rest api?
On 11 July 2017 at 10:19, Torben Barsballe <tbarsballe@anonymised.com> wrote:
–
Jody Garnett
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
By calculating bounds, I assume you mean in the UI, when defining the layer group. Off the top of my head, I can think of a couple options:
Use the CRS bounds of the LayerGroup when calculating bounds for one of these groups (since they are ostensibly unknown, and subject to change)
Parse the layer names out of the linked style, and then calculate bounds from there. Given that the calculated bounds for a layer group typically must be changed manually when the layers change anyways, the fact that these bounds may become out of date if the style changes seems fine, and in line with the current behaviour.
Torben
On Tue, Jul 11, 2017 at 10:37 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
I think we can also calculate bounds via rest api?
I though that was still one of the things we could only do in the UI? I
would be happy to be wrong though.
On Tue, Jul 11, 2017 at 10:25 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:
Hi,
I had a quick look at the proposal and I cannot really wrap my head around
it, honestly as
I read it it seems hacky but instinctively I blame the way it's presented
instead of the substance.Could you for example show a step by step of it would be used referring
only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer
SLD and then make it into a group
with the current UI?
And then again, using the REST API?Cheers
Andrea
The main idea with this GSIP is just promoting the existing NamedLayer
functionality in SLD to a first class citizen in GeoServer.
The GSIP has been updated with (fairly basic) examples for how one would
use the new functionality (see "Using Style Groups", in the Proposal
section).
There is now also a detailed description of the existing functionality this
is based upon at the end of the GSIP, and how it would be used in a current
GeoServer (See "Use of Multi-Layered SLD Files in GeoServer").
Torben
I know there is a recalculate REST endpoint we use when we upload new files through our process.
Using this XML and endpoint
%s
%s
0
0
"
String path = String.*format*(**"rest/workspaces/%s/datastores/%s/featuretypes/%s.xml"**, workspace, dataStore, layerName);
Map<String, String> queryParams = **new** HashMap<>();
queryParams.put(**"recalculate"**, **"nativebbox,latlonbbox"**);
And process as a PUT request
Documented at
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, A Polaris Alpha Company
From: Torben Barsballe [mailto:tbarsballe@…3839…]
Sent: Tuesday, July 11, 2017 1:56 PM
To: Jody Garnett <jody.garnett@…403…>; Andrea Aime <andrea.aime@…1268…>
Cc: GeoServer geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] GSIP 161
On Tue, Jul 11, 2017 at 10:37 AM, Jody Garnett <jody.garnett@…403…> wrote:
I think we can also calculate bounds via rest api?
I though that was still one of the things we could only do in the UI? I would be happy to be wrong though.
On Tue, Jul 11, 2017 at 10:25 AM, Andrea Aime <andrea.aime@…1268…> wrote:
Hi,
I had a quick look at the proposal and I cannot really wrap my head around it, honestly as
I read it it seems hacky but instinctively I blame the way it’s presented instead of the substance.
Could you for example show a step by step of it would be used referring only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer SLD and then make it into a group
with the current UI?
And then again, using the REST API?
Cheers
Andrea
The main idea with this GSIP is just promoting the existing NamedLayer functionality in SLD to a first class citizen in GeoServer.
The GSIP has been updated with (fairly basic) examples for how one would use the new functionality (see “Using Style Groups”, in the Proposal section).
There is now also a detailed description of the existing functionality this is based upon at the end of the GSIP, and how it would be used in a current GeoServer (See “Use of Multi-Layered SLD Files in GeoServer”).
Torben
On Tue, Jul 11, 2017 at 1:17 PM, Chris Snider <chris.snider@anonymised.com
wrote:
I know there is a recalculate REST endpoint we use when we upload new
files through our process.Using this XML and endpoint
*<featureType>*
* <enabled>%s</enabled>*
* <advertised>%s</advertised>*
* <maxFeatures>0</maxFeatures>*
* <numDecimals>0</numDecimals>*
*</featureType>"*
String path = String.*format*(*"rest/workspaces/%s/datastores/%s/featuretypes/%s.xml"*, workspace, dataStore, layerName);
Map<String, String> queryParams = *new *HashMap<>();
queryParams.put(*"recalculate"*, *"nativebbox,latlonbbox"*);And process as a PUT request
Documented at
REST configuration API reference — GeoServer 2.26.x User Manual
featuretypes.html#rest-api-featuretypes-recalculate
That is just for the featuretypes endpoint though, so while quite useful
for dealing with layers, doesn't help with recalculating LayerGroup bounds
(as is being discussed here). I don't think there is an equivalent for
LayerGroups yet.
Torben
AH, missed that part
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, A Polaris Alpha Company
On Tue, Jul 11, 2017 at 1:17 PM, Chris Snider <chris.snider@…4594…> wrote:
I know there is a recalculate REST endpoint we use when we upload new files through our process.
Using this XML and endpoint
%s
%s
0
0
"
String path = String.*format*(**"rest/workspaces/%s/datastores/%s/featuretypes/%s.xml"**, workspace, dataStore, layerName);Map<String, String> queryParams = **new** HashMap<>(); queryParams.put(**"recalculate"**, **"nativebbox,latlonbbox"**);And process as a PUT request
Documented at
That is just for the featuretypes endpoint though, so while quite useful for dealing with layers, doesn’t help with recalculating LayerGroup bounds (as is being discussed here). I don’t think there is an equivalent for LayerGroups yet.
Torben
Andrea I think the GSIP now answers your questions, it was discussed in yesterday’s meeting and refined with an example SLD and example step by step instructions.
On 11 July 2017 at 10:25, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I had a quick look at the proposal and I cannot really wrap my head around it, honestly as
I read it it seems hacky but instinctively I blame the way it’s presented instead of the substance.Could you for example show a step by step of it would be used referring only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer SLD and then make it into a group
with the current UI?
And then again, using the REST API?Cheers
Andrea
–
Jody Garnett
On Tue, Jul 11, 2017 at 7:10 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
I imagine we will discuss this GISP in today’s geoserver meeting if you would like to join.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
–
Jody Garnett
On 11 July 2017 at 09:55, David Vick <dvick@anonymised.com> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hi Jody,
I don’t think it does yet, but I could only glance over it. Please allow some time to look
at it, there’s FOSS4G next week and I have stuff to finish before I leave for Paris.
Cheers
Andrea
On Wed, Jul 12, 2017 at 6:15 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Andrea I think the GSIP now answers your questions, it was discussed in yesterday’s meeting and refined with an example SLD and example step by step instructions.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
–
Jody Garnett
On 11 July 2017 at 10:25, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I had a quick look at the proposal and I cannot really wrap my head around it, honestly as
I read it it seems hacky but instinctively I blame the way it’s presented instead of the substance.Could you for example show a step by step of it would be used referring only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer SLD and then make it into a group
with the current UI?
And then again, using the REST API?Cheers
Andrea
On Tue, Jul 11, 2017 at 7:10 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
I imagine we will discuss this GISP in today’s geoserver meeting if you would like to join.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
–
Jody Garnett
On 11 July 2017 at 09:55, David Vick <dvick@anonymised.com.> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Again I won’t have any time to look at this until I’m in Paris or after.
Ian
On 12 Jul 2017 17:45, “Andrea Aime” <andrea.aime@anonymised.com> wrote:
Hi Jody,
I don’t think it does yet, but I could only glance over it. Please allow some time to look
at it, there’s FOSS4G next week and I have stuff to finish before I leave for Paris.Cheers
Andrea
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Wed, Jul 12, 2017 at 6:15 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Andrea I think the GSIP now answers your questions, it was discussed in yesterday’s meeting and refined with an example SLD and example step by step instructions.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
–
Jody Garnett
On 11 July 2017 at 10:25, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I had a quick look at the proposal and I cannot really wrap my head around it, honestly as
I read it it seems hacky but instinctively I blame the way it’s presented instead of the substance.Could you for example show a step by step of it would be used referring only core concepts/functionality
(mapbox is not even an extension), like, how does one define a multi-layer SLD and then make it into a group
with the current UI?
And then again, using the REST API?Cheers
Andrea
On Tue, Jul 11, 2017 at 7:10 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Thanks David and Torben, this will be a little bit of a challenge to explain - one wrinkle that may be a challenge is calculating the bounds when one of these style groups is used.
I imagine we will discuss this GISP in today’s geoserver meeting if you would like to join.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
–
Jody Garnett
On 11 July 2017 at 09:55, David Vick <dvick@anonymised.com> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ok,
more substantive review this time.
So, StyleGroup is really a link to a multi-layer SLD.
The statement “StyleGroupInfo will not be stored as catalog objects” threw me off a few times, I believe that what you mean is that
StyleGroupInfo is not a top level catalog object, so it has no identity, and cannot be searched directly from a catalog object,
but can only be found by scanning the containing group (I had no familiarity with LegendInfo so could not really see what you meant there
at a first read).
Making it a PublishedInfo will cause some confusion in Catalog, as one can search for PublishedInfo in the list method
of the Catalog, e.g. in the preview page we have:
CloseableIterator pi = catalog.list(PublishedInfo.class, filter, (int) first, …
Since this thing exist only in a group, does it make sense to list it? Basically a style is just a style, but becomes a group
the moment it’s being referred as one in another layer group… and you say it can be chosen and previewed in the style editor
(but really, what you’re doing there is previewing the current style no?)
but when you refer to it from the layer preview, then it can only be previewed through the containing group?
My head is starting to spin.
Then I see the rest representation, and it really looks like what you’re after there is a empty layer slot with
a style attached to it, and when that happens, then the style is to be used as as a sub-group definition.
Before I make a counter proposal, one more thing, I have a patch sitting on my disk allowing someone to
preview a group while editing a style, because it’s common to have to look at a whole map while tweaking
a single style of it.
With this in mind, wouldn’t it be simpler to just allow the layer group to have an empty layer entry, and when
that happens, then make the style spec compulsory and use it as the source of layers, without the need
to be talking about a style group to start with?
If you modify the LayerGroupHelper to perform the style expansion when no layer is found, most of the
current code should be working already.
In the style editor, then also allow a “preview style as a group” link/option, that would activate
after checking that the style is indeed referring to layers (existing ones).
Now, some other concerns the proposal is not covering.
Using GetMap with SLD or SLD_BODY the code will perform a few consistency checks (assuming you’re not entering library mode, mind), in particular, that all layers referred to by name are there.
However, nowadays most styles are not referring to layers, or are referring to layers that do not exist, so some checking
should be done, either before or after the fact, to ensure a style used as a group definition is indeed suitable for the job.
Also, taken into consideration deletion and cascading deletion via UI and REST. Nowadays if a layer gets removed
groups containing it are found and listed in a warning dialog, and on confirmation they are updated removing the
layer.
If a layer is referred by a style group, what do we do? Update the style? Disallow the deletion?
Or allow the catalog to get into an inconsistent state? The latter does not seem acceptable to me, as the current behavior does better than that.
Also, nowadays references to layers are done via ID, which is an immutable, but style groups would be referring layer by
name, which is mutable instead. So a new set of checks should be enacted, making sure that when a store changes
workspace, or a layer gets renamed, the style groups referring to it are modified.
I see no other option here, as disallowing the change would require the user to first remove the reference from the style,
then modify the store/layer, and then go back and add the new name in the style.
One final note on the editing of such styles. Nowadays when validating a style we just check it’s valid in generic
terms, that it can be parsed. But binding it to a layer seems to suggest two more validations could be performed:
nowadays it’s not done. So don’t take this a requirement.
Cheers
Andrea
On Tue, Jul 11, 2017 at 6:55 PM, David Vick <dvick@anonymised.com> wrote:
https://github.com/geoserver/geoserver/wiki/GSIP-161
We have submitted a GeoServer Improvement Proposal for adding the ability to define LayerGroups through a SLD. Currently this can be achieved by using external SLD’s and we propose to enable GeoServer to create/publish LayerGroups from it’s styles stored in the catalog.
Looking forward to your comments.
David Vick
Professional Services Engineer | Boundless
dvick@anonymised.com
mobile: +1-636-698-3174
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Ah, forgot one more concern, which is related to workspace specific
services.
I setup an example group on a demo server for you to look at, it's a globa
one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace
specific services, and the
catalog will automatically shave off the layers that are not part of the
current workspace
transparently, please see and compare:
http://demo.geo-solutions.it/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=test&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers
http://demo.geo-solutions.it/geoserver/geosolutions/wms?service=WMS&version=1.1.0&request=GetMap&layers=test&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers
http://demo.geo-solutions.it/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=test&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers
What happens when style groups enter the picture? Is the catalog going to
alter the style
on the fly to remove references to layers that are not visible in the
current workspace?
And the same should happen with security, if a layer is not visible and
referenced by a group today, the
layer is removed transparently from the group as it gets out of the
catalog, I assume the same would
have to happen for nested style groups, right?
I'm also wondering, is nesting style groups in standard groups a
requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?
If it's the latter, wouldn't it be simpler to extend the current GetMap
protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal
style known by GeoServer?
Hell, wouldn't it be even simpler to allow SLD to take either a URL, or a
style name, and be done with it [1]? 
If you need to mix it with other layers, how about allowing an empty layer
name in the layer list,
and if that happens then take the style name a group?
Just thinking out loud here!
Cheers
Andrea
[1] Well, almost be done, even using a style like this would incur in
security and more in general
catalog filtering related issues.
I’m going to to try and address most of your comments and questions inline, then send a summary in another email, so please bear with me.
On Fri, Jul 14, 2017 at 9:17 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Ok,
more substantive review this time.So, StyleGroup is really a link to a multi-layer SLD.
The statement “StyleGroupInfo will not be stored as catalog objects” threw me off a few times, I believe that what you mean is that
StyleGroupInfo is not a top level catalog object, so it has no identity, and cannot be searched directly from a catalog object,
but can only be found by scanning the containing group (I had no familiarity with LegendInfo so could not really see what you meant there
at a first read).
Correct. Additionally, we’d probably only ever use a single static instance, similar to CatalogFacade.NO_WORKSPACE
Making it a PublishedInfo will cause some confusion in Catalog, as one can search for PublishedInfo in the list method
of the Catalog, e.g. in the preview page we have:CloseableIterator pi = catalog.list(PublishedInfo.class, filter, (int) first, …
Since this thing exist only in a group, does it make sense to list it? Basically a style is just a style, but becomes a group
Probably not, since it is not something in the catalog with an id.
the moment it’s being referred as one in another layer group… and you say it can be chosen and previewed in the style editor
(but really, what you’re doing there is previewing the current style no?)
Yes, previewing the current style. For the style editor, this would probably be implemented through the WMS SLD parameter, rather than a StyleGroup (I think the proposal mentions this, but if not I can update it).
but when you refer to it from the layer preview, then it can only be previewed through the containing group?
My head is starting to spin.Then I see the rest representation, and it really looks like what you’re after there is a empty layer slot with
a style attached to it, and when that happens, then the style is to be used as as a sub-group definition.Before I make a counter proposal, one more thing, I have a patch sitting on my disk allowing someone to
preview a group while editing a style, because it’s common to have to look at a whole map while tweaking
a single style of it.With this in mind, wouldn’t it be simpler to just allow the layer group to have an empty layer entry, and when
that happens, then make the style spec compulsory and use it as the source of layers, without the need
to be talking about a style group to start with?
That does accomplish the same thing, without making (as many) changes to the Catalog API. Null entries in the layer list of a layer group feels a bit hacky, but we already do this for styles (when using a default style), so I guess it is fine.
If you modify the LayerGroupHelper to perform the style expansion when no layer is found, most of the
current code should be working already.In the style editor, then also allow a “preview style as a group” link/option, that would activate
after checking that the style is indeed referring to layers (existing ones).
Now, some other concerns the proposal is not covering.
Using GetMap with SLD or SLD_BODY the code will perform a few consistency checks (assuming you’re not entering library mode, mind), in particular, that all layers referred to by name are there.However, nowadays most styles are not referring to layers, or are referring to layers that do not exist, so some checking
should be done, either before or after the fact, to ensure a style used as a group definition is indeed suitable for the job.Also, taken into consideration deletion and cascading deletion via UI and REST. Nowadays if a layer gets removed
groups containing it are found and listed in a warning dialog, and on confirmation they are updated removing the
layer.
If a layer is referred by a style group, what do we do? Update the style? Disallow the deletion?
Or allow the catalog to get into an inconsistent state? The latter does not seem acceptable to me, as the current behavior does better than that.
Updating the style seems infeasible, especially given the number of supported style formats we have (I’m not sure if CSS has an equivalent to NamedLayers, but I am fairly sure YSLD does).
If you are using this feature in the first place, I expect it is likely you intend to have a style that can easily be transferred between different systems (e.g., different geoservers, or geoserver and some other program that supports SLD), assuming they have the same layer names defined.
My first thought would have been to treat the style like any other external style, and allow it to become invalid, but I can see how this would be problematic.
That said, even in current geoserver, it is not uncommon to make a style invalid after some sort of catalog change (moreso if there are changes to the underlying data, especially changes to attribute names, but even so…), or have a style that only works against certain layers.
Given this, I am still leaning towards letting the change (be it deleting a layer, or renaming one) go through without any changes to the style. In the case of a deletion through the UI, we could present a custom warning dialog. As for the REST api, we could send along an informational message with the 200 response.
Also, nowadays references to layers are done via ID, which is an immutable, but style groups would be referring layer by
name, which is mutable instead. So a new set of checks should be enacted, making sure that when a store changes
workspace, or a layer gets renamed, the style groups referring to it are modified.
I see no other option here, as disallowing the change would require the user to first remove the reference from the style,
then modify the store/layer, and then go back and add the new name in the style.
As above, this sort of style is well-suited for transfer between different systems, in part because it refers to layers by name. I agree that disallowing the name change would be problematic.
Since the style body is not actually part of the Catalog, checks for style name would be relatively expensive from a performance perspective, since one would have to parse any styles in a group and check for name matches.
There is also the complication that the if the layer name has no workspace prefix, it will apply to the layer in the default workspace, so changing the default workspace will also affect the validity of such styles.
One final note on the editing of such styles. Nowadays when validating a style we just check it’s valid in generic
terms, that it can be parsed. But binding it to a layer seems to suggest two more validations could be performed:
- Check that the layer exists
- Check the attributes referred from the styles are usable with that layer
I say could because at least the second one could also be performed when associating a layer to a style, andnowadays it’s not done. So don’t take this a requirement.
This touches on one of the reasons it is so easy to have an invalid style these days.
My biggest concern with enforcing style validity in this case is if you are editing a fairly large style (perhaps already associated with a style), and want to save it part way through, even if it might not be valid (this is especially relevant for GeoServer, given the standard server timeout). This is one of the reasons that the Style Editor UI still allows you so save a syntactically invalid style.
Cheers
Andrea
Torben
Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <andrea.aime@…1268…> wrote:
Good question. My first response would be what do we do currently if you use an external SLD via the WMS SLD parameter while making a WMS request from a workspace specific service.
After trying it out, it handles it as if the layer doesn’t exist, and fails with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to respect security and virtual service restrictions. It may be better to change this behaviour to simply exclude layers that can’t be found (and log a warning), although this might be something that can be controlled by an additional parameter, so that we can still treat missing layers in a more strict fashion.
For the StyleGroup, I would expect it would trim out any layers when parsing the SLD. The current code for handling the SLD parameter (In GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each NamedLayer within the SLD into separate MapLayer and Style objects, so I expect it would be possible to trim out any layers that would be hidden to to workspace-specific services or security rules at this point.
It mostly the latter, although it would still be useful to be able to refer to regular layers and StyleGroups in the same WMS, such as if you had a style group that defines a basemap, and wanted to show some additional layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and you can use a GeoServer-internal style this way via the styles endpoint (localhost:8080/geoserver/styles/stylename.sld). Adding the ability to refer to an internal style by name / relative URL would be a simple improvement, and a potential alternative.
You mentioned this in your earlier mail, and I think that would be a perfectly workable alternative to an actual StyleGroup object.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ah, forgot one more concern, which is related to workspace specific services.
I setup an example group on a demo server for you to look at, it’s a globa one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace specific services, and the
catalog will automatically shave off the layers that are not part of the current workspace
transparently, please see and compare:
What happens when style groups enter the picture? Is the catalog going to alter the style
on the fly to remove references to layers that are not visible in the current workspace?
And the same should happen with security, if a layer is not visible and referenced by a group today, the
layer is removed transparently from the group as it gets out of the catalog, I assume the same would
have to happen for nested style groups, right?
I’m also wondering, is nesting style groups in standard groups a requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?
If it’s the latter, wouldn’t it be simpler to extend the current GetMap protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal style known by GeoServer?
Hell, wouldn’t it be even simpler to allow SLD to take either a URL, or a style name, and be done with it [1]? 
If you need to mix it with other layers, how about allowing an empty layer name in the layer list,
and if that happens then take the style name a group?
Just thinking out loud here!
Cheers
Andrea
[1] Well, almost be done, even using a style like this would incur in security and more in general
catalog filtering related issues.
Summary:
Suggestion - use an empty layer entry in the layers list of the Layer Group, instead of adding the StyleGroupInfo class:
This seems a little hacky, but I don’t see any real problems with it.
Overall results in a smaller API change, so I am happy with this suggestion.
Style Validation - Deleting or renaming layers referred to by StyleGroups:
Overall, I would prefer going with the current prevalent approach of leaving most of the onus of keeping the style valid upon the user. I think adding warnings to the UI where deleting or renaming a layer would make a StyleGroup invalid would definitely be valuable.
I agree preventing deletion of a layer referred to by a style group is unacceptable.
I think modifying a style group programatically when layers are renamed is a bad idea, for a number of reasons:
Handling Virtual Services / Security:
Current behaviour for external SLDs is to fail with a “layer not found”. For a Style Group, I would prefer to implement a softer failure of just dropping the layer from the output, to match with the current treatment of layer groups. It may be valuable to extend this implementation to the treatment of external styles as well (Perhaps as a configurable option if this is necessary to remain compliant with the SLD / WMS spec).
Alternative approach - just use the WMS SLD parameter (extend it to support referencing local styles by name) instead of modifying layer group behaviour:
I would rather extend the layer group functionality, as it allows combining Style Groups with regular layers. However, I think extending the SLD parameter would still be a workable alternative.
Torben
On Fri, Jul 14, 2017 at 11:15 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Good question. My first response would be what do we do currently if you use an external SLD via the WMS SLD parameter while making a WMS request from a workspace specific service.
After trying it out, it handles it as if the layer doesn’t exist, and fails with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to respect security and virtual service restrictions. It may be better to change this behaviour to simply exclude layers that can’t be found (and log a warning), although this might be something that can be controlled by an additional parameter, so that we can still treat missing layers in a more strict fashion.
For the StyleGroup, I would expect it would trim out any layers when parsing the SLD. The current code for handling the SLD parameter (In GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each NamedLayer within the SLD into separate MapLayer and Style objects, so I expect it would be possible to trim out any layers that would be hidden to to workspace-specific services or security rules at this point.
It mostly the latter, although it would still be useful to be able to refer to regular layers and StyleGroups in the same WMS, such as if you had a style group that defines a basemap, and wanted to show some additional layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and you can use a GeoServer-internal style this way via the styles endpoint (localhost:8080/geoserver/styles/stylename.sld). Adding the ability to refer to an internal style by name / relative URL would be a simple improvement, and a potential alternative.
You mentioned this in your earlier mail, and I think that would be a perfectly workable alternative to an actual StyleGroup object.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ah, forgot one more concern, which is related to workspace specific services.
I setup an example group on a demo server for you to look at, it’s a globa one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace specific services, and the
catalog will automatically shave off the layers that are not part of the current workspace
transparently, please see and compare:
What happens when style groups enter the picture? Is the catalog going to alter the style
on the fly to remove references to layers that are not visible in the current workspace?
And the same should happen with security, if a layer is not visible and referenced by a group today, the
layer is removed transparently from the group as it gets out of the catalog, I assume the same would
have to happen for nested style groups, right?
I’m also wondering, is nesting style groups in standard groups a requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?
If it’s the latter, wouldn’t it be simpler to extend the current GetMap protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal style known by GeoServer?
Hell, wouldn’t it be even simpler to allow SLD to take either a URL, or a style name, and be done with it [1]?
If you need to mix it with other layers, how about allowing an empty layer name in the layer list,
and if that happens then take the style name a group?
Just thinking out loud here!
Cheers
Andrea
[1] Well, almost be done, even using a style like this would incur in security and more in general
catalog filtering related issues.
Hi Torben,
we sort of agree on a few points, besides one major disagreement, which is the handling of
configuration consistency.
This statement is provably false: “My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer”
Any attempt to change a layer name, a store workspace, or remove it, is today followed by a warning and an automatic re-alignment of the configuration on save.
Any security application is completely transparent to the group configuration too.
Yes, it’s possible to make a style not work with a layer, just remove an attribute that the style is using, or fumble and associate
the wrong style to a layer, but this is not a 0 or 1 situation, the current system does a significant effort trying to keep things
consistent (and could do better, I agree), this new one would do nothing at all instead, in other words, it’s anything but transparent and/or automatic.
Now, you say it’s an extension of the current SLD/SLD_BODY behavior, and there, I completely agree.
However, SLD/SLD_BODY is non discoverable by the novice/normal user, and not so very well documented… it smells of advanced (here be dragons) a mile away.
Putting style groups in the UI makes them be “front and center”, discoverable and usable by everybody, more rope for the common users to hang themselves,
and annoying for the advanced user that (god forbid) might have to change a layer name (ever made a typo? ever asked by a manager for a reorganization?)
and then has to hunt it down in all styles referring to it. It just cries out for automation.
And automation is indeed hard, I completely agree again, as it would require writing a plugin system to do the right thing for each styling language supporting NamedLayer
(btw, CSS would not be one of them, at least not today).
I’d be quite a bit more comfortable with the vendor params/empty layer approach in GetMap/GetFeatureInfo instead, as in that case
it would be a true-er parallel to the current SLD/SLD_BODY functionality, less “front and center”, more geared towards the advanced user
(although I’m sure we’ll get complaints about the lack of automatic updates of the styles on layer name changes even in this case,
but hopefully a smaller amount).
In its current state, I would advise against the proposed approach, but if everybody else unanimously supports it, I’ll vote -0 to
avoid blocking the proposal.
Cheers
Andrea
On Fri, Jul 14, 2017 at 9:04 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Summary:
Suggestion - use an empty layer entry in the layers list of the Layer Group, instead of adding the StyleGroupInfo class:
This seems a little hacky, but I don’t see any real problems with it.
Overall results in a smaller API change, so I am happy with this suggestion.Style Validation - Deleting or renaming layers referred to by StyleGroups:
Overall, I would prefer going with the current prevalent approach of leaving most of the onus of keeping the style valid upon the user. I think adding warnings to the UI where deleting or renaming a layer would make a StyleGroup invalid would definitely be valuable.
I agree preventing deletion of a layer referred to by a style group is unacceptable.
I think modifying a style group programatically when layers are renamed is a bad idea, for a number of reasons:
- There are several different styling languages supported by GeoServer, and some of them support NamedLayer. Most of these are not 1:1 compatible with SLD, which is to say writing from SLD to one of these layers is not always possible, or has the potential to cause destructive changes (if only to comments or structure, not behaviour).
- In general, programatically modifying a user’s style seems like a very bad idea, especially since even “SLD file” → “parsed SLD in GeoServer” → “SLD file” chain does not always result in something exactly the same.
My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer.Handling Virtual Services / Security:
Current behaviour for external SLDs is to fail with a “layer not found”. For a Style Group, I would prefer to implement a softer failure of just dropping the layer from the output, to match with the current treatment of layer groups. It may be valuable to extend this implementation to the treatment of external styles as well (Perhaps as a configurable option if this is necessary to remain compliant with the SLD / WMS spec).
Alternative approach - just use the WMS SLD parameter (extend it to support referencing local styles by name) instead of modifying layer group behaviour:
I would rather extend the layer group functionality, as it allows combining Style Groups with regular layers. However, I think extending the SLD parameter would still be a workable alternative.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
On Fri, Jul 14, 2017 at 11:15 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Good question. My first response would be what do we do currently if you use an external SLD via the WMS SLD parameter while making a WMS request from a workspace specific service.
After trying it out, it handles it as if the layer doesn’t exist, and fails with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to respect security and virtual service restrictions. It may be better to change this behaviour to simply exclude layers that can’t be found (and log a warning), although this might be something that can be controlled by an additional parameter, so that we can still treat missing layers in a more strict fashion.
For the StyleGroup, I would expect it would trim out any layers when parsing the SLD. The current code for handling the SLD parameter (In GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each NamedLayer within the SLD into separate MapLayer and Style objects, so I expect it would be possible to trim out any layers that would be hidden to to workspace-specific services or security rules at this point.
It mostly the latter, although it would still be useful to be able to refer to regular layers and StyleGroups in the same WMS, such as if you had a style group that defines a basemap, and wanted to show some additional layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and you can use a GeoServer-internal style this way via the styles endpoint (localhost:8080/geoserver/styles/stylename.sld). Adding the ability to refer to an internal style by name / relative URL would be a simple improvement, and a potential alternative.
You mentioned this in your earlier mail, and I think that would be a perfectly workable alternative to an actual StyleGroup object.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ah, forgot one more concern, which is related to workspace specific services.
I setup an example group on a demo server for you to look at, it’s a globa one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace specific services, and the
catalog will automatically shave off the layers that are not part of the current workspace
transparently, please see and compare:
What happens when style groups enter the picture? Is the catalog going to alter the style
on the fly to remove references to layers that are not visible in the current workspace?
And the same should happen with security, if a layer is not visible and referenced by a group today, the
layer is removed transparently from the group as it gets out of the catalog, I assume the same would
have to happen for nested style groups, right?
I’m also wondering, is nesting style groups in standard groups a requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?
If it’s the latter, wouldn’t it be simpler to extend the current GetMap protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal style known by GeoServer?
Hell, wouldn’t it be even simpler to allow SLD to take either a URL, or a style name, and be done with it [1]?
If you need to mix it with other layers, how about allowing an empty layer name in the layer list,
and if that happens then take the style name a group?
Just thinking out loud here!
Cheers
Andrea
[1] Well, almost be done, even using a style like this would incur in security and more in general
catalog filtering related issues.
Regards,
Andrea Aime
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Maybe we could allow a choice of multiple strategies for handling operations that invalidate styles:
Allow invalidation of style, rewrite style (Modify data structure write out if the language supports it), replace style (keep the old one, write a new one and update all references to use the new one), cascade delete (delete anything that would become invalid), cascade disable (disable anything that would become invalid)
In the UI, a warning could show up and allow the user to pick a resolution strategy maybe with a documentation link to explain their strengths and weaknesses.
In REST we would have a parameter on the operation specifying the strategy. I think the safe default would be to deny the operation if it would invalidate the style.
For rewrite/replace adding a comment explaining what happened to the new style could be helpful. This would probably require an extension to the style language API though.
On 7/14/17 12:59 PM, Andrea Aime wrote:
Hi Torben,
we sort of agree on a few points, besides one major disagreement, which is the handling of
configuration consistency.This statement is provably false: “My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer”
Any attempt to change a layer name, a store workspace, or remove it, is today followed by a warning and an automatic re-alignment of the configuration on save.
Any security application is completely transparent to the group configuration too.Yes, it’s possible to make a style not work with a layer, just remove an attribute that the style is using, or fumble and associate
the wrong style to a layer, but this is not a 0 or 1 situation, the current system does a significant effort trying to keep things
consistent (and could do better, I agree), this new one would do nothing at all instead, in other words, it’s anything but transparent and/or automatic.Now, you say it’s an extension of the current SLD/SLD_BODY behavior, and there, I completely agree.
However, SLD/SLD_BODY is non discoverable by the novice/normal user, and not so very well documented… it smells of advanced (here be dragons) a mile away.
Putting style groups in the UI makes them be “front and center”, discoverable and usable by everybody, more rope for the common users to hang themselves,
and annoying for the advanced user that (god forbid) might have to change a layer name (ever made a typo? ever asked by a manager for a reorganization?)
and then has to hunt it down in all styles referring to it. It just cries out for automation.And automation is indeed hard, I completely agree again, as it would require writing a plugin system to do the right thing for each styling language supporting NamedLayer
(btw, CSS would not be one of them, at least not today).I’d be quite a bit more comfortable with the vendor params/empty layer approach in GetMap/GetFeatureInfo instead, as in that case
it would be a true-er parallel to the current SLD/SLD_BODY functionality, less “front and center”, more geared towards the advanced user
(although I’m sure we’ll get complaints about the lack of automatic updates of the styles on layer name changes even in this case,
but hopefully a smaller amount).In its current state, I would advise against the proposed approach, but if everybody else unanimously supports it, I’ll vote -0 to
avoid blocking the proposal.Cheers
AndreaOn Fri, Jul 14, 2017 at 9:04 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Summary:
Suggestion - use an empty layer entry in the layers list of the Layer Group, instead of adding the StyleGroupInfo class:
This seems a little hacky, but I don’t see any real problems with it.
Overall results in a smaller API change, so I am happy with this suggestion.Style Validation - Deleting or renaming layers referred to by StyleGroups:
Overall, I would prefer going with the current prevalent approach of leaving most of the onus of keeping the style valid upon the user. I think adding warnings to the UI where deleting or renaming a layer would make a StyleGroup invalid would definitely be valuable.
I agree preventing deletion of a layer referred to by a style group is unacceptable.
I think modifying a style group programatically when layers are renamed is a bad idea, for a number of reasons:
- There are several different styling languages supported by GeoServer, and some of them support NamedLayer. Most of these are not 1:1 compatible with SLD, which is to say writing from SLD to one of these layers is not always possible, or has the potential to cause destructive changes (if only to comments or structure, not behaviour).
- In general, programatically modifying a user’s style seems like a very bad idea, especially since even “SLD file” → “parsed SLD in GeoServer” → “SLD file” chain does not always result in something exactly the same.
My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer.Handling Virtual Services / Security:
Current behaviour for external SLDs is to fail with a “layer not found”. For a Style Group, I would prefer to implement a softer failure of just dropping the layer from the output, to match with the current treatment of layer groups. It may be valuable to extend this implementation to the treatment of external styles as well (Perhaps as a configurable option if this is necessary to remain compliant with the SLD / WMS spec).
Alternative approach - just use the WMS SLD parameter (extend it to support referencing local styles by name) instead of modifying layer group behaviour:
I would rather extend the layer group functionality, as it allows combining Style Groups with regular layers. However, I think extending the SLD parameter would still be a workable alternative.
Torben
On Fri, Jul 14, 2017 at 11:15 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Ah, forgot one more concern, which is related to workspace specific services.
I setup an example group on a demo server for you to look at, it’s a globa one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace specific services, and the
catalog will automatically shave off the layers that are not part of the current workspace
transparently, please see and compare:What happens when style groups enter the picture? Is the catalog going to alter the style
on the fly to remove references to layers that are not visible in the current workspace?Good question. My first response would be what do we do currently if you use an external SLD via the WMS SLD parameter while making a WMS request from a workspace specific service.
After trying it out, it handles it as if the layer doesn’t exist, and fails with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to respect security and virtual service restrictions. It may be better to change this behaviour to simply exclude layers that can’t be found (and log a warning), although this might be something that can be controlled by an additional parameter, so that we can still treat missing layers in a more strict fashion.
For the StyleGroup, I would expect it would trim out any layers when parsing the SLD. The current code for handling the SLD parameter (In GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each NamedLayer within the SLD into separate MapLayer and Style objects, so I expect it would be possible to trim out any layers that would be hidden to to workspace-specific services or security rules at this point.
And the same should happen with security, if a layer is not visible and referenced by a group today, the
layer is removed transparently from the group as it gets out of the catalog, I assume the same would
have to happen for nested style groups, right?I’m also wondering, is nesting style groups in standard groups a requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?If it’s the latter, wouldn’t it be simpler to extend the current GetMap protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal style known by GeoServer?
Hell, wouldn’t it be even simpler to allow SLD to take either a URL, or a style name, and be done with it [1]?It mostly the latter, although it would still be useful to be able to refer to regular layers and StyleGroups in the same WMS, such as if you had a style group that defines a basemap, and wanted to show some additional layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and you can use a GeoServer-internal style this way via the styles endpoint (localhost:8080/geoserver/styles/stylename.sld). Adding the ability to refer to an internal style by name / relative URL would be a simple improvement, and a potential alternative.
If you need to mix it with other layers, how about allowing an empty layer name in the layer list,
and if that happens then take the style name a group?You mentioned this in your earlier mail, and I think that would be a perfectly workable alternative to an actual StyleGroup object.
Just thinking out loud here!
Cheers
Andrea[1] Well, almost be done, even using a style like this would incur in security and more in general
catalog filtering related issues.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel–
Regards,
Andrea Aime
== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)_______________________________________________ Geoserver-devel mailing list [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@anonymised.comsourceforge.net) [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
--
Kevin Michael Smith
[<smithkm@anonymised.com>](mailto:smithkm@anonymised.com)
Giving the user a choice about whether or not to rewrite the style addresses most of the concerns I had about that approach. Given this, I would be okay with an implementation that rewrites the style by default, with the option to leave it unchanged.
Allow invalidation of style, rewrite style (Modify data structure write out if the language supports it), replace style (keep the old one, write a new one and update all references to use the new one), cascade delete (delete anything that would become invalid), cascade disable
This seems like maybe a few too many options, but some subset of these would be good.
In the UI, a warning could show up and allow the user to pick a resolution strategy maybe with a documentation link to explain their strengths and weaknesses.
In REST we would have a parameter on the operation specifying the strategy. I think the safe default would be to deny the operation if it would invalidate the style.
Sounds good, this closely matches the current behaviour of validate by default, but allow a raw if a certain parameter is passed.
I also like the suggestion to preserve the old style, as that helps address the case of large complex styles with complex internal formatting / indentation / comments. That does open a couple cans of worms with respect to cluttering the style directory, and renaming the preserved styles, but both these issues seem easy enough to solve.
Torben
On Fri, Jul 14, 2017 at 3:16 PM, Kevin Smith <smithkm@anonymised.com> wrote:
Maybe we could allow a choice of multiple strategies for handling operations that invalidate styles:
Allow invalidation of style, rewrite style (Modify data structure write out if the language supports it), replace style (keep the old one, write a new one and update all references to use the new one), cascade delete (delete anything that would become invalid), cascade disable (disable anything that would become invalid)
In the UI, a warning could show up and allow the user to pick a resolution strategy maybe with a documentation link to explain their strengths and weaknesses.
In REST we would have a parameter on the operation specifying the strategy. I think the safe default would be to deny the operation if it would invalidate the style.
For rewrite/replace adding a comment explaining what happened to the new style could be helpful. This would probably require an extension to the style language API though.
On 7/14/17 12:59 PM, Andrea Aime wrote:
Hi Torben,
we sort of agree on a few points, besides one major disagreement, which is the handling of
configuration consistency.This statement is provably false: “My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer”
Any attempt to change a layer name, a store workspace, or remove it, is today followed by a warning and an automatic re-alignment of the configuration on save.
Any security application is completely transparent to the group configuration too.Yes, it’s possible to make a style not work with a layer, just remove an attribute that the style is using, or fumble and associate
the wrong style to a layer, but this is not a 0 or 1 situation, the current system does a significant effort trying to keep things
consistent (and could do better, I agree), this new one would do nothing at all instead, in other words, it’s anything but transparent and/or automatic.Now, you say it’s an extension of the current SLD/SLD_BODY behavior, and there, I completely agree.
However, SLD/SLD_BODY is non discoverable by the novice/normal user, and not so very well documented… it smells of advanced (here be dragons) a mile away.
Putting style groups in the UI makes them be “front and center”, discoverable and usable by everybody, more rope for the common users to hang themselves,
and annoying for the advanced user that (god forbid) might have to change a layer name (ever made a typo? ever asked by a manager for a reorganization?)
and then has to hunt it down in all styles referring to it. It just cries out for automation.And automation is indeed hard, I completely agree again, as it would require writing a plugin system to do the right thing for each styling language supporting NamedLayer
(btw, CSS would not be one of them, at least not today).I’d be quite a bit more comfortable with the vendor params/empty layer approach in GetMap/GetFeatureInfo instead, as in that case
it would be a true-er parallel to the current SLD/SLD_BODY functionality, less “front and center”, more geared towards the advanced user
(although I’m sure we’ll get complaints about the lack of automatic updates of the styles on layer name changes even in this case,
but hopefully a smaller amount).In its current state, I would advise against the proposed approach, but if everybody else unanimously supports it, I’ll vote -0 to
avoid blocking the proposal.Cheers
Andrea------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)_______________________________________________ Geoserver-devel mailing list [Geoserver-devel@anonymised.com.366...sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net) [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)-- Kevin Michael Smith [<smithkm@anonymised.com>](mailto:smithkm@anonymised.com)
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Fri, Jul 14, 2017 at 9:04 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Summary:
Suggestion - use an empty layer entry in the layers list of the Layer Group, instead of adding the StyleGroupInfo class:
This seems a little hacky, but I don’t see any real problems with it.
Overall results in a smaller API change, so I am happy with this suggestion.Style Validation - Deleting or renaming layers referred to by StyleGroups:
Overall, I would prefer going with the current prevalent approach of leaving most of the onus of keeping the style valid upon the user. I think adding warnings to the UI where deleting or renaming a layer would make a StyleGroup invalid would definitely be valuable.
I agree preventing deletion of a layer referred to by a style group is unacceptable.
I think modifying a style group programatically when layers are renamed is a bad idea, for a number of reasons:
- There are several different styling languages supported by GeoServer, and some of them support NamedLayer. Most of these are not 1:1 compatible with SLD, which is to say writing from SLD to one of these layers is not always possible, or has the potential to cause destructive changes (if only to comments or structure, not behaviour).
- In general, programatically modifying a user’s style seems like a very bad idea, especially since even “SLD file” → “parsed SLD in GeoServer” → “SLD file” chain does not always result in something exactly the same.
My preference would be to allow invalid styles caused by catalog changes. This is fairly similar to the current treatment of styles in GeoServer.Handling Virtual Services / Security:
Current behaviour for external SLDs is to fail with a “layer not found”. For a Style Group, I would prefer to implement a softer failure of just dropping the layer from the output, to match with the current treatment of layer groups. It may be valuable to extend this implementation to the treatment of external styles as well (Perhaps as a configurable option if this is necessary to remain compliant with the SLD / WMS spec).
Alternative approach - just use the WMS SLD parameter (extend it to support referencing local styles by name) instead of modifying layer group behaviour:
I would rather extend the layer group functionality, as it allows combining Style Groups with regular layers. However, I think extending the SLD parameter would still be a workable alternative.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Regards,
Andrea Aime
== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
On Fri, Jul 14, 2017 at 11:15 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Good question. My first response would be what do we do currently if you use an external SLD via the WMS SLD parameter while making a WMS request from a workspace specific service.
After trying it out, it handles it as if the layer doesn’t exist, and fails with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to respect security and virtual service restrictions. It may be better to change this behaviour to simply exclude layers that can’t be found (and log a warning), although this might be something that can be controlled by an additional parameter, so that we can still treat missing layers in a more strict fashion.
For the StyleGroup, I would expect it would trim out any layers when parsing the SLD. The current code for handling the SLD parameter (In GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each NamedLayer within the SLD into separate MapLayer and Style objects, so I expect it would be possible to trim out any layers that would be hidden to to workspace-specific services or security rules at this point.
It mostly the latter, although it would still be useful to be able to refer to regular layers and StyleGroups in the same WMS, such as if you had a style group that defines a basemap, and wanted to show some additional layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and you can use a GeoServer-internal style this way via the styles endpoint (localhost:8080/geoserver/styles/stylename.sld). Adding the ability to refer to an internal style by name / relative URL would be a simple improvement, and a potential alternative.
You mentioned this in your earlier mail, and I think that would be a perfectly workable alternative to an actual StyleGroup object.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ah, forgot one more concern, which is related to workspace specific services.
I setup an example group on a demo server for you to look at, it’s a globa one called test,
referring two layers in different workspaces:
Nowadays the usage of test is allowed from both global and workspace specific services, and the
catalog will automatically shave off the layers that are not part of the current workspace
transparently, please see and compare:
What happens when style groups enter the picture? Is the catalog going to alter the style
on the fly to remove references to layers that are not visible in the current workspace?
And the same should happen with security, if a layer is not visible and referenced by a group today, the
layer is removed transparently from the group as it gets out of the catalog, I assume the same would
have to happen for nested style groups, right?
I’m also wondering, is nesting style groups in standard groups a requirement for you, or just a way to
make style groups viewable without making them catalog first class objects?
If it’s the latter, wouldn’t it be simpler to extend the current GetMap protocol with a new parameter that
would mimick SLD and SLD_BODY, but so that you can refer to an internal style known by GeoServer?
Hell, wouldn’t it be even simpler to allow SLD to take either a URL, or a style name, and be done with it [1]?
If you need to mix it with other layers, how about allowing an empty layer name in the layer list,
and if that happens then take the style name a group?
Just thinking out loud here!
Cheers
Andrea
[1] Well, almost be done, even using a style like this would incur in security and more in general
catalog filtering related issues.