Hi Andrea & Jody,
Thanks for your comments. My next steps are to dive through all the
relevant parts of the Geotools / GeoServer code base and figure out a more
detailed plan for the work. At which point would you like to see a GSIP?
Regarding targeting only stored queries: Stored query support is vital for
the use case at FMI, so that's the minimum level we need to target. That
means that I will work on the full WFS 2.0 client only after we've
satisfied the demands for the use case at hand. But knowing that this is a
key limiting factor to having this work included in mainline GeoServer is
very important for us. Thanks for the heads up Andrea! We will definitely
raise the priority of a more complete WFS 2.0 client support.
How complete the WFS 2.0 client would need to be to be "automatically"
included? Is read-only sufficient? As we're not doing anything related to
transactional requests, fitting transactional client support would be
stretching the budget, time frame and scope.
Sampo
On Fri, Mar 14, 2014 at 3:24 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Mar 14, 2014 at 11:49 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Hi,
>>
>> I've been contracted by the Finnish Meteorological Institute to write a
>> cascaded WFS 2.0 data store for GeoServer. My background is deep in
>> software development, working mainly on networked systems using Java. I
>> have previous experience with GeoServer (a few bug fixes, a proprietary
>> dispatcher implementation, server setup & maintenance) and I also have
>> experience with WFS. Latter part comes from Spatineo, where I've
>> implemented the backend for our WFS monitoring.
>>
>> The actual use case we're solving is visualizing data supplied by a
>> separate WFS 2.0 server. The visualization will be done using GeoServer's
>> WMS facilities. We need 2.0 support because the backend WFS server offers
>> the data as stored queries. This is where our efforts will be focused on:
>> Stored Queries returning responses in Simple Features Profile.
>>
>>
> Ok, so your focus will be strictly to write one store that, while using
> the WFS 2.0 protocol, is not a general one, but one specifically targeted
> to stored queries?
>
>
>
>> One of the goals of this project is to create an implementation which has
>> enough general appeal to be accepted into the official builds of GeoServer,
>> or perhaps as one extension in the official collection.
>>
>
> If the work extends the existing WFS store it would become part of the
> GeoServer distribution automatically, but to go there, it would have to be
> a generic WFS client, not one specific
> to stored queries.
> If it's a stored query specific one, it will probably be up to you to
> become its long term maintainer in order to raise it to extension status
> (which, indeed, requires a long term
> maintainer, along with other requirements such as tests, docs, ip checks
> and at least 3 users)
>
>
>>
>> I would love to get some feedback on this project. Especially regarding
>> what requirements the GeoServer developer community has for this work to
>> get accepted into official releases. Also any ideas on how to approach this
>> task are gladly accepted.
>>
>> I've identified the following places that I need to work on:
>>
>> Geotools needs a WFS 2.0 module (
>> https://github.com/geotools/geotools/tree/master/modules/unsupported/wfs)
>>
>
> Yes, that module is a generic WFS clients, the WFS 1.0 portion does
> read/write, the WFS 1.1 portion is read only.
>
>
>>
>> GeoServer needs relevant configuration and possibly UI elements to set up
>> cascading WFS 2.0 data stores and creating layers from those datasources.
>>
>
> If the client is generic all that is needed are the connection parameters
> in the factory, but if you need to setup the configuration
> for the stored queries, indeed a custom panel will be required.
>
>
>>
>> To support parameters for the stored queries, the WMS dimensions need to
>> be leveraged to pass on any dimension values to the WFS 2.0 data store.
>>
>
> Ah, those go down as filters... and I guess this might be a problem? With
> stored queries you are pretty much stuck with whatever
> is in the query template, cannot pass more filters down (and you need to
> understand how the generic filter GeoServer will give you
> is mapped in the stored query, which means, understanding the stored query
> itself...). Any other filter will have to be run client side
> (which is of course inefficient...)
>
>
>>
>> I will initially be writing on this on top of 2.5.x, as that is the
>> expected version the first production system will run.
>>
>
> New features have to go to master first, so make sure your pull requests
> target that branch, even if you're developing
> against another one
>
> 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
>
> -------------------------------------------------------
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
