On Mon, Apr 8, 2013 at 10:54 PM, Phil Scadden <p.scadden@anonymised.com> wrote:
> Simple, you don't.
Okay, I will put a particular use-case to you then. Suppose you have an
database file with rather ugly set of attributes. (ie highly normalised
or coded attributes). In an ideal world you would construct a view that
delivers human-readable form and serve that from geoserver. However, if
you dont have admin access to its particular database schema, then you
are stuck with what you have. At the moment you can construct FTL or
make readable on the client. The XSLT would allow for an alternative
through say GML->JSON or GML->HTML. However, you might have two
use-cases for the same data - one where you want it pretty (say info in
a popup) and another where you want the raw attributes because you are
offering editing of attributes and must pass back the proper data. If
you could specify which transformer to use, then you have the
possibility of a GML-> pretty GML for popups and plain one for editing.
Using XSLT the way you suggest, to alter the schema seen by users,
would likely bring us to a world of pain, as it's not just a matter of
transforming the generated GML:
* you have to transform DescribeFeatureType as well
* you have to transform back all the incoming filters, referring to the
properties you're exposing, back to the native ones
* you have to take all the GET/KVP requests, and turn them into XML
so that they can also be back-transformed
* the same would have to happen with the tight integration we have with
WPS (when using the local WFS as a data source)
Generally speaking, using XSLT for the task is bad because the
transformation
happens in a too specific place (WFS only) and too much on the outside
(against XML as opposed to against the data).
I have written a solution for your use case, it's the "transform" module in
GeoTools,
which can apply transformations at the data level, go back and forth,
transform
filters, and retain the ability to do writes if the store knows how to
invert your
transformations (at this time, this is true only for attribute renames):
https://github.com/geotools/geotools/tree/master/modules/unsupported/transform
The issue is that the above needs to be wired up with GeoServer, and that's
not
2 hours work. This is what is needed:
* writing a GUI to allow setting up the attribute renames/type changes/CQL
expressions to
perform the transformation
* store the configuration in XML
* apply the transformations on the fly in ResourcePool, we likely need to
open an extension
point to do that
I'd be very happy to work on it, but it needs a little funding so that the
devs can work on it
during working hours instead of doing the n-th thing in their space time.
Cheers
Andrea
--
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
