Hi! Guys,
Can you someone help me to know how to publish a WMS service from GeoServer with my own dataset (map), thank you in advance.
Zhanping
From: “geoserver-devel-request@lists.sourceforge.net” geoserver-devel-request@anonymised.comt
To: geoserver-devel@lists.sourceforge.net
Sent: Fri, October 15, 2010 8:10:10 AM
Subject: Geoserver-devel Digest, Vol 53, Issue 36
Send Geoserver-devel mailing list submissions to
geoserver-devel@anonymised.comt
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:
- [jira] Created: (GEOS-4178) Style editor do no use charset
described in SLD (Lazarev Eugene (JIRA)) - Re: RFC: Parametric SQL View Enhancement Proposal (and patch)
(Andrea Aime) - problem with REST, thread-safe issue (Martins Linde)
- Re: RFC: Parametric SQL View Enhancement Proposal (and patch)
(Eli Miller)
Message: 1
Date: Fri, 15 Oct 2010 03:32:32 -0500 (CDT)
From: “Lazarev Eugene (JIRA)” <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-4178) Style editor do
no use charset described in SLD
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<16702075.81320.1287131552464.JavaMail.haus-jira@anonymised.com>
Content-Type: text/plain; charset=ISO-8859-1
Style editor do no use charset described in SLD
Key: GEOS-4178
URL: http://jira.codehaus.org/browse/GEOS-4178
Project: GeoServer
Issue Type: Bug
Components: Configuration
Affects Versions: 2.1-beta1, 2.0.2
Environment: Windows Server 2003
Reporter: Lazarev Eugene
Assignee: Justin Deoliveira
Attachments: SLD.PNG, Styler.PNG
if i upload style throw REST in UTF-8 encoding, file created in this encoding but style editor doesn’t use encoding described in sld header
<?xml version="1.0" encoding="UTF-8"?>i suppose that used system encoding (windows-1251 in my case)
so i can’t read characters
–
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Message: 2
Date: Fri, 15 Oct 2010 10:45:21 +0200
From: Andrea Aime <andrea.aime@anonymised.com>
Subject: Re: [Geoserver-devel] RFC: Parametric SQL View Enhancement
Proposal (and patch)
To: Eli Miller <emiller@anonymised.com9…>
Cc: geoserver-devel@lists.sourceforge.net
Message-ID:
<AANLkTi=EkB+OgOocu=tu0ZbMPf-eVmV_oS46_4vG0weN@anonymised.com>
Content-Type: text/plain; charset=windows-1252
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.
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: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.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:??? 1. The view params object was switched from Map to List.
??? 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:
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
Message: 3
Date: Fri, 15 Oct 2010 13:40:46 +0300
From: Martins Linde <martins.linde@anonymised.com…403…>
Subject: [Geoserver-devel] problem with REST, thread-safe issue
To: geoserver-devel@anonymised.coms.sourceforge.net
Message-ID:
<AANLkTikEmaMAkisO2Mbcw_R+g6dnLvig8cJzbUHjWkZL@anonymised.com>
Content-Type: text/plain; charset=“utf-8”
Hi, mailing list,
there is problem with org.geoserver.rest.BeanResourceFinder.
Restlet resources are not designed to be thread-safe (response, request are
stored in fields… ), but BeanResourceFinder method findTarget:
public Resource findTarget(Request request, Response response){
Resource res = (Resource)
applicationContext.getBean(getBeanToFind());
res.init(getContext(), request, response);
return res;
}
returns the same Resource instance to concurrent threads, well, Spring
returns the same instance,
workaround is to tell Spring to give different instances, that can be done
with scope=“prototype” like:
But it would be nice if it could be fixed in code not in the Spring
configuration file, because users may forget to add scope attribute, which
may lead to real time errors.
Thank you,
M?rti?? Linde
-------------- next part --------------
An HTML attachment was scrubbed…
Message: 4
Date: Fri, 15 Oct 2010 08:10:01 -0400
From: Eli Miller <emiller@anonymised.com>
Subject: Re: [Geoserver-devel] RFC: Parametric SQL View Enhancement
Proposal (and patch)
To: Rob Atkinson <robatkinson101@anonymised.com>
Cc: geoserver-devel@lists.sourceforge.net
Message-ID:
<AANLkTik8f_BJViy_PbrXsuX-37HdT3cAUPhFmmPCrnYP@anonymised.com>
Content-Type: text/plain; charset=“windows-1252”
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 <robatkinson101@anonymised.com>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 <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.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: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:1The 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[, …]).- 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.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.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.
- The output for GetFeatureInfo is incomplete if INFO_FORMAT is not
specified (only the first feature is output).- 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
Geoserver-devel@lists.sourceforge.net
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.
-------------- 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 36