[Geoserver-devel] Nested layer groups: take 2, simplified plan

GeoServer GeoServer Developer
1

Hi,
discussing with the people that might be interested in funding the
nested layer groups
work we agreed a commit on 2.1.x is not critical.

So, what changes would be needed to only only in trunk?
I guess we could keep the layers property as is, making it a list of
CatalogInfo (or
common group/layers superclass, AbstractLayerInfo maybe, but as I
said, with no extra
work related to adding the common properties) and have a layers() method that
flattens out the list of LayerInfo().

This should also made the xstream work pretty much transparent, as we don't have
expectations that a 2.2.x data dir keeps on working when ported back to 2.1.x

There is a residual wrinkle I guess, which is styles: the current
layer group setup
has two parallel lists, layers and styles.
If we want to maintain this setup a layer group would have to correspond to an
empty slot in the styles list.

Or... we could have getLayers() contain a LayerGroupItemInfo, which in turns
contains Layer, LayerGroup and Style, or make that an abstract class
with two subclasses, one for layer groups and one for layers.
Not too eager on the second approach, it is more OO but also just
replace an if to test if
the layer or layer group is set with instanceof checks, and would make building
and processing the item lists more cumbersome.

Opinions?
Anything else missing?

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

Sounds good to me. I think adding LayerGroupItem that has “layer” property which can be a Layer or LayerGroup and a StyleI. I agree in that I think an instanceof check would probably be just as convenient as two subinterfaces of it, and more concise.

On Wed, Oct 12, 2011 at 1:15 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
discussing with the people that might be interested in funding the
nested layer groups
work we agreed a commit on 2.1.x is not critical.

So, what changes would be needed to only only in trunk?
I guess we could keep the layers property as is, making it a list of
CatalogInfo (or
common group/layers superclass, AbstractLayerInfo maybe, but as I
said, with no extra
work related to adding the common properties) and have a layers() method that
flattens out the list of LayerInfo().

This should also made the xstream work pretty much transparent, as we don’t have
expectations that a 2.2.x data dir keeps on working when ported back to 2.1.x

There is a residual wrinkle I guess, which is styles: the current
layer group setup
has two parallel lists, layers and styles.
If we want to maintain this setup a layer group would have to correspond to an
empty slot in the styles list.

Or… we could have getLayers() contain a LayerGroupItemInfo, which in turns
contains Layer, LayerGroup and Style, or make that an abstract class
with two subclasses, one for layer groups and one for layers.
Not too eager on the second approach, it is more OO but also just
replace an if to test if
the layer or layer group is set with instanceof checks, and would make building
and processing the item lists more cumbersome.

Opinions?
Anything else missing?

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

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

3

On Wed, Oct 12, 2011 at 4:23 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds good to me. I think adding LayerGroupItem that has "layer" property
which can be a Layer or LayerGroup and a StyleI. I agree in that I think an
instanceof check would probably be just as convenient as two subinterfaces
of it, and more concise.

There is one last annoying thing. The group external representation is made
of two parallel arrays, layers and styles.
Do we maintain it, giving a empty entry to the layer group styles?
I guess it's the more natural evolution path?

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

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

4

On Mon, Oct 17, 2011 at 9:59 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Oct 12, 2011 at 4:23 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds good to me. I think adding LayerGroupItem that has “layer” property
which can be a Layer or LayerGroup and a StyleI. I agree in that I think an
instanceof check would probably be just as convenient as two subinterfaces
of it, and more concise.

There is one last annoying thing. The group external representation is made
of two parallel arrays, layers and styles.
Do we maintain it, giving a empty entry to the layer group styles?
I guess it’s the more natural evolution path?

Right… yeah while annoying i think we want to maintain this, especially for the rest api.

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

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

5

On Tue, Oct 18, 2011 at 10:38 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

On Mon, Oct 17, 2011 at 9:59 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Wed, Oct 12, 2011 at 4:23 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
> Sounds good to me. I think adding LayerGroupItem that has "layer"
> property
> which can be a Layer or LayerGroup and a StyleI. I agree in that I think
> an
> instanceof check would probably be just as convenient as two
> subinterfaces
> of it, and more concise.

There is one last annoying thing. The group external representation is
made
of two parallel arrays, layers and styles.
Do we maintain it, giving a empty entry to the layer group styles?
I guess it's the more natural evolution path?

Right... yeah while annoying i think we want to maintain this, especially
for the rest api.

+1. In the _future_ having a placeholder for the layergroup style may
even be useful in case you want to have a SLD doc with
FeatureTypeStyles for each of the layers in the group?

2c/
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

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

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

------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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