GSIP 161

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GSIP 161

David Vick

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

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. 

I imagine we will discuss this GISP in today's geoserver meeting if you would like to join.

--
Jody Garnett

On 11 July 2017 at 09:55, David Vick <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

geowolf
In reply to this post by jody.garnett
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 <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 09:55, David Vick <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
[hidden email]
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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

jody.garnett
In reply to this post by Torben Barsballe
I think we can also calculate bounds via rest api?

--
Jody Garnett

On 11 July 2017 at 10:19, Torben Barsballe <[hidden email]> 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. 

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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe


On Tue, Jul 11, 2017 at 10:37 AM, Jody Garnett <[hidden email]> 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 <[hidden email]> 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
 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Chris Snider

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

http://docs.geoserver.org/stable/en/user/rest/api/featuretypes.html#rest-api-featuretypes-recalculate

 

 

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

Description: Description: Description: cid:image001.png@01CA1F1F.CBC93990

 

From: Torben Barsballe [mailto:[hidden email]]
Sent: Tuesday, July 11, 2017 1:56 PM
To: Jody Garnett <[hidden email]>; Andrea Aime <[hidden email]>
Cc: GeoServer <[hidden email]>
Subject: Re: [Geoserver-devel] GSIP 161

 

 

 

On Tue, Jul 11, 2017 at 10:37 AM, Jody Garnett <[hidden email]> 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 <[hidden email]> 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

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe


On Tue, Jul 11, 2017 at 1:17 PM, Chris Snider <[hidden email]> 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

http://docs.geoserver.org/stable/en/user/rest/api/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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Chris Snider

AH, missed that part

 

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

Description: Description: Description: cid:image001.png@01CA1F1F.CBC93990

 

From: Torben Barsballe [mailto:[hidden email]]
Sent: Tuesday, July 11, 2017 2:29 PM
To: Chris Snider <[hidden email]>
Cc: Jody Garnett <[hidden email]>; Andrea Aime <[hidden email]>; GeoServer <[hidden email]>
Subject: Re: [Geoserver-devel] GSIP 161

 

 

 

On Tue, Jul 11, 2017 at 1:17 PM, Chris Snider <[hidden email]> 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

http://docs.geoserver.org/stable/en/user/rest/api/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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

jody.garnett
In reply to this post by geowolf
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.

--
Jody Garnett

On 11 July 2017 at 10:25, Andrea Aime <[hidden email]> 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 <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 09:55, David Vick <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
[hidden email]
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

geowolf
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 <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 10:25, Andrea Aime <[hidden email]> 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 <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 09:55, David Vick <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
[hidden email]
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Ian Turton
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" <[hidden email]> 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

On Wed, Jul 12, 2017 at 6:15 PM, Jody Garnett <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 10:25, Andrea Aime <[hidden email]> 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 <[hidden email]> 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.

--
Jody Garnett

On 11 July 2017 at 09:55, David Vick <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
[hidden email]
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

geowolf
In reply to this post by David Vick
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<PublishedInfo> 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:
  • 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, and
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 <[hidden email]> wrote:

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
[hidden email]
mobile: <a href="tel:(636)%20698-3174" value="+16366983174" target="_blank">+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
[hidden email]
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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

geowolf
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:

Inline image 1


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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe
In reply to this post by geowolf
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 <[hidden email]> 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<PublishedInfo> 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, and
nowadays 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe
In reply to this post by geowolf
Part 2:

On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[hidden email]> 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:

Inline image 1


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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe
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 <[hidden email]> wrote:
Part 2:

On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[hidden email]> 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:

Inline image 1


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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

geowolf
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 <[hidden email]> 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 <[hidden email]> wrote:
Part 2:

On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[hidden email]> 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:

Inline image 1


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
[hidden email]
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
[hidden email]
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
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Kevin Smith-3
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


On Fri, Jul 14, 2017 at 9:04 PM, Torben Barsballe <[hidden email]> 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 <[hidden email]> wrote:
Part 2:

On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[hidden email]> 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:

Inline image 1


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
[hidden email]
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
[hidden email]
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


_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Kevin Michael Smith
[hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSIP 161

Torben Barsballe
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 <[hidden email]> 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


On Fri, Jul 14, 2017 at 9:04 PM, Torben Barsballe <[hidden email]> 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 <[hidden email]> wrote:
Part 2:

On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[hidden email]> 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:

Inline image 1


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
[hidden email]
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
[hidden email]
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313 fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272 mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+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


_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Kevin Michael Smith
[hidden email]

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
12