Do we have any similar UI examples? Text field would be quick, a table like the layer Metadata Links would be kinder (but harder to implement). -- Jody Garnett
On 12 August 2015 at 15:56, Torben Barsballe <[email protected]> wrote: > How do we plan to expose the vendorOptions() for LayerGroups? Given that > they will affect how layers are displayed, they should be editable from the > GeoServer UI, but an arbitrary Map of values does not really lend itself to > a user friendly display. > > Exposing these values via the REST API should also be done, but seems much > simpler. > > Torben > > On Fri, Jun 12, 2015 at 1:50 PM, Kevin Smith <[email protected]> > wrote: > >> I considered putting the scale range on the layer rather than the layer >> group, but it seems less useful. A layer may be used in multiple layer >> groups with the same style differing only in the scale range it's used at. >> For one layer in isolation, saving on scales across the rules in a style is >> fairly minor compared to doing that across multiple layers in a group, in a >> group specific way. >> >> The style change would be filtering at the point where the style is being >> loaded for rendering, not a change to the stored style. Conceptually the >> scale range on the layer and scale ranges used in styles would be separate >> things. Implementing the former by tweaking the latter would be an >> implementation detail. It's just that it looks to me like the easiest way >> to manage this. An alternative would be to calculate the scale and then >> remove any sublayers that are out of scale. As far as the user and the >> catalog are concerned, whether it's layers being removed, or styles being >> filtered should be irrelevant. >> >> On 12 June 2015 at 12:28, Jody Garnett <[email protected]> wrote: >> >>> An alternative to changing the layer group info is to change the layer >>> to include min/max scale information. Ideally do to DRY (do not repeat >>> yourself) I would like to see the min/max scale calculated from the style >>> ... and refreshed each time the style is changed. >>> >>> I guess it is tricky as the scale based on which style the user has >>> requested; or in this case the layer group has been configured with. >>> >>> In the WMS module during a GetMap request (rather than adjust the styles >>> using a style visitor) you could discard layers that do not match the >>> current scale from further processing >>> >>> >>> -- >>> Jody Garnett >>> >>> On 12 June 2015 at 11:43, Kevin Smith <[email protected]> wrote: >>> >>>> I'm looking at ways we could make it easier to manage scale based >>>> visibility of layers in a layer group. >>>> >>>> At the moment I'm thinking the best way to do it would be to add a list >>>> of scale ranges to layer groups in parallel to the existing lists of >>>> publishables and styles with the same pair of accessors (one for children, >>>> one for a flattened list of descendants) >>>> >>>> Then in the WMS module when the StyleInfo objects are retrieved and >>>> used to get the Style objects (Happens in two places, one for GetMap, one >>>> for GetLegend), a StyleVisitor could be sent over the styles to adjust the >>>> scale rules so they are suitably restricted. >>>> >>>> This would simplify the process of building complex layer groups as it >>>> would place all the scale dependant visibility information in one place >>>> instead of having to coordinate it across multiple styles. >>>> >>>> This would either require a new kind of layer group that the WMS module >>>> would have to detect, or a change to the LayerGroupInfo interface to add >>>> new methods. I expect the latter would call for a GSIP. >>>> >>>> Does anyone have any thoughts? >>>> >>>> -- >>>> >>>> Kevin Smith >>>> >>>> Software Engineer | Boundless <http://boundlessgeo.com/> >>>> >>>> [email protected] >>>> >>>> +1-778-785-7459 >>>> >>>> @boundlessgeo <http://twitter.com/boundlessgeo/> >>>> >>>> >>>> <http://twitter.com/boundlessgeo/> >>>> >>>> [image: http://boundlessgeo.com/] >>>> <http://boundlessgeo.com/> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >>>> >>> >> >> >> -- >> >> Kevin Smith >> >> Software Engineer | Boundless <http://boundlessgeo.com/> >> >> [email protected] >> >> +1-778-785-7459 >> >> @boundlessgeo <http://twitter.com/boundlessgeo/> >> >> >> <http://twitter.com/boundlessgeo/> >> >> [image: http://boundlessgeo.com/] >> <http://boundlessgeo.com/> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> >> >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
