On Wed, Oct 13, 2010 at 3:10 PM, 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.
Thanks :-) > 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. Same layer, but joined with different data sets. Oh, you actually want it to perform SQL injection so that the different joins are part of the request? If so, beware of malicious use of the same. > 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 So basically, if there is a single set of params they are applied to all layers, but if there is more, then you apply each of them to a different layer? This is compatible with how we treat filters (another GeoServer specific extension to WMS), if there is just one it is replicated to all layers, if there are multiple the user is supposed to provide as many as the layers that are around, otherwise an exception will be thrown. > 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[, ...]). Cool > 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). If we want consistent behavior with the other replicated layers the syntax would have to be: LAYERS=parameterized,static&VIEWPARAMS=a:1;b:2, I mean, what you proposed would work as well but it would have a different meaning, it would result in passing the params to the second layer as well (which is not parametrized so it would not take them, but here I want to make sure we agree on the meaning of the syntax). In general it would be good to have everything consistent, so have this extension behave exactly like filters do (replicate if just one, apply one by one if the number of param groups match the number of layers, bomb out with an exception in case they don't match). > 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. Humm.... in WFS you can also make a request that will return multiple layers, something like: http://demo.opengeo.org/geoserver/ows?request=getfeature&version=1.0.0&service=wfs&typename=og:archsites,og:streams As you can see the relationship is positional as well > 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. Sounds good > 2. The output for GetFeatureInfo is incomplete if INFO_FORMAT is not > specified (only the first feature is output). I did not get this one. The default behavior is to return just one feature unless you manually specify a different number (by spec). If there is any interaction with INFO_FORMAT that is a bug indeed. > 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. May be, we recently had a large refactor in WMS, > 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. I did not have time to look into your patch so far, but you mention separate things above: the changes related to the extensions you're proposing, and a couple of bug fixes. It would help to have each bug fis sit in their own patch Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
