On Fri, Oct 15, 2010 at 4:45 AM, Andrea Aime
<[email protected]>wrote:
> 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.
>
>
Agreed, but it doesn't seem like it creates too much more exposure than the
current Parametric SQL Views (except that it exposes multiple layers with
independent parameters).
> > 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.
>
>
Actually, the logic that I implemented applies the parameters to a layer if
and only if the parameters were specified in the same position as that of
the layer -- if there is only a single set of parameters it is not applying
it to all layers. This would be easy to change and seems to make sense in
terms of consistency with other features.
> > 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
>
If we changed the handling when a single set of parameters was specified as
noted above, this would no longer be an issue.
>
> > 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).
>
>
Good point, the implementation that I included is lenient in that it allows
for any number of sets of parameters to be specified but should enforce 0,1
or N where N is the number of layers.
> > 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
>
>
I will take a closer look at this.
> > 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.
>
>
This may just be my misunderstanding. I was surprised that I got one
feature back when INFO_FORMAT was not specified, and multiple features when
it was specified.
> > 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
>
>
I will separate out the matters that I discussed as best as I can and enter
them in JIRA.
> 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
>
> -----------------------------------------------------
>
***************************************************
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.
***************************************************
------------------------------------------------------------------------------
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
