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
instead 
For 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?
Q2. How do I access the service parameters that have been passed to the
AbstractService?
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
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?
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?
Thanks again,
Jerry.
-----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" WFS
Hi 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+Http
So 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.