Justin,
Thanks for your ongoing advice.
The Feature class already produces the correct "KvpReader" and
"XmlReader" to read a request.
How do I obtain (or construct) the "WFS" parameter needed for the
Feature constructor?
The workflow goes "service" -> "kvp/xml reader" -> "request object" ->
"response".
Ok, but presumably this workflow is achieved in some template method
that calls methods of the Feature class. Hence, it seems to me I need
something like:
////////////////////////////////////////////////////
class TransformFeature extends WFService
{
public TransformFeature(WFS wfs) {
super("SayHello", wfs);
}
protected Response getResponseHandler() {
return new TransformFeatureResponse();
}
protected KvpRequestReader getKvpReader( Map params) {
return new GetFeatureKvpReader(params, this);
}
protected XmlRequestReader getXmlRequestReader() {
return new GetFeatureXmlReader(this);
}
}
////////////////////////////////////////////////////
Where TransformFeatureResponse does the work of connecting to the
external WFS client, transforming the features and returning the GML.
Does this make sense?
Jerry.
-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: 29 March 2007 18:08
To: Swan Jerry
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] [Geotools-gt2-users] "Transforming" WFS
Hi Jerry,
Good questions!! Answers inline.
Swan Jerry wrote:
Justin,
give these docs a read and hit be back with any questions you might
have.
Is it possible that we might discuss the required object interactions
in more detail? It might be, for example, that by substituting
FeatureResponse (rather than a FeatureCollection) in the following
that most of the pieces of the puzzle would fall into place, but
that's not apparent to me at present.Please feel free just to point me at any documentation I've missed
insteadFor the time being, let's simplify things by restricting the
discussion to a "GetFeature" request.My understanding is that I should write some AbstractService subclass.
Q1. Would it be of benefit to subclass
org.vfny.geoserver.wfs.servlets.Feature, or should I stick with
subclassing AbstractService?
Probably. Since you are not extending the protocol in any way ( or not
that i know of ) the request parameters will stay the same. The Feature
class already produces the correct "KvpReader" and "XmlReader" to read a
request. Although if you went straight subclass of AbstractService you
could probably resuse this.
Q2. How do I access the service parameters that have been passed to
the AbstractService?
The workflow goes "service" -> "kvp/xml reader" -> "request object" ->
"response". The request object is a java bean which captures all the
parameters of a request. This request object is passed to the response
of a particular request. Look at FeatureResponse.execute for example.
The AbstractService subclass then passes these service parameters to
the
external server (e.g.
via something like org.geotools.demo.example.WFSClient), presumably
obtaining a FeatureCollection as a result.Recall that your suggestion was that the transformations should be
achieved by implementing a custom output format which would apply
whatever transformations were required.Assuming that the "custom output format" approach is the way to go, I
guess the intent is to follow the example given in:
http://docs.codehaus.org/display/GEOSDOC/Create+your+own+Output+Format
Yup.
However, it seems to me that (in order to perform these
transformations)
the custom subclass of FeatureResponseDelegate would then need to be
coupled to the AbstractService subclass (in order to access attributes
representing the FeatureCollection and\or the service parameters).Q3. Hence, if we were to stipulate that the output format was actually
still GML in practice, are there any significant merits in the "custom
output format" approach, rather than directly transforming the
FeatureCollection via the AbstractService class and then encoding it
as
GML?
I agree. What you could do is extend GML2FeatureResponseDelegate and
extend the "prepare" method to do the transformation on the feature
collection itself. This would save you having to deal with any of the
gml encoding code, which is not all that nice imho.
Q4. Assuming that there are no other merits in the "custom output
format" approach, presumably I should encode the transformed
FeatureCollection into GML from within the AbstractService class and
output the result to the HttpServletResponse output stream
(analagously
to the "HelloWorld" plugin example). If so, is
GML2FeatureResponseDelegate the best means of achieving this encoding?
Yup, its the code that handles encoding feature collections as gml.
Encoding / parsing gml is a tough problem imho. Reusing any code that
exists would probably be a good idea.
Thanks again,
Jerry.
-Justin
-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: 05 March 2007 15:34
To: Swan Jerry
Cc: 'geoserver-devel@lists.sourceforge.net'
Subject: Re: [Geotools-gt2-users] "Transforming" WFSHi Jerry,
Glad to be of help. Comments inline.
Could you implement your system as a custom output format in
geoserverthat would take the
features, do a bunch of transformations on their geometries, and
then
give some new features
back to the client?
Since I may also want to transform the non-geometric aspects of the
XML schema, this might be a bit too restrictive...Well actually it wouldn't be restricted to just geometries. You would
have 100% control of how the xml is generated. Basically an output
format ( in geotools / geoserver speak here ) gets a feature
collection,
which is the collection of data matching a request. The output format
has full control over this.Recall that (in implementation terms) the adaptor has client and
server
components: the server is connected (via http) to the external client
and the client is connected (again, via http) to the external
server.
The issue is then what geoserver\geotools functionality can best
implement the client and server components and how best to couple
them
together.
So the more I think about it and your requirement to be a middle layer
between existing client and server the more it sounds like WPS.One possible scheme might be as follows:
Presumably there a server API available (in Geoserver?) that pulls in
data from some datasource and marshalls the geometry into XML in
response to a feature request.Yup, its the output format api described above.
A custom datasource could use something like
org.geotools.demo.example.WFSClient (which provides a simple example
of unmarshalling XML into geometry).This (together with some polymorphic hooks for the transformation)
should suffice for the geometry, but the above scheme would also need
separate communication between the client and server components for
the non-geometric aspects of schema transformation.What I'm hoping for is a broad explanation that identifies the
appropriate API level for communication between the client and server
sides in order to tie these two things together into a single
component.Ok, so just to make sure I understand the requirements. What you need
is:A special service which talks wfs. This service delegates to another
existing wfs to grab some data. The service then applies some
transformation to the data ( geometric and non-geometric attributes ).
The service then returns that result to the calling client.Apologies if i am missing any key points.
So I think you are on the right track by looking at the WFS demo
client
code. This is the first piece of the puzzle as it allows you to fetch
the data,The next piece is for lack of a better term, your special
transformation
engine, which I imagine will be some api that you come up with for
performing features. Ideally it sounds like you want to make the api
plugin based.The last piece is where GeoServer comes in and allows you to bundle
the
above components into a web service. You can define the adaptor as its
own service, which sit between the external client and server. The api
for defining new services in GeoServer is relatively new and available
only on the trunk development branch. Here are some preliminary docs,
i
apologize, some parts are incomplete, but they are good enough to give
you the general idea of what defining a new custom service will look
like.http://docs.codehaus.org/display/GEOSDOC/3+A+Simple+PlugIn
http://docs.codehaus.org/display/GEOSDOC/2+HttpSo if I have understood the scope of your problem, give these docs a
read and hit be back with any questions you might have.
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.