[Geoserver-devel] Nested layer groups proposal

GeoServer GeoServer Developer
1

Hi,

I'd like to propose a change to layer groups: I'd like to add nested
layer groups support, allowing a layer group to be a child of another
layer group.

A layer group could contain layers and layer groups in the same children list.
To have an homogeneous list we could extract a common interface from
LayerInfo and LayerGroupInfo:
they both extend the CatalogInfo interface, but they share other
properties so we could create a new super interface.

These are the properties that LayerInfo and LayerGroupInfo share and
that can be included in the new super interface:
- name
- prefixedName
- workspace
- title
- abstract
- metadata
- authorityURLs
- identifiers

LayerGroupInfo method getLayers() will return a list of layers and layer groups.
Method getStyles() will contain null entries for layer groups.

The work will be based on changes already made for GSIP 84 where
LayerGroupInfo has
two new methods renderingLayers() and renderingStyles().
These methods are used by the WMS service to retrieve layers and styles.

renderingLayers() will continue to return a list of LayerInfo, so the
LayerGroup will expand
nested LayerGroups to expose only a list of Layers.

renderingStyles() will continue to return a list of StyleInfo with a
1-1 correspondence to renderingLayers(),
so the LayerGroup will expand nested LayerGroups styles.

Nested layer groups could replace usage of layers WMS Path property.

Opinions? :slight_smile:

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Davide Savazzi
@svzdvd
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

I like it. Have you thought of a name for the common super class? I have thought about this before but always came up short. LayerableInfo? WWWInfo, etc… Could never find anything that fit.

But with that in mind it might be a cleaner chance to rename LayerGroupInfo.getLayers() to something else like LayerGroupInfo.getLayerables(), and possibly just deprecate LayerGroupInfo.getLayers(), and have it implemented as a derived property that either strips out the layer groups, or throws an exception when layer groups are present.

On Thu, Jan 3, 2013 at 12:53 AM, Davide <davide.savazzi@anonymised.com> wrote:

Hi,

I’d like to propose a change to layer groups: I’d like to add nested
layer groups support, allowing a layer group to be a child of another
layer group.

A layer group could contain layers and layer groups in the same children list.
To have an homogeneous list we could extract a common interface from
LayerInfo and LayerGroupInfo:
they both extend the CatalogInfo interface, but they share other
properties so we could create a new super interface.

These are the properties that LayerInfo and LayerGroupInfo share and
that can be included in the new super interface:

  • name
  • prefixedName
  • workspace
  • title
  • abstract
  • metadata
  • authorityURLs
  • identifiers

LayerGroupInfo method getLayers() will return a list of layers and layer groups.
Method getStyles() will contain null entries for layer groups.

The work will be based on changes already made for GSIP 84 where
LayerGroupInfo has
two new methods renderingLayers() and renderingStyles().
These methods are used by the WMS service to retrieve layers and styles.

renderingLayers() will continue to return a list of LayerInfo, so the
LayerGroup will expand
nested LayerGroups to expose only a list of Layers.

renderingStyles() will continue to return a list of StyleInfo with a
1-1 correspondence to renderingLayers(),
so the LayerGroup will expand nested LayerGroups styles.

Nested layer groups could replace usage of layers WMS Path property.

Opinions? :slight_smile:

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Davide Savazzi
@svzdvd
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only – learn more at:
http://p.sf.net/sfu/learnmore_122712

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

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

3

On Thu, Jan 3, 2013 at 8:53 AM, Davide <davide.savazzi@anonymised.com> wrote:

Nested layer groups could replace usage of layers WMS Path property.

Could is key here. If we do it, Chris already provided feedback that we should also
consider a migration path for those that have wms path setup, like recognizing
the path structure and build new groups out of it.

Or we could live things as they are, which would result in some redundant functionality,
though this might not be the end of the world: I have doubt wms path is very much
used, but it’s my perception.

And/or… maybe someone is interested in teaming up and working on the wms path
to layer group migration?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

On Fri, Jan 4, 2013 at 9:09 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I like it. Have you thought of a name for the common super class? I have thought about this before but always came up short. LayerableInfo? WWWInfo, etc… Could never find anything that fit.

But with that in mind it might be a cleaner chance to rename LayerGroupInfo.getLayers() to something else like LayerGroupInfo.getLayerables(), and possibly just deprecate LayerGroupInfo.getLayers(), and have it implemented as a derived property that either strips out the layer groups, or throws an exception when layer groups are present.

Hum… with the other proposal I’m wondering if layer group could not be seens as a sort of “layer on steroids”, especially
in the wms mode.

That is… how about the base class is just called AbstractLayerInfo, with LayerInfo and LayerGroupInfo as subinterfaces?
Another possibility: PublishedInfo.
It’s not that Layerable would not work at all, but LayerableInfo sounds like something that can be transformed into a layer,
as opposed to being some sort of layer in its own merit.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

5

On Sat, Jan 5, 2013 at 10:15 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jan 3, 2013 at 8:53 AM, Davide <davide.savazzi@anonymised.com> wrote:

