Hi Rob,
Thanks for the quick response and suggestion regarding parametrized SLDs.
Our current GIS platform is not OGC compliant so I am familiarizing myself
with all the concepts and had overlooked the SLD-based filtering technique
that you describe. On first review, it seems like this approach could meet
our needs. With some experimentation I was able to achieve comparable
results by posting an SLD to WMS using NamedLayers with UserStyle Rules (I
didn't have as much luck with LayerFeatureConstraints but I am continuing to
research that). From a system resource efficiency perspective should it be
better to use LayerFeatureConstraints instead of excluding features from
rendering via Rules?
I agree with you that the Parametrized SQL View approach encourages use of a
non-descriptive endpoint which has implications. It also seems like
GeoServer might have less of an opportunity for caching (or cache re-use)
when SQL View parameters are in use. Nonetheless I would be curious if
anyone has tested or can vouch for the possible performance differences
between filtering data in a spatial database before it gets to GeoServer
versus filtering in GeoServer (which I assume is what happens when the
filter criteria are posted in a request-scoped SLD). Performance seemed
reasonable during my cursory testing but I do need to better assess this
from an overall resource consumption perspective -- I will be sure to share
any results.
Although the data we are presenting is dimensional in nature it is related
to many different, and frequently updated, data sets which makes it
impractical to incorporate as layer attributes.
I will add the issues and patches to JIRA.
Best regards,
Eli
On Wed, Oct 13, 2010 at 7:49 PM, Rob Atkinson <[email protected]>wrote:
> 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
> >
> >
>
***************************************************
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
