Hey Andrea, +1 on the community module but some feedback inline as well for
things to think about.

On Tue, Oct 2, 2012 at 4:34 AM, Andrea Aime <[email protected]>wrote:

> Hi all,
> I want to propose a new community module, a customizable WFS output format
> which
> will leverage XSLT to transform GML2/3 outputs into any text output.
>
> Cool. One thing to consider is how the folks did this for app-schema. If
you look for instance at GML3OutputFormat you will see support for an xslt
transformation. In that case it is very specific but it would be good to
think about how to do this in a general way that would be supported by the
core wfs module.

The configuration will be XML based, one configuration file
> file stored in $GEOSERVER_DATA_DIR/wfs-xslt/configuration.xml, with a
> format as follows:
>
> Can we throw this under a directory named "wfs" to avoid proliferating new
directories at the top level, eventually having it customizable per
workspace as well (although i understand this can be put off as a
future improvement).

It would also be good to have this customizable on a layer by layer basis.
Which i would think is kind of important for general use right? Just
thinking out loud but how often the case that you want a strctly general
transform to be applied to all GML output, i would think tweaking the
output of a single layer would make more sense. Although I guess this could
also be done with a global file and just select the types you want.

<xsltConfiguration>
>   <formats>
>       <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>
>       <outputFormat>text/plain</outputFormat>
>       <fileExtension>txt</fileExtension>
>       <xslt>/path/to/the/xslt/file</xslt>
>   </format>
>   <format>
>      ...
>   </format>
>   ...
> </xsltConfiguration>
>
> The term "transform" might make more sense than configuration.

The format will not have a configuration GUI for the time being, but will
> be accompanied
> by a REST configuration extension mimicking the configuration file
> structure:
>
> /rest/wfs-xslt/formats/<format>.xml
>
> Again I think this shoudl fall under the existing /services/wfs endpoint.
I would think something like:

/rest/services/wfs/transforms/...

ANd if supported on a layer by layer basis i think also available under the
layer endpoint as well.

/rest/workspaces/.../featureTypes/<featureType>/transforms/...


> where formats would list all the available formats, and format would allow
> the manipulation
> of each single one. The editing will be as usual, POST on formats to
> create a new format,
> PUT/DELETE on the single format to alter/remove
>
> I plan to add enough testing to push it to extension level in a short-ish
> time, the idea
> of having a XSLT based output format was requested already some times on
> the user list
> and by voice during code sprints (notably GeoNetwork people asked a few
> times about this).
> The idea is to have this land on the 2.2.x series as well once it matures
> enough.
>
> Cool, agreed this will be a very powerful feature that is well received. I
do think it is worth thinking about maybe a tighter integration with the
core wfs/restconfig/etc... modules rather than as an add on.



> Of course documentation will be also added.
>
> How does it sound?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.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
>
> -------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to