Nested layer groups could replace usage of layers WMS Path property.

Could is key here. If we do it, Chris already provided feedback that we should also
consider a migration path for those that have wms path setup, like recognizing
the path structure and build new groups out of it.

Or we could live things as they are, which would result in some redundant functionality,
though this might not be the end of the world: I have doubt wms path is very much
used, but it’s my perception.

And/or… maybe someone is interested in teaming up and working on the wms path
to layer group migration?

Yeah, my impression is that it is probably not worth the trouble. Rather than try to get fancy I would rather see the removal of wms path documented in the user guide, with clear options of how to reproduce the same functionality.

$0.02

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122912

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

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

6

On Sat, Jan 5, 2013 at 10:19 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jan 4, 2013 at 9:09 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I like it. Have you thought of a name for the common super class? I have thought about this before but always came up short. LayerableInfo? WWWInfo, etc… Could never find anything that fit.

But with that in mind it might be a cleaner chance to rename LayerGroupInfo.getLayers() to something else like LayerGroupInfo.getLayerables(), and possibly just deprecate LayerGroupInfo.getLayers(), and have it implemented as a derived property that either strips out the layer groups, or throws an exception when layer groups are present.

Hum… with the other proposal I’m wondering if layer group could not be seens as a sort of “layer on steroids”, especially
in the wms mode.

That is… how about the base class is just called AbstractLayerInfo, with LayerInfo and LayerGroupInfo as subinterfaces?
Another possibility: PublishedInfo.
It’s not that Layerable would not work at all, but LayerableInfo sounds like something that can be transformed into a layer,
as opposed to being some sort of layer in its own merit.

Yeah, I didn’t like LayerableInfo. I thought about PublishedInfo as well since more or less what they share is all the “publishing” metadata . I do kind of like it since it would be a separation of those entities (like layer and layer group) which represent the published aspect from those that are sort of internal entities (resource, store, etc…)I guess the question is how likely is it that something else might want to extend this same interface, ie share this same publishing metadata.

Anyways, no strong opinion.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

7

On Mon, Jan 7, 2013 at 5:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, I didn’t like LayerableInfo. I thought about PublishedInfo as well since more or less what they share is all the “publishing” metadata . I do kind of like it since it would be a separation of those entities (like layer and layer group) which represent the published aspect from those that are sort of internal entities (resource, store, etc…)I guess the question is how likely is it that something else might want to extend this same interface, ie share this same publishing metadata.

Likely, in the short term… uh, I guess not very much?

What else could be publisheable as a layer of sorts? Maybe map decorations of some sort?

Another thing that could sooner or later come in is the idea of having a WPS process be a source of data
for a layer, but I guess in that cause we’d make the WPS process a resource too, so that it can be used
from WFS and WCS too

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

8

On Mon, Jan 7, 2013 at 5:19 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Yeah, I didn't like LayerableInfo. I thought about PublishedInfo as well

I've created a proposal:
http://geoserver.org/display/GEOS/GSIP+85+-+Nested+layer+groups

I've used the name PublishedInfo.
If we were starting from scratch I would use LayerInfo for the super
interface, SingleLayerInfo and LayerGroupInfo, but it would require
too much refactoring now...

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Davide Savazzi
@svzdvd
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

9

On Mon, Jan 7, 2013 at 11:13 AM, Justin Deoliveira <jdeolive@anonymised.com>wrote:

On Sat, Jan 5, 2013 at 10:15 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:

On Thu, Jan 3, 2013 at 8:53 AM, Davide <davide.savazzi@anonymised.com> wrote:

Nested layer groups could replace usage of layers WMS Path property.

Could is key here. If we do it, Chris already provided feedback that we
should also
consider a migration path for those that have wms path setup, like
recognizing
the path structure and build new groups out of it.

Or we could live things as they are, which would result in some redundant
functionality,
though this might not be the end of the world: I have doubt wms path is
very much
used, but it's my perception.

And/or... maybe someone is interested in teaming up and working on the
wms path
to layer group migration?

Yeah, my impression is that it is probably not worth the trouble. Rather
than try to get fancy I would rather see the removal of wms path documented
in the user guide, with clear options of how to reproduce the same
functionality.

+1 on it not being worth the trouble. I forget what I wrote, but I think a
fine 'migration path' is just what Justin says - user documentation on how
to reproduce the functionality and maybe a blog post notifying users. I'm
not convinced that many people use it. And indeed if there's docs we just
have to point them at it when they ask on the list.

C

$0.02

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912

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

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

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10

Cool, +1 on the proposal with the idea of documenting how to get the same layer tree that was once supported by wmspath using layer groups instead.
Which, btw, could be just done by documenting well how to build layer trees of various shapes using the nesting construct.

Cheers
Andrea

···

+1 on it not being worth the trouble. I forget what I wrote, but I think a fine ‘migration path’ is just what Justin says - user documentation on how to reproduce the functionality and maybe a blog post notifying users. I’m not convinced that many people use it. And indeed if there’s docs we just have to point them at it when they ask on the list.