Re: [Geoserver-devel] styles per workspace
On Sat, Jan 7, 2012 at 2:31 AM, Jody Garnett 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. -- 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
Re: [Geoserver-devel] styles per workspace
> 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-- 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
Re: [Geoserver-devel] styles per workspace
On Fri, Jan 6, 2012 at 10:23 AM, Andrea Aime wrote: > On Thu, Jan 5, 2012 at 7:03 PM, Justin Deoliveira 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. -- 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
Re: [Geoserver-devel] styles per workspace
On Thu, Jan 5, 2012 at 7:03 PM, Justin Deoliveira 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 --- -- 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
Re: [Geoserver-devel] styles per workspace
On Thu, Jan 5, 2012 at 5:53 PM, Andrea Aime wrote: > On Thu, Jan 5, 2012 at 1:07 AM, Justin Deoliveira 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. -- 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
Re: [Geoserver-devel] styles per workspace
On Thu, Jan 5, 2012 at 1:07 AM, Justin Deoliveira 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 --- -- 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
Re: [Geoserver-devel] styles per workspace
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 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 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@lists.sourcef
Re: [Geoserver-devel] styles per workspace
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 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] styles per workspace
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
