[Geoserver-devel] Nested layer group support

GeoServer GeoServer Developer
1

Hi,
I'm investigating the possibility of having nested layer groups, that
is, groups made of a mix of
other layer groups and layers.

The code to unpack the beast in the various KVP readers is of course
trivial, what is not trivial
is the configuration changes.

I was thinking that for simplicity the getLayers() method in
LayerGroupInfo would be preserved
and would do the recursive unpacking (the config must be extra careful
not to allow a loop
of references there) and that we could have a new getComponents() or
getItems() method
that really has the mix of layers and other groups.
However layer and groups share pretty much nothing, so the baby would
have to have a pretty
generic interface:
List<CatalogInfo> getItems()

Would this be ok?
Another thing is that the solution would be needed for the 2.1.x
series, so we'd need the
generic list of items to be stored among the metadata (fun eh?).
Given that anything in the catalog as a globally unique di the
metadata could contain
a flat list of UUIDs, and the code parsing it would try each id for
both layer and layer group.

Of course also the GUI would have to be updated. To keep things simple
we could have
a "add layer" and a "add group" button.
And finally the cascaded deletion code would have to care for groups in groups.

Have I considered everything? Hmm... RESTConfig changes are going to
be real fun too...

Opinions?

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

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

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

2

Good stuff.

It looks to me like LayerInfo and LayerGroupInfo could share some
stuff though. Both are means of defining a WMS layer, but
LayerGroupInfo is usually left aside when it comes to configuration
properties.
For instance, looks like they can share the following properties:
enabled, legend, path, advertised, queryable, and AuthorityURL and
Identifier once GEOS-4491 gets home. So I wouldn't mind a common
superinterface?

List<CatalogInfo> getItems()

Would this be ok?
Another thing is that the solution would be needed for the 2.1.x
series, so we'd need the
generic list of items to be stored among the metadata (fun eh?).

I'm facing a similar problem with the backwards compatibility patch
for GEOS-4491, as would need both LayerInfo and LayerGroupInfo to hold
more than one AuthorityURL, and even funnier cause AuthorityURL is not
a single string but a compound object.

Given that anything in the catalog as a globally unique di the
metadata could contain
a flat list of UUIDs, and the code parsing it would try each id for
both layer and layer group.

Of course also the GUI would have to be updated. To keep things simple
we could have
a "add layer" and a "add group" button.
And finally the cascaded deletion code would have to care for groups in groups.

Have I considered everything? Hmm... RESTConfig changes are going to
be real fun too...

Keep in touch cause I think I'll also have to update the GWC catalog
listener in order to resolve both contained layer and layergroups when
truncated based on a config change.

Opinions?

Sounds good to me. I'd like to hear your opinions about the common
superinterface for LayerInfo and LayerGroup though, perhaps only on
trunk?

Cheers,
Gabriel.

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

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

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

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

Some thoughts:

I would be for a common interface for Layer and LayerGroup… but not sure what a good name for it would be… I would also be for just using CatalogInfo if it suffices for this use case.

If LayerGroupInfo#layers is going to become a derived property that recursively returns all the leafs of the tree I would like to see it deprecated and renamed to “layers()” to keep with derived property naming conventions. I like either getItems() or getContents() for the property that returns only the direct children of the layer group.

You might be able to save yourself some headaches with the REST api by allowing one to POST to an existing layer group the name of a layer / or another layer group, rather than forcing the client to encode the contents in the metadata map.

Anyways… a fun problem, there will definitely be some tricky bits in there :slight_smile:

-Justin

The config

On Fri, Oct 7, 2011 at 11:04 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Good stuff.

It looks to me like LayerInfo and LayerGroupInfo could share some
stuff though. Both are means of defining a WMS layer, but
LayerGroupInfo is usually left aside when it comes to configuration
properties.
For instance, looks like they can share the following properties:
enabled, legend, path, advertised, queryable, and AuthorityURL and
Identifier once GEOS-4491 gets home. So I wouldn’t mind a common
superinterface?

List getItems()

Would this be ok?
Another thing is that the solution would be needed for the 2.1.x
series, so we’d need the
generic list of items to be stored among the metadata (fun eh?).

I’m facing a similar problem with the backwards compatibility patch
for GEOS-4491, as would need both LayerInfo and LayerGroupInfo to hold
more than one AuthorityURL, and even funnier cause AuthorityURL is not
a single string but a compound object.

