Hi! Folks,
Can you someone give me a hand how to integrate the “OpenStreetMap” into the GeoServer, my target is to show the “OpenStreetMap” as basemap through the “OpenLayers” application.
I assume the “OpenStreetMap” has to be a WMS service in the GeoServer first, how to do that?
Thank you for your great help!
Zhanping
From: “geoserver-devel-request@lists.sourceforge.net” geoserver-devel-request@lists.sourceforge.net
To: geoserver-devel@lists.sourceforge.net
Sent: Fri, October 15, 2010 9:56:00 AM
Subject: Geoserver-devel Digest, Vol 53, Issue 40
Send Geoserver-devel mailing list submissions to
geoserver-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
or, via email, send a message with subject or body ‘help’ to
geoserver-devel-request@lists.sourceforge.net
You can reach the person managing the list at
geoserver-devel-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than “Re: Contents of Geoserver-devel digest…”
Today’s Topics:
- Re: RFC: Parametric SQL View Enhancement Proposal (and patch)
(Eli Miller)
Message: 1
Date: Fri, 15 Oct 2010 09:55:48 -0400
From: Eli Miller <emiller@anonymised.com>
Subject: Re: [Geoserver-devel] RFC: Parametric SQL View Enhancement
Proposal (and patch)
To: Andrea Aime <andrea.aime@anonymised.com>
Cc: geoserver-devel@lists.sourceforge.net
Message-ID:
<AANLkTimC4fk+9LRuPdbKKrhgTGRDQR2oovJZfOcNMkyN@anonymised.com>
Content-Type: text/plain; charset=“windows-1252”
On Fri, Oct 15, 2010 at 4:45 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Wed, Oct 13, 2010 at 3:10 PM, Eli Miller <emiller@anonymised.com>
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:1or 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:1So 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:
- 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.
- 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.gmlAs 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.Humm… in WFS you can also make a request that will return multiple
layers, something
like: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:
- 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
- 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.
- 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 EngineerGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italyphone: +39 0584962313
fax: +39 0584962313http://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.
-------------- next part --------------
An HTML attachment was scrubbed…
Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) 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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
End of Geoserver-devel Digest, Vol 53, Issue 40