[Geoserver-devel] openlayers output format

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:

class Request {
   ...
   Map getVendorParameters();
   ...
}

Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?

-Justin

Farber, Saul (EEA) wrote:

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

-------------------------------------------------------------------------
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,46672fe6183628992556831!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin,

Cool, thanks for the historic info.

I think it's useful enough, however, to have a many-layer version as a non-default option on the application/openlayers outputformat.

As for where to put the vendor parameters, here's what's in my head:

For a given operation (GetMap, GetFeature, GetCoverage, etc.) on a given service, we should decide ahead of time which EXISTING parameters are 'vendor-extendable'. This will probably change over time, as people add options to geoserver requests (like this openlayers one)

These parameters are things like 'FORMAT=application/openlayers;layerGrouping:on,bells:off,whistles:on'
or
'TRANSPARENT=true;model:singlePixelTransparency,alphaBlending:2layersdown'
where an existing parameter is 'vendor-extended' by adding a semi-colon after the expected value, and comma-delimited, colon-seperated KVPs follow.
(the last one is a stretch, but it's just an example)

There should be a convenience method on Request which will parse an 'extended' parameter like these. Something like this:

public static List getVendorOptions(rawString) {
  //discard the 'real' value
  //collect a String of the remaining colon-delimeted pairs
}

and

public static String getStandardOption(rawString) {
  return [string off everything after the ';' in rawString ,if there is one]
}

This allows the Request subclasses (by way of their respective XML and KVP readers) to store the vendorOptions as a list (if they want to) or to just store the whole raw string, knowing that convenience methods exist to pull out the vendor params in the actual operation code later.

By the way, I think the return type should be a List, because parameters may not necessarily be unique (think COVERAGE_OPTION=BANDA;red:band1,red:band2,blue:band3 or another situation where the keys might not be unique)

Seperately from this, fully optional vendor parameters could potentially exist on all requests, but I'm not sure what the advantage to

Map Request.getVendorParameters()

is over just using

HttpServletRequest.getParameterValue()

for raw parametetrs, or actually doing the parsing and creating getters/setters for more 'formalized' optional parameters.

Thoughts?

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 6:37 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:

class Request {
   ...
   Map getVendorParameters();
   ...
}

Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?

-Justin

Farber, Saul (EEA) wrote:

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

-------------------------------------------------------------------------
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,46672fe6183628992556831!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

I am a little weary of "extending" existing parameters in this way. If
so we would have to do one of two things.

1. Pre-parse all kvp and split out the vendor options or:
2. Have the "getValue" method on KvpRequestReader handle this and
essentially do what "getStandardOption" does

Also (I am not sure) but i believe there is code that directly accesses
kvp through HttpServerRequest.getParameters(), so that code could
potentially break.

I also believe this falls apart when a kvp allows a ";" as part of its
value space. IE. how do you know if the first ";" is part of the value
proper, or the start of vendor options.

The nice thing about doing it entirely in a separate kvp is that we have
full control over what "allowable" values are. IE. if we say semi column
means start of vendor option, then thats what it means. We don't have to
worry about a new spec or something coming along which introduces a semi
colon as an allowable value.

So how about this. We use the "VENDOR_OPTIONS" key name, but we change
its format slightly so that the first "token" is the kvp we are
extending. So for example, rewriting your examples would be:

'FORMAT=application/openlayers&VENDOR_OPTIONS=FORMAT,layerGrouping:on,bells:off,whistles:on'
'TRANSPARENT=true&VENDOR_OPTIONS=TRANSPARENT,model:singlePixelTransparency,alphaBlending:2layersdown'

This way all the old kvp code does not have to change at all. We can
still have the method for looking up a vendor option be:

List getVendorOptions( String key );

What do you think?

Farber, Saul (EEA) wrote:

Justin,

Cool, thanks for the historic info.

I think it's useful enough, however, to have a many-layer version as a non-default option on the application/openlayers outputformat.

As for where to put the vendor parameters, here's what's in my head:

For a given operation (GetMap, GetFeature, GetCoverage, etc.) on a given service, we should decide ahead of time which EXISTING parameters are 'vendor-extendable'. This will probably change over time, as people add options to geoserver requests (like this openlayers one)

These parameters are things like 'FORMAT=application/openlayers;layerGrouping:on,bells:off,whistles:on'
or
'TRANSPARENT=true;model:singlePixelTransparency,alphaBlending:2layersdown'
where an existing parameter is 'vendor-extended' by adding a semi-colon after the expected value, and comma-delimited, colon-seperated KVPs follow.
(the last one is a stretch, but it's just an example)

There should be a convenience method on Request which will parse an 'extended' parameter like these. Something like this:

public static List getVendorOptions(rawString) {
  //discard the 'real' value
  //collect a String of the remaining colon-delimeted pairs
}

and

public static String getStandardOption(rawString) {
  return [string off everything after the ';' in rawString ,if there is one]
}

This allows the Request subclasses (by way of their respective XML and KVP readers) to store the vendorOptions as a list (if they want to) or to just store the whole raw string, knowing that convenience methods exist to pull out the vendor params in the actual operation code later.

By the way, I think the return type should be a List, because parameters may not necessarily be unique (think COVERAGE_OPTION=BANDA;red:band1,red:band2,blue:band3 or another situation where the keys might not be unique)

Seperately from this, fully optional vendor parameters could potentially exist on all requests, but I'm not sure what the advantage to

Map Request.getVendorParameters()

is over just using

HttpServletRequest.getParameterValue()

for raw parametetrs, or actually doing the parsing and creating getters/setters for more 'formalized' optional parameters.

Thoughts?

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 6:37 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:

class Request {
   ...
   Map getVendorParameters();
   ...
}

Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?

-Justin

Farber, Saul (EEA) wrote:

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

-------------------------------------------------------------------------
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

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

!DSPAM:4007,46673eb6194526491211187!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Those are a couple of really good points Justin.

I hadn't considered that other code might be using HttpServletRequest.getParameterValue() directly, but you're right that this may very well break things. So I guess that rules out the general case of 'extending' parameters that way.

Andrea had brought up yesterday (and over the last couple of days, I think) the idea of extending the FORMAT= parameter in exactly that way, however. It's entirely possible that I mis-interpreted that idea, though, so I'd love to hear Andrea's call on the FORMAT= parameter and all this stuff.

I like the idea of VENDOR_OPTIONS as a general tag with colon-seperated, comma-delimeted KVPs, and a general

List Request.getVendorOptions()

method. I guess I'd rather see the main parameter called "GEOSERVER_OPTIONS" rather than VENDOR_OPTIONS, but if VENDOR_OPTIONS is the OGC-approved tag, then I guess we should go that route.

Is there an approved way to map VENDOR_OPTIONS=a:b,c:d from XML requests? Or would it be done ad-hoc by the individual request XML parsers?

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 7:34 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

I am a little weary of "extending" existing parameters in this way. If
so we would have to do one of two things.

1. Pre-parse all kvp and split out the vendor options or:
2. Have the "getValue" method on KvpRequestReader handle this and
essentially do what "getStandardOption" does

Also (I am not sure) but i believe there is code that directly accesses
kvp through HttpServerRequest.getParameters(), so that code could
potentially break.

I also believe this falls apart when a kvp allows a ";" as part of its
value space. IE. how do you know if the first ";" is part of the value
proper, or the start of vendor options.

The nice thing about doing it entirely in a separate kvp is that we have
full control over what "allowable" values are. IE. if we say semi column
means start of vendor option, then thats what it means. We don't have to
worry about a new spec or something coming along which introduces a semi
colon as an allowable value.

So how about this. We use the "VENDOR_OPTIONS" key name, but we change
its format slightly so that the first "token" is the kvp we are
extending. So for example, rewriting your examples would be:

'FORMAT=application/openlayers&VENDOR_OPTIONS=FORMAT,layerGrouping:on,bells:off,whistles:on'
'TRANSPARENT=true&VENDOR_OPTIONS=TRANSPARENT,model:singlePixelTransparency,alphaBlending:2layersdown'

This way all the old kvp code does not have to change at all. We can
still have the method for looking up a vendor option be:

List getVendorOptions( String key );

What do you think?

Farber, Saul (EEA) wrote:

Justin,

Cool, thanks for the historic info.

I think it's useful enough, however, to have a many-layer version as a non-default option on the application/openlayers outputformat.

As for where to put the vendor parameters, here's what's in my head:

For a given operation (GetMap, GetFeature, GetCoverage, etc.) on a given service, we should decide ahead of time which EXISTING parameters are 'vendor-extendable'. This will probably change over time, as people add options to geoserver requests (like this openlayers one)

These parameters are things like 'FORMAT=application/openlayers;layerGrouping:on,bells:off,whistles:on'
or
'TRANSPARENT=true;model:singlePixelTransparency,alphaBlending:2layersdown'
where an existing parameter is 'vendor-extended' by adding a semi-colon after the expected value, and comma-delimited, colon-seperated KVPs follow.
(the last one is a stretch, but it's just an example)

There should be a convenience method on Request which will parse an 'extended' parameter like these. Something like this:

public static List getVendorOptions(rawString) {
  //discard the 'real' value
  //collect a String of the remaining colon-delimeted pairs
}

and

public static String getStandardOption(rawString) {
  return [string off everything after the ';' in rawString ,if there is one]
}

This allows the Request subclasses (by way of their respective XML and KVP readers) to store the vendorOptions as a list (if they want to) or to just store the whole raw string, knowing that convenience methods exist to pull out the vendor params in the actual operation code later.

By the way, I think the return type should be a List, because parameters may not necessarily be unique (think COVERAGE_OPTION=BANDA;red:band1,red:band2,blue:band3 or another situation where the keys might not be unique)

Seperately from this, fully optional vendor parameters could potentially exist on all requests, but I'm not sure what the advantage to

Map Request.getVendorParameters()

is over just using

HttpServletRequest.getParameterValue()

for raw parametetrs, or actually doing the parsing and creating getters/setters for more 'formalized' optional parameters.

Thoughts?

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 6:37 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:

class Request {
   ...
   Map getVendorParameters();
   ...
}

Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?

-Justin

Farber, Saul (EEA) wrote:

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

-------------------------------------------------------------------------
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

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

!DSPAM:4007,46673eb6194526491211187!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Farber, Saul (EEA) wrote:

Those are a couple of really good points Justin.

I hadn't considered that other code might be using HttpServletRequest.getParameterValue() directly, but you're right that this may very well break things. So I guess that rules out the general case of 'extending' parameters that way.

Andrea had brought up yesterday (and over the last couple of days, I think) the idea of extending the FORMAT= parameter in exactly that way, however. It's entirely possible that I mis-interpreted that idea, though, so I'd love to hear Andrea's call on the FORMAT= parameter and all this stuff.

I like the idea of VENDOR_OPTIONS as a general tag with colon-seperated, comma-delimeted KVPs, and a general

List Request.getVendorOptions()

method. I guess I'd rather see the main parameter called "GEOSERVER_OPTIONS" rather than VENDOR_OPTIONS, but if VENDOR_OPTIONS is the OGC-approved tag, then I guess we should go that route.

I would be cool with calling it "GEOSERVER_OPTIONS". It is less likely
to be clobbered by a kvp option from a new spec :).

Is there an approved way to map VENDOR_OPTIONS=a:b,c:d from XML requests? Or would it be done ad-hoc by the individual request XML parsers?

Good question. WFS capabilities documents have the notion of vendor
specific capabilities... but i don't think there is way to specify
things specific to them in a request, not that i can tell at least.

We could "roll our own" I guess. Although doing that would break any
parser that is validating...tough one.

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 7:34 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

I am a little weary of "extending" existing parameters in this way. If
so we would have to do one of two things.

1. Pre-parse all kvp and split out the vendor options or:
2. Have the "getValue" method on KvpRequestReader handle this and
essentially do what "getStandardOption" does

Also (I am not sure) but i believe there is code that directly accesses
kvp through HttpServerRequest.getParameters(), so that code could
potentially break.

I also believe this falls apart when a kvp allows a ";" as part of its
value space. IE. how do you know if the first ";" is part of the value
proper, or the start of vendor options.

The nice thing about doing it entirely in a separate kvp is that we have
full control over what "allowable" values are. IE. if we say semi column
means start of vendor option, then thats what it means. We don't have to
worry about a new spec or something coming along which introduces a semi
colon as an allowable value.

So how about this. We use the "VENDOR_OPTIONS" key name, but we change
its format slightly so that the first "token" is the kvp we are
extending. So for example, rewriting your examples would be:

'FORMAT=application/openlayers&VENDOR_OPTIONS=FORMAT,layerGrouping:on,bells:off,whistles:on'
'TRANSPARENT=true&VENDOR_OPTIONS=TRANSPARENT,model:singlePixelTransparency,alphaBlending:2layersdown'

This way all the old kvp code does not have to change at all. We can
still have the method for looking up a vendor option be:

List getVendorOptions( String key );

What do you think?

Farber, Saul (EEA) wrote:

Justin,

Cool, thanks for the historic info.

I think it's useful enough, however, to have a many-layer version as a non-default option on the application/openlayers outputformat.

As for where to put the vendor parameters, here's what's in my head:

For a given operation (GetMap, GetFeature, GetCoverage, etc.) on a given service, we should decide ahead of time which EXISTING parameters are 'vendor-extendable'. This will probably change over time, as people add options to geoserver requests (like this openlayers one)

These parameters are things like 'FORMAT=application/openlayers;layerGrouping:on,bells:off,whistles:on'
or
'TRANSPARENT=true;model:singlePixelTransparency,alphaBlending:2layersdown'
where an existing parameter is 'vendor-extended' by adding a semi-colon after the expected value, and comma-delimited, colon-seperated KVPs follow.
(the last one is a stretch, but it's just an example)

There should be a convenience method on Request which will parse an 'extended' parameter like these. Something like this:

public static List getVendorOptions(rawString) {
  //discard the 'real' value
  //collect a String of the remaining colon-delimeted pairs
}

and

public static String getStandardOption(rawString) {
  return [string off everything after the ';' in rawString ,if there is one]
}

This allows the Request subclasses (by way of their respective XML and KVP readers) to store the vendorOptions as a list (if they want to) or to just store the whole raw string, knowing that convenience methods exist to pull out the vendor params in the actual operation code later.

By the way, I think the return type should be a List, because parameters may not necessarily be unique (think COVERAGE_OPTION=BANDA;red:band1,red:band2,blue:band3 or another situation where the keys might not be unique)

Seperately from this, fully optional vendor parameters could potentially exist on all requests, but I'm not sure what the advantage to

Map Request.getVendorParameters()

is over just using

HttpServletRequest.getParameterValue()

for raw parametetrs, or actually doing the parsing and creating getters/setters for more 'formalized' optional parameters.

Thoughts?

--saul

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 6:37 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:

class Request {
   ...
   Map getVendorParameters();
   ...
}

Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?

-Justin

Farber, Saul (EEA) wrote:

Hey all,

I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.

It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.

However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.

Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:

&format=application/openlayers,groupLayers:[true|false]

With the default set to...well, I don't know which is appropriate for the default.

There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?

--saul

-------------------------------------------------------------------------
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

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

-------------------------------------------------------------------------
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,46674776200171961014482!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Farber, Saul (EEA) ha scritto:

Those are a couple of really good points Justin.

I hadn't considered that other code might be using
HttpServletRequest.getParameterValue() directly, but you're right
that this may very well break things. So I guess that rules out the
general case of 'extending' parameters that way.

Andrea had brought up yesterday (and over the last couple of days, I
think) the idea of extending the FORMAT= parameter in exactly that
way, however. It's entirely possible that I mis-interpreted that
idea, though, so I'd love to hear Andrea's call on the FORMAT=
parameter and all this stuff.

Yup, that's a misunderstanding. My idea was something along the lines
of:
FORMAT_OPTIONS=n1:v1,n2:v2,...
where FORMAT_OPTIONS is the name of the vendor option (so it was a
slightly different idea than Justin one too)

Is there an approved way to map VENDOR_OPTIONS=a:b,c:d from XML
requests? Or would it be done ad-hoc by the individual request XML
parsers?

Dangerous ground this one. Vendor options have been supported so far
only on GET requests for a reason, that is, we aren't breaking the standard.
Handling extensions at the XML level would mean having to provide
our own extended XML schemas, and hoping clients do use the schema locations we provide for parsing, instead of the standard xsd.
Are you sure you want to do this?
Cheers
Andrea

Justin Deoliveira ha scritto:

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

The argument is the following: how do you cascade layer related parameters to the openlayers definitions?
Two examples, SLD and Filter.
Our parsing code parses the filters (our own WMS protocol extension that do match the WFS GetFeature request), that can be specified in 3 ways (ids, ogc filter, cql filter), and the output format can only access
Filter objects.

Now, how we don't know how the filter was expressed originally, and the
most general form (OGC filter) is very verbose. So, if I use it, I have
no guarantee the request will still be small enough to fit the GET limits.

With SLD I think it's the same, with the aggravation that styles can
be specified with external URL too (so a monster SLD can be expressed
by a very small spec in the original GetMap query).

By avoiding to split layers into base and overlays, I could write code
that ignored splitting and parsing style and filter list, and simply cloned the original request. This also has a mantainance benefit, in
that we don't have to touch the OL output format each time we add
vendor params (and we don't have to separate them into "splittable,
layer specific" and general ones, too).

I was seduced by the idea of an output format that could become a "frontend generator", but trying to implement the simple cascading
above (and failing), I went back on my feet and concluded that
Openlayers output format is there for quick data preview, and that's all.
The other risk in assuming the OL output format is a silver bullet is
that we'll end up adding a billion of options to it. Today I want
GetFeatureInfo. Tomorrow I want the preview area to fit the browser
window. The next day, why don't we add an option for WFS editing? And
so on... I have the feeling it's a slipper slope.

If the user wants to get fancy, grabbing the initial HTML we generated
and customizing it to his heart desires is not hard imho.

Anyways, you seem to be quite eager to try and push the limits
of the OL output format. Why don't you clone it, making an application/openlayers2 hit it with whatever fancy you, try to
address the issues above, and we can see where we end up?
I gave up quickly because I had other things to do, but if you
have the time and energy, why not try? :slight_smile:

Cheers
Andrea

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Saul,

This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).

The argument is the following: how do you cascade layer related parameters to the openlayers definitions?
Two examples, SLD and Filter.
Our parsing code parses the filters (our own WMS protocol extension that do match the WFS GetFeature request), that can be specified in 3 ways (ids, ogc filter, cql filter), and the output format can only access
Filter objects.

Now, how we don't know how the filter was expressed originally, and the
most general form (OGC filter) is very verbose. So, if I use it, I have
no guarantee the request will still be small enough to fit the GET limits.

With SLD I think it's the same, with the aggravation that styles can
be specified with external URL too (so a monster SLD can be expressed
by a very small spec in the original GetMap query).

By avoiding to split layers into base and overlays, I could write code
that ignored splitting and parsing style and filter list, and simply cloned the original request. This also has a mantainance benefit, in
that we don't have to touch the OL output format each time we add
vendor params (and we don't have to separate them into "splittable,
layer specific" and general ones, too).

I was seduced by the idea of an output format that could become a "frontend generator", but trying to implement the simple cascading
above (and failing), I went back on my feet and concluded that
Openlayers output format is there for quick data preview, and that's all.
The other risk in assuming the OL output format is a silver bullet is
that we'll end up adding a billion of options to it. Today I want
GetFeatureInfo. Tomorrow I want the preview area to fit the browser
window. The next day, why don't we add an option for WFS editing? And
so on... I have the feeling it's a slipper slope.

If the user wants to get fancy, grabbing the initial HTML we generated
and customizing it to his heart desires is not hard imho.

The other route we could take would be to have a page in the web admin that is made to configure an openlayers map. Then we wouldn't have to try to squeeze everything in to the WMS request pipeline.

Anyways, you seem to be quite eager to try and push the limits
of the OL output format. Why don't you clone it, making an application/openlayers2 hit it with whatever fancy you, try to
address the issues above, and we can see where we end up?
I gave up quickly because I had other things to do, but if you
have the time and energy, why not try? :slight_smile:

Of course I'd be more than happy with this as well, as there could be more cool stuff done.

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,46679cf5279851961014482!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org