[Geoserver-devel] styles per workspace

Justin_Deoliveira · January 5, 2012, 12:07am

Hi all,

Following after the recent work to make workspaces in geoserver be able to live truly autonomously, i am back to revisit a topic that was brought up before, and that is storing styles on a workspace by workspace basis. Before I get to far with an implementation I wanted to run some ideas by folks first.

First thing is style visibility. If styles can be stored globally and stored under a workspace, what styles should be visible from where? It would make sense that “global” styles be visible everywhere, whether you are going through a virtual service / workspace or not. But what about non global styles? Should they be constrained only to that workspace / virtual service? Or should you be able to access them globally as well, perhaps with some prefix?

I am thinking the former. To illustrate, here are some examples:

Consider some global styles:

point
line

And some local ones:

topp:

foo

nurc:

bar

The following requests would all be valid:

geoserver/wms?..&styles=point
geoserver/topp/wms?..&styles=line
geoserver/topp/wms?..&styles=foo
geoserver/nurc/wms?..&styles=bar

The following requests would not be valid:

geoserver/wms?..&styles=foo
geoserver/wms?..&styles=bar
geoserver/topp/wms?..&styles=bar
geoserver/nurc/wms?..&styles=foo

Thoughts?

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

One potential solution is to add an additional property to StyleInfo, something like “resourceFilenames”.

StyleInfo {
List getResourceFilenames():
}

Which would store any supplementary files that are needed by the SLD. When the user uploads a new file via the ui, we examine the file and look for any external graphics that point to relative file uris, and detect the additional resources. This might not be bullet proof so I was also thinking of an additional form field (a list chooser with add/remove) that would allow the admin to explicitly specify the supplementary fies.

Thoughts?

Thanks folks. Feedback much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Chris_Holmes1 · January 5, 2012, 2:56pm

I think constrained to the workspace / virtual service makes a lot more sense. Indeed to me part of the workspaces is a place you’d apply security settings. With security in mind it seems more logical in general to have the scope be constrained. May not be hard to implement those security contraints so they don’t appear in global if you set the workspace private, but having the scope constrained will just have it make more sense to a user imho.

As for resource file names, I think in general it does make sense to track things more, and that we can probably do some nicer stuff with exposing them more easily to the web if we do track them.

my $.02

On Wed, Jan 4, 2012 at 7:07 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Following after the recent work to make workspaces in geoserver be able to live truly autonomously, i am back to revisit a topic that was brought up before, and that is storing styles on a workspace by workspace basis. Before I get to far with an implementation I wanted to run some ideas by folks first.

First thing is style visibility. If styles can be stored globally and stored under a workspace, what styles should be visible from where? It would make sense that “global” styles be visible everywhere, whether you are going through a virtual service / workspace or not. But what about non global styles? Should they be constrained only to that workspace / virtual service? Or should you be able to access them globally as well, perhaps with some prefix?

I am thinking the former. To illustrate, here are some examples:

Consider some global styles:

point

line

And some local ones:

topp:

foo

nurc:

bar

The following requests would all be valid:

geoserver/wms?..&styles=point
geoserver/topp/wms?..&styles=line
geoserver/topp/wms?..&styles=foo
geoserver/nurc/wms?..&styles=bar

The following requests would not be valid:

geoserver/wms?..&styles=foo
geoserver/wms?..&styles=bar
geoserver/topp/wms?..&styles=bar
geoserver/nurc/wms?..&styles=foo

Thoughts?

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

One potential solution is to add an additional property to StyleInfo, something like “resourceFilenames”.

StyleInfo {
List getResourceFilenames():
}

Which would store any supplementary files that are needed by the SLD. When the user uploads a new file via the ui, we examine the file and look for any external graphics that point to relative file uris, and detect the additional resources. This might not be bullet proof so I was also thinking of an additional form field (a list chooser with add/remove) that would allow the admin to explicitly specify the supplementary fies.

Thoughts?

Thanks folks. Feedback much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don’t need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

David_Winslow · January 5, 2012, 3:21pm

With regard to the resource file name, maybe it would be better to provide some tools for verifying the resources for a style (ie, don’t persist the file list, don’t automatically move image files around, just add a ‘Validate Resource References’ button on the style editor page.)

–
David Winslow
OpenGeo - http://opengeo.org/

On Thu, Jan 5, 2012 at 9:56 AM, Chris Holmes <cholmes@anonymised.com> wrote:

I think constrained to the workspace / virtual service makes a lot more sense. Indeed to me part of the workspaces is a place you’d apply security settings. With security in mind it seems more logical in general to have the scope be constrained. May not be hard to implement those security contraints so they don’t appear in global if you set the workspace private, but having the scope constrained will just have it make more sense to a user imho.

As for resource file names, I think in general it does make sense to track things more, and that we can probably do some nicer stuff with exposing them more easily to the web if we do track them.

my $.02

On Wed, Jan 4, 2012 at 7:07 PM, Justin Deoliveira <jdeolive@anonymised.com…> wrote:

Hi all,

Following after the recent work to make workspaces in geoserver be able to live truly autonomously, i am back to revisit a topic that was brought up before, and that is storing styles on a workspace by workspace basis. Before I get to far with an implementation I wanted to run some ideas by folks first.

First thing is style visibility. If styles can be stored globally and stored under a workspace, what styles should be visible from where? It would make sense that “global” styles be visible everywhere, whether you are going through a virtual service / workspace or not. But what about non global styles? Should they be constrained only to that workspace / virtual service? Or should you be able to access them globally as well, perhaps with some prefix?

I am thinking the former. To illustrate, here are some examples:

Consider some global styles:

point

line

And some local ones:

topp:

foo

nurc:

bar

The following requests would all be valid:

geoserver/wms?..&styles=point
geoserver/topp/wms?..&styles=line
geoserver/topp/wms?..&styles=foo
geoserver/nurc/wms?..&styles=bar

The following requests would not be valid:

geoserver/wms?..&styles=foo
geoserver/wms?..&styles=bar
geoserver/topp/wms?..&styles=bar
geoserver/nurc/wms?..&styles=foo

Thoughts?

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

One potential solution is to add an additional property to StyleInfo, something like “resourceFilenames”.

StyleInfo {
List getResourceFilenames():
}

Which would store any supplementary files that are needed by the SLD. When the user uploads a new file via the ui, we examine the file and look for any external graphics that point to relative file uris, and detect the additional resources. This might not be bullet proof so I was also thinking of an additional form field (a list chooser with add/remove) that would allow the admin to explicitly specify the supplementary fies.

Thoughts?

Thanks folks. Feedback much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don’t need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don’t need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Andrea_Aime4 · January 5, 2012, 5:53pm

On Thu, Jan 5, 2012 at 1:07 AM, Justin Deoliveira <jdeolive@anonymised.com1501…> wrote:

Hi all,

Following after the recent work to make workspaces in geoserver be able to live truly autonomously, i am back to revisit a topic that was brought up before, and that is storing styles on a workspace by workspace basis. Before I get to far with an implementation I wanted to run some ideas by folks first.

First thing is style visibility. If styles can be stored globally and stored under a workspace, what styles should be visible from where? It would make sense that “global” styles be visible everywhere, whether you are going through a virtual service / workspace or not. But what about non global styles? Should they be constrained only to that workspace / virtual service? Or should you be able to access them globally as well, perhaps with some prefix?

I am thinking the former.

The former seems reasonable.

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

Resource wise things work like this: if a resource path is relative the SLDParser will assume it’s relative to the
location of the .sld file and will try to build that path, which will in turn replace the original path in the
in memory reprentation of the style.
See SLDParser line 1662 (be seated and prepared, that code is ugly).

If we leave it like this it may work well regardless of where you place the sld files.
Btw, I don’t know much about the SLD 1.1 parser but I doubt it has the same logic?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Justin_Deoliveira · January 5, 2012, 6:03pm

On Thu, Jan 5, 2012 at 5:53 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jan 5, 2012 at 1:07 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Following after the recent work to make workspaces in geoserver be able to live truly autonomously, i am back to revisit a topic that was brought up before, and that is storing styles on a workspace by workspace basis. Before I get to far with an implementation I wanted to run some ideas by folks first.

First thing is style visibility. If styles can be stored globally and stored under a workspace, what styles should be visible from where? It would make sense that “global” styles be visible everywhere, whether you are going through a virtual service / workspace or not. But what about non global styles? Should they be constrained only to that workspace / virtual service? Or should you be able to access them globally as well, perhaps with some prefix?

I am thinking the former.

The former seems reasonable.

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

Resource wise things work like this: if a resource path is relative the SLDParser will assume it’s relative to the
location of the .sld file and will try to build that path, which will in turn replace the original path in the
in memory reprentation of the style.
See SLDParser line 1662 (be seated and prepared, that code is ugly).

Right, makes sense though. The issue is moving the style to a different workspace, the external graphics will be left behind as things sit today.

