On Thu, May 15, 2014 at 11:09 AM, Sampo Savolainen <
[email protected]> wrote:
> Hi,
>
> I've successfully merged my and Niels's work. It was surprisingly easy
> with only one minor conflict. I noticed that you have discussed having a
> shared branch for me, Niels and Reni. This would be wise indeed as the
> danger of us either working on the same thing or against each other is
> pretty big.
>
> The merged is at
> https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq
>
> Do note however that my work stretches out to the geoserver codebase as
> well, though there's not too many changes there to date. (
> https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)
>
> We need to figure out who's responsible for the wfs-ng module in GS.
> Niels, Reni, have you built wfs-ng as a GS module yet? I've built one, but
> I made the mistake of naming it an "extension" instead of "community" so I
> probably have to at least redo that part.
>
>
> The main goal of my work is pretty much done. There are two things that
> need to be discussed though:
>
> 1. Stored query "feature type"
>
> As discussed when I started this feature, the stored queries are currently
> exposed as special feature types provided by the data source. There's a
> naming convention which then can be used to separate true feature types
> from stored queries. Is this still fine with everyone involved?
>
>
> https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43
>
>
> 2. Configuration UI
>
> I haven't written an UI to configure the stored query parameter mappings.
> As cascading stored queries are quite rare, do you think such a GUI is
> needed? Maybe writing clear documentation on how the featuretype.xml needs
> to be amended would be fine?
>
> The configuration is required if the feature type should do dynamic
> mapping of query attributes (bbox, crs, etc) to stored query parameters.
> This configuration is not required for the SQL ViewParams to be mapped as
> stored query parameters. That happens automatically.
>
Sampo, GeoServer wise there is an extra snatch.
GeoServer core currently depends on the wfs module in order to support WMS
feature portrayal services,
that is, requests where the indication of the data to be painted is
provided in the request by giving
a link to a capabilities document and a feature type.
I see a few ways forward:
1) drop feature portrayal support and make wfs a community module
2) make fetaure portrayal behavior pluggable, and implement it in a wfs
extension/community module or another module that would depend on it
3) replace the current wfs in core, and have core depend on wfs-ng instead
1) has backwards compatibility issues for the functionality we lose, and
whoever is cascading a WFS today would have to add a new extension module
when upgrading geoserver
2) is hard to implement
3) is risky and requires a GSIP, but if we do it only on trunk it's (imho)
probably the best path forward
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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
-------------------------------------------------------
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
