[Geoserver-devel] Troubles with layer grouping on trunk

Hi,
I'm having issues with layer grouping on trunk... this is
a long and nasty story, so let me give you some background.

Before 1.5.1 release Alessio provided a patch to handle multiple
layer groups. After some massage, I merged it on 1.5.x, but
hadn't ported it to trunk because we were in a rush to release
1.5.1. And then, I forgot.

Today I spend some time trying to port it over, to find it
conflicts the hard way with the new dispatcher code (that in
the meantime was changed by Justin to use the new KVP parser
framework).

The trouble is that base map layer parsing was done by altering the request parameters before actual parsing, and this happened
on both layers and styles at the same time.

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).
When a request enters into 1.5.1, let's say it's
GetMap&layers=la,base,lb&styles=sa,sbase,sb
the code in 1.5.1 gets it, and expands style and layer to turn
it into:
GetMap&layers=la,l1,l2,lb&styles=sa,s1,s2,sb

This happens before actual parsing, so the GetMapKvpParser
did not know anything about grouping at all.

The trouble is, on trunk one can do KVP parsing of one
parameter at a time, so whilst I can still do the layer
expansion, I cannot do the same for styles (because it's
the layer that tell me a certain style has to be replaced
and expanded).

I guess the right solution now is to do the same job
in the GetMapKvpRequestReader, but nevertheless this
makes things harder (and makes us rehash some work
that was already done)...

Long story short... when you have to forward or back port
anything, do it right away, or bigger troubles than
you image will catch you when you'll attempt the merge.

Cheers
Andrea

Andrea Aime ha scritto:

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).

Ah, btw, since layer groups are defined like this now, do
we still need the WMS path trick around?
Cheers
Andrea

I feel your pain, apologies if I caused you more work then need be by
porting the GetMap code to the new framework.

So yeah... basically all "logic" all gets done in the request reader,
and only raw parsing gets done in the kvp parser. Which makes porting an
old style kvp request reader a bit of work...

-Justin

Andrea Aime wrote:

Hi,
I'm having issues with layer grouping on trunk... this is
a long and nasty story, so let me give you some background.

Before 1.5.1 release Alessio provided a patch to handle multiple
layer groups. After some massage, I merged it on 1.5.x, but
hadn't ported it to trunk because we were in a rush to release
1.5.1. And then, I forgot.

Today I spend some time trying to port it over, to find it
conflicts the hard way with the new dispatcher code (that in
the meantime was changed by Justin to use the new KVP parser
framework).

The trouble is that base map layer parsing was done by altering the
request parameters before actual parsing, and this happened
on both layers and styles at the same time.

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).
When a request enters into 1.5.1, let's say it's
GetMap&layers=la,base,lb&styles=sa,sbase,sb
the code in 1.5.1 gets it, and expands style and layer to turn
it into:
GetMap&layers=la,l1,l2,lb&styles=sa,s1,s2,sb

This happens before actual parsing, so the GetMapKvpParser
did not know anything about grouping at all.

The trouble is, on trunk one can do KVP parsing of one
parameter at a time, so whilst I can still do the layer
expansion, I cannot do the same for styles (because it's
the layer that tell me a certain style has to be replaced
and expanded).

I guess the right solution now is to do the same job
in the GetMapKvpRequestReader, but nevertheless this
makes things harder (and makes us rehash some work
that was already done)...

Long story short... when you have to forward or back port
anything, do it right away, or bigger troubles than
you image will catch you when you'll attempt the merge.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,468505da170188992556831!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Andrea Aime wrote:

Andrea Aime ha scritto:

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).

Ah, btw, since layer groups are defined like this now, do
we still need the WMS path trick around?

Hopefully not? I haven't looked at the new code yet, but definitely wanted it so there was just one way of doing things that shows up both for requests and for the capabilities document. Having too many options is confusing, so we should get rid of WMS path if the new layer grouping covers all cases.

Chris

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,46850701171074901796417!

Chris Holmes ha scritto:

Andrea Aime wrote:

Andrea Aime ha scritto:

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).

Ah, btw, since layer groups are defined like this now, do
we still need the WMS path trick around?

Hopefully not? I haven't looked at the new code yet, but definitely wanted it so there was just one way of doing things that shows up both for requests and for the capabilities document. Having too many options is confusing, so we should get rid of WMS path if the new layer grouping covers all cases.

Hum, yeah, they do show up in the capabilities as non queriable layers (well, we have a bug here, because GetFeatureInfo tries to query them
anyways... hum... should we make then queriable, or it's assumed a group
is just "background"?).

Here is a sample:

<Layer queryable="0">
           <Name>raster</Name>
           <Title>raster</Title>
           <Abstract>Layer-Group type layer: raster</Abstract>
           <SRS>EPSG:4326</SRS>
           <LatLonBoundingBox minx="6.34617490847439" miny="36.4917718219401" maxx="20.8296831527815" maxy="46.5907669751351"/>
           <BoundingBox SRS="EPSG:4326" minx="6.34617490847439" miny="36.4917718219401" maxx="20.8296831527815" maxy="46.5907669751351"/>
           <Style>
             <Name>raster</Name>
             <Title>raster</Title>
             <Abstract>Layer-Group complex style</Abstract>
           </Style>
         </Layer>

There is no indication whatsoever of which are the sublayers,
no nesting or paths (which is what people want I guess).

So, shall we get rid of the WMS paths?
Cheers
Andrea

Andrea,
today I've done a new post, related the capabilities to invoke a WMS with
one layer and one marker.
It's possible?
thanks in advance
Jack

aaime wrote:

Chris Holmes ha scritto:

Andrea Aime wrote:

Andrea Aime ha scritto:

A base layer is defined by a list of layers and a list of styles,
for example base -> (l1,l2),(s1,s2).

Ah, btw, since layer groups are defined like this now, do
we still need the WMS path trick around?

Hopefully not? I haven't looked at the new code yet, but definitely
wanted it so there was just one way of doing things that shows up both
for requests and for the capabilities document. Having too many options
is confusing, so we should get rid of WMS path if the new layer grouping
covers all cases.

Hum, yeah, they do show up in the capabilities as non queriable layers
(well, we have a bug here, because GetFeatureInfo tries to query them
anyways... hum... should we make then queriable, or it's assumed a group
is just "background"?).

Here is a sample:

<Layer queryable="0">
           <Name>raster</Name>
           <Title>raster</Title>
           <Abstract>Layer-Group type layer: raster</Abstract>
           <SRS>EPSG:4326</SRS>
           <LatLonBoundingBox minx="6.34617490847439"
miny="36.4917718219401" maxx="20.8296831527815" maxy="46.5907669751351"/>
           <BoundingBox SRS="EPSG:4326" minx="6.34617490847439"
miny="36.4917718219401" maxx="20.8296831527815" maxy="46.5907669751351"/>
           <Style>
             <Name>raster</Name>
             <Title>raster</Title>
             <Abstract>Layer-Group complex style</Abstract>
           </Style>
         </Layer>

There is no indication whatsoever of which are the sublayers,
no nesting or paths (which is what people want I guess).

So, shall we get rid of the WMS paths?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
View this message in context: http://www.nabble.com/Troubles-with-layer-grouping-on-trunk-tp11360030p15357469.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.