If we leave it like this it may work well regardless of where you place the sld files.
Btw, I don’t know much about the SLD 1.1 parser but I doubt it has the same logic?

Yeah, don’t think so either, i imagine it is just left as is. Will see about porting that logic over.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime4 · January 6, 2012, 10:23am

On Thu, Jan 5, 2012 at 7:03 PM, Justin Deoliveira <jdeolive@anonymised.com1501…> wrote:

Resource wise things work like this: if a resource path is relative the SLDParser will assume it’s relative to the

location of the .sld file and will try to build that path, which will in turn replace the original path in the
in memory reprentation of the style.
See SLDParser line 1662 (be seated and prepared, that code is ugly).

Right, makes sense though. The issue is moving the style to a different workspace, the external graphics will be left behind as things sit today.

I agree, but I’m not sure that making the resources into explicit configuration items will make things better.

The user does not have to manually declare them, so we’d have to extract their location automatically anyways
each time the SLD (or css) is saved.

Given that, isn’t it better to do the job only when the files are moved, if they are at all?
We could have a flag that disables the automatic path transformation during parsing, we walk the style, get
the resource references, and locate the relative ones, either moving them around or updating the
references.

I would actually go for the latter, unless you first want to check all the styles around to see if any other
style also depends on the same resource (in such case you cannot move it, you have to copy it instead)

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Justin_Deoliveira · January 6, 2012, 3:04pm

On Fri, Jan 6, 2012 at 10:23 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jan 5, 2012 at 7:03 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Resource wise things work like this: if a resource path is relative the SLDParser will assume it’s relative to the

location of the .sld file and will try to build that path, which will in turn replace the original path in the
in memory reprentation of the style.
See SLDParser line 1662 (be seated and prepared, that code is ugly).

Right, makes sense though. The issue is moving the style to a different workspace, the external graphics will be left behind as things sit today.

I agree, but I’m not sure that making the resources into explicit configuration items will make things better.

The user does not have to manually declare them, so we’d have to extract their location automatically anyways
each time the SLD (or css) is saved.

Well the idea was to have it be specifiable by configuration as a last resort, in case for some reason the automatic lookup code fails. But I agree less than idea. And in that case the user could just go in and move or copy the file manual anyways.

Given that, isn’t it better to do the job only when the files are moved, if they are at all?
We could have a flag that disables the automatic path transformation during parsing, we walk the style, get
the resource references, and locate the relative ones, either moving them around or updating the
references.

I would actually go for the latter, unless you first want to check all the styles around to see if any other
style also depends on the same resource (in such case you cannot move it, you have to copy it instead)

Makes sense. I will play around with this approach.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

jive · January 7, 2012, 2:31am

The following requests would all be valid:

geoserver/wms?..&styles=point
geoserver/topp/wms?..&styles=line
geoserver/topp/wms?..&styles=foo
geoserver/nurc/wms?..&styles=bar

So this is the equivalent of "anything published as a global style is available everywhere. I assume a local workspace could “override” a setting so styles=“point” could be provided by a workspace.

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

I have run into this issue as well; mostly with “symbology sets” either captured as a TTF, director of PNG files or hopefully a property file of WKT if we can ever get that WKT mark factory approved. For uDig I was going to try and manage these directly; and use the geotools factory mechanism about them.

Andrea has already pointed out that the references are considered relative to the SLD file; which hopefully will simplify this issue for you.

Jody

Justin_Deoliveira · January 7, 2012, 4:12pm

On Sat, Jan 7, 2012 at 2:31 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The following requests would all be valid:

geoserver/wms?..&styles=point
geoserver/topp/wms?..&styles=line
geoserver/topp/wms?..&styles=foo
geoserver/nurc/wms?..&styles=bar

So this is the equivalent of "anything published as a global style is available everywhere. I assume a local workspace could “override” a setting so styles=“point” could be provided by a workspace.

Yeah, I think that makes sense to be able to override.

A second issue i ran into are styles that make use of other resources (like external graphics), that are stored along side the sld file. If we make styles be able to be part of a workspace, this means the style sld file can potentially move around, and for that to work we have to move not only the sld, but any other resources it requires. Currently our config model doesn’t specify any of these files.

I have run into this issue as well; mostly with “symbology sets” either captured as a TTF, director of PNG files or hopefully a property file of WKT if we can ever get that WKT mark factory approved. For uDig I was going to try and manage these directly; and use the geotools factory mechanism about them.

Andrea has already pointed out that the references are considered relative to the SLD file; which hopefully will simplify this issue for you.

Playing around at the moment trying to figure out the best way to solve this one.

Jody

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.