Hi Eli, this is great work, nicely described. Please attach the patch to a JIRA task, and create those other JIRA tasks.
Previously I've done the same sort of thing using SLDs - each SLD can have a filter and I stored a parameterised SLD - and parameterised WFS templates for the same purpose, instead of semantically non-descriptive service endpoints in a service catalog. The other option is dimensions - often parameters are really dimensions of a phenomena - can you comment on whether these standard mechanisms would work and if not, why not? Rob On Thu, Oct 14, 2010 at 12:10 AM, Eli Miller <[email protected]> wrote: > > 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: > > 1. 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[, ...]). > 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: > > 1. The view params object was switched from Map to List<Map>. > 2. A new WMS ViewParamsKvpParser was created (which delegates its tokens > to the FormatOptionsKvpParser). > 3. References to view params now index into the list based on layer > sequencing. > 4. 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: > > 1. 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. > > 2. The output for GetFeatureInfo is incomplete if INFO_FORMAT is not > specified (only the first feature is output). > 3. 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. > *************************************************** > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