Given that anything in the catalog as a globally unique di the
metadata could contain
a flat list of UUIDs, and the code parsing it would try each id for
both layer and layer group.

Of course also the GUI would have to be updated. To keep things simple
we could have
a “add layer” and a “add group” button.
And finally the cascaded deletion code would have to care for groups in groups.

Have I considered everything? Hmm… RESTConfig changes are going to
be real fun too…

Keep in touch cause I think I’ll also have to update the GWC catalog
listener in order to resolve both contained layer and layergroups when
truncated based on a config change.

Opinions?

Sounds good to me. I’d like to hear your opinions about the common
superinterface for LayerInfo and LayerGroup though, perhaps only on
trunk?

Cheers,
Gabriel.

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

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

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2

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.

4

On Fri, Oct 7, 2011 at 7:04 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Sounds good to me. I'd like to hear your opinions about the common
superinterface for LayerInfo and LayerGroup though, perhaps only on
trunk?

Seems a reasoable option to me, though working on it will require modifying
the group layer GUI and REST config even more deeply, and do the same
in the two WMS capabilities generators.

I don't mind if someone else does it, but I won't have time to cover it
(assuming this investigation turns into any funding, that is).

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

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

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

5

On Fri, Oct 7, 2011 at 9:01 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Some thoughts:
I would be for a common interface for Layer and LayerGroup... but not sure
what a good name for it would be... I would also be for just using
CatalogInfo if it suffices for this use case.
If LayerGroupInfo#layers is going to become a derived property that
recursively returns all the leafs of the tree I would like to see it
deprecated and renamed to "layers()" to keep with derived property naming
conventions. I like either getItems() or getContents() for the property that
returns only the direct children of the layer group.

Sure, this works.

You might be able to save yourself some headaches with the REST api by
allowing one to POST to an existing layer group the name of a layer / or
another layer group, rather than forcing the client to encode the contents
in the metadata map.

I agree, at least for construction, but I guess that for editing and deletion of
elements there is really no way out?
Anyways, yes, this is an headache, it seems to me the xstream code will have to
be able to understand both <layers> and <contents> on trunk for put operations
and act accordingly (to preserve backwards compatibility).
Wondering about GET, do we need to keep on returning both layers and contents?
I guess a simpler way would be to keep on returning layers only and allow groups
to be part of the list?
The issue with the persistence code is that we cannot do it without breaking
backwards compatibilty :frowning:

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

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

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

6

It seems that we could have a few implementations of LayerGroupInfo etc. for the express purpose of loading old data dirs - maybe we add a version= attribute to the root element and have XStream choose the implementation class based on that, with the fallback in case that attribute doesn’t exist being the last version before we started this scheme. Then these old models have a way to convert themselves into an equivalent, xstream-ready instance of the latest and greatest.

It seems like if we provide a backwards conversion this could also help support a versioned REST API, which would help give us a bit of freedom in developing useful new features that just happen to be awkward to implement in a backward-incompatible way (like this one.)

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

On Tue, Oct 11, 2011 at 10:48 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Oct 7, 2011 at 9:01 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Some thoughts:
I would be for a common interface for Layer and LayerGroup… but not sure
what a good name for it would be… I would also be for just using
CatalogInfo if it suffices for this use case.
If LayerGroupInfo#layers is going to become a derived property that
recursively returns all the leafs of the tree I would like to see it
deprecated and renamed to “layers()” to keep with derived property naming
conventions. I like either getItems() or getContents() for the property that
returns only the direct children of the layer group.

Sure, this works.

You might be able to save yourself some headaches with the REST api by
allowing one to POST to an existing layer group the name of a layer / or
another layer group, rather than forcing the client to encode the contents
in the metadata map.

I agree, at least for construction, but I guess that for editing and deletion of
elements there is really no way out?
Anyways, yes, this is an headache, it seems to me the xstream code will have to
be able to understand both and on trunk for put operations
and act accordingly (to preserve backwards compatibility).
Wondering about GET, do we need to keep on returning both layers and contents?
I guess a simpler way would be to keep on returning layers only and allow groups
to be part of the list?
The issue with the persistence code is that we cannot do it without breaking
backwards compatibilty :frowning:

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

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

All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

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