Hello GeoServer Developers,
We have been assessing the use of GeoServer for some projects and have found it to be very promising – so far it has addressed the majority of our functional requirements. Thank you for the great work that you have done.
Our system tracks a reasonably large number of layers which are stored in a database and serves a reasonably large number of real-time daily image rendering requests which are ad-hoc in nature. Individual layers are rendered many times and are joined to a wide range of non-spatial data that is determined at runtime. As such, we are very interested in the Parametric SQL View Feature of the GeoServer 2.1 release. For the sake of efficiency and scaling we are hoping to avoid the creation of many on-demand database tables, database views or GeoServer Feature Type and Layer Definitions. The one problem that we are encountering is that our image requests will often reference the same layer multiple times (but joined to different data sets). Because the current capabilities of the Parametric SQL View Feature of GeoServer scopes the incoming SQL parameters to the request instead of individual layers, we have not been able to emulate this behavior with GeoServer.
After some review of the GeoServer trunk code I was able to put together a proof-of-concept that would allow WMS requests using the Parametric SQL View Feature to take advantage of positionally-specified parameters (just as styles are positionally specified). For example, the layer gisws:filter_pg_layer_19 is defined using parameterized SQL (the parameters are rdid and sid). The changes that I describe allow WMS to render an image that includes two copies of the layer joined to different data sets through the specification of view parameters by layer. The syntax that I use is compatible with the current syntax – if there is only one layer in use, the syntax is unchanged. An example WMS request using this syntax is:
http://localhost:8080/geoserver/wms?
VERSION=1.1.0&
SERVICE=wms&
REQUEST=getmap&
WIDTH=600&
HEIGHT=400&
SRS=EPSG:4326&
BBOX=-24.542,51.297,-0.018,66.565&
FORMAT=image/png&
STYLES=red,blue&
LAYERS=gisws:filter_pg_layer_19,gisws:filter_pg_layer_19&
VIEWPARAMS=rdid:1;sid:2,rdid:1;sid:1
or via the reflector:
http://localhost:8080/geoserver/wms/reflect?
WIDTH=800&
BBOX=-24.542,51.297,-0.018,66.565&
FORMAT=image/png&
STYLES=red,blue&
LAYERS=gisws:filter_pg_layer_19,gisws:filter_pg_layer_19&
VIEWPARAMS=rdid:1;sid:2,rdid:1;sid:1
The only scenarios that I can think of where these changes could cause behavioral incompatibilities with the current methodology are:
- Multiple layers are being used and the view parameters apply to several of them. In this case, the request form would need to replicate the parameters for each layer in the VIEWPARAMS (e.g. VIEWPARAMS=a:1;b:2 would need to be changed to VIEWPARAMS=a:1;b:2,a:1;b:2[, …]).
- Multiple layers are being used, one of which is a parameterized SQL view but is not listed first in the sequence (e.g. LAYERS=static,parameterized&VIEWPARAMS=a:1;b:2). In this case the VIEWPARAMS would need to be left-padded so that the parameters were in the same position as the parametrized layer (LAYERS=static,parameterized&VIEWPARAMS=,a:1;b:2) or, if viable, the layer sequence could instead be changed (LAYERS=parameterized,static&VIEWPARAMS=a:1;b:2).
I have assessed support for other WMS request types given these changes. Everything works as expected for GetFeatureInfo:
http://localhost:8080/geoserver/wms?
VERSION=1.1.0&
REQUEST=GetFeatureInfo&
SERVICE=wms&
WIDTH=600&
HEIGHT=400&
SRS=EPSG:4326&
BBOX=-24.542,51.297,-0.018,66.565&
LAYERS=gisws:filter_pg_layer_19,gisws:filter_pg_layer_19&
VIEWPARAMS=rdid:1;sid:2,rdid:1;sid:1&
QUERY_LAYERS=gisws:filter_pg_layer_19,gisws:filter_pg_layer_19&
X=100&
Y=50&
INFO_FORMAT=application/vnd.ogc.gml
As best I can tell these changes do not seem to be relevant to the DescribeLayer or GetLegendGraphic request types.
The proof-of-concept changes that I made were limited to OWS and WMS and include the following:
- The view params object was switched from Map to List.
- A new WMS ViewParamsKvpParser was created (which delegates its tokens to the FormatOptionsKvpParser).
- References to view params now index into the list based on layer sequencing.
- The GetMapKvpRequestReaderTest was expanded to include appropriate new tests.
I specifically avoided making any changes in WFS, as it seems like the approach is not as well defined but I would be happy to work on integrating these changes into WFS if anyone thinks it would be worthwhile and they would be willing to provide some guidance. On first glance it seems like positional referencing may not be the best approach for WFS.
While testing things I noticed a couple of issues that I’d be happy to elaborate on via JIRA if appropriate:
- The FormatOptionsKvpParser does not provide any escaping mechanism (I’m thinking along the lines of the comment in WFS 1.1.0 14.2.2). I don’t know that this section of the specification is directly relevant but it does seem like VIEWPARAMS should allow any values to be specified (particularly if character-based SQL parameters are being used). I have included an alternate implementation of FormatOptionsKvpParser that allows for values from KVPs to support backslash as an escape character and added supporting test cases.
14.2.2 Parameter lists
Parameters consisting of lists shall use the comma (“,”) as the delimiter between items in
the list. In addition, multiple lists can be specified as the value of a parameter by
enclosing each list in parentheses; “(”, “)”. The characters “,”, “(“ and “)” may be
escaped using the “\” character.
- The output for GetFeatureInfo is incomplete if INFO_FORMAT is not specified (only the first feature is output).
- GetLegendGraphic is not properly handling the FORMAT parameter – it seems to require specification of both OUTPUTFORMAT and FORMAT (and it uses OUTPUTFORMAT to determine the Response instance(s) to use). I assume that this is a regression or is due to work-in-progress.
I hope that there is interest in these enhancements (and it would be great if there was a chance of them getting into the 2.1 release). I would be happy to assist with this in any manner that I can.
Best regards,
Eli Miller
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
(attachments)
geoserver.patch (19 KB)
