[Geoserver-devel] GSIP 61 - WFS 2.0

GeoServer GeoServer Developer
1

Hi all,

I have been working trying to organize the wfs 2.0 work into a proposal ready state and here is the result:

http://geoserver.org/display/GEOS/GSIP+61±+WFS+2.0

Patches linked from the proposal. Thoughts and feedback welcome.

One remaining thing I failed to do was to run the wfsv tests. I tried setting up the database and the fixture locally to run the tests but still failed. It seems LegacyDbmsTestData.getDatabaseConnection() is unable to get the underlying connection from the datastore… not sure if the structure has changed recently or not… any thoughts/guidance there would be appreciated.

Thanks.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

On Fri, Oct 14, 2011 at 7:37 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I have been working trying to organize the wfs 2.0 work into a proposal ready state and here is the result:
http://geoserver.org/display/GEOS/GSIP+61+-+WFS+2.0
Patches linked from the proposal. Thoughts and feedback welcome.

Massive. Let me start with something easy, reading the proposal and
discussing it (patches...later) :slight_smile:

* Services Architecture -> ok
* Request Object Model -> cool
* Filter 2.0 -> yep
* Paging -> cool, two observations (not blocking or anything, just
related stuff that might be of interest)
The work I did on trunk for the aggregating data store actually allows
any store to implement sorting,
and subclasses of content data store get that for free.
The other interesting bit is that the code doing merge-sort can dump
features on the disk quickly
enough (using other serialization technologies it could be made faster
though), this could be used
to actually dump an entire result set on disk for real stable paging.
It is just an idea, and if implemented, imho it should be something
that the administrator has to
enable explicitly, setting a max feature for WFS carefully in
accordance to avoid killing the
disk in the process.

* Joins -> nice, one question here
Is the client able to know in advance which two types can be joined?
Does the standard foresee the option of seletively supporting joins
only on some feature types?

* Stored query -> cool (/me dreams of stored ECQL)

* Soap -> ok, with questions
Say a response is not XML and does not implement the SOAPAwareResponse
interface... what happens?
Also, do we have everything soap-ified by default? Like, is WCS/WPS
going to receive
the SOAP magic as well? Or do we have to implement something specific?
Another question is... where are the WSDL coming from?

* Extended operators -> ok (we are going to have a ton of extended ops
out of the box!)

* Backwards compatibility -> yep, the usual drill. Meh, one day we
should allow the administrator
  to choose what the default version of each protocol is.

Tomorrow I'll try to have a look at the patches too :slight_smile:

One remaining thing I failed to do was to run the wfsv tests. I tried setting up the database and the fixture locally to run the tests but still failed. It seems LegacyDbmsTestData.getDatabaseConnection() is unable to get the underlying connection from the datastore... not sure if the structure has changed recently or not... any thoughts/guidance there would be appreciated.

I honestly would not know. I'm inclined to just drop WFSV back in
community land, what do you think?
Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

Thanks for the review of the proposal Andrea. Comments inline.

On Sat, Oct 15, 2011 at 4:45 AM, Andrea Aime <andrea.aime@anonymised.com…> wrote:

On Fri, Oct 14, 2011 at 7:37 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I have been working trying to organize the wfs 2.0 work into a proposal ready state and here is the result:
http://geoserver.org/display/GEOS/GSIP+61±+WFS+2.0
Patches linked from the proposal. Thoughts and feedback welcome.

Massive. Let me start with something easy, reading the proposal and
discussing it (patches…later) :slight_smile:

  • Services Architecture → ok
  • Request Object Model → cool
  • Filter 2.0 → yep
  • Paging → cool, two observations (not blocking or anything, just
    related stuff that might be of interest)
    The work I did on trunk for the aggregating data store actually allows
    any store to implement sorting,
    and subclasses of content data store get that for free.
    The other interesting bit is that the code doing merge-sort can dump
    features on the disk quickly
    enough (using other serialization technologies it could be made faster
    though), this could be used
    to actually dump an entire result set on disk for real stable paging.
    It is just an idea, and if implemented, imho it should be something
    that the administrator has to
    enable explicitly, setting a max feature for WFS carefully in
    accordance to avoid killing the
    disk in the process.

Yeah I think this would be really great to have sorting across the board. Also nice to have everything extending from ContentDataStore :slight_smile:

  • Joins → nice, one question here
    Is the client able to know in advance which two types can be joined?
    Does the standard foresee the option of seletively supporting joins
    only on some feature types?

Unfortunately not… the capabilities doc is only able to advertise support for paging at a global level. I guess with the ability to do sorting for any data source we do introduce the possibility of doing joins (or a limited form of them) across the board as well. But yeah… I think users will simply to have to deal with the exception report now, which should say something like “store x does not support joins”.

  • Stored query → cool (/me dreams of stored ECQL)

Indeed… or in the scripting language of your choice.

  • Soap → ok, with questions
    Say a response is not XML and does not implement the SOAPAwareResponse
    interface… what happens?
    Also, do we have everything soap-ified by default? Like, is WCS/WPS
    going to receive
    the SOAP magic as well? Or do we have to implement something specific?
    Another question is… where are the WSDL coming from?

For responses that return non xml the payload will be encoded in the midst of the soap document… depending on the encoding this could possibly return an invalid document. Regardless it would undoubtedly cause an failure on the client.

By default yes, anything run through the ows dispatcher has the ability to do SOAP. We may want to add to the service config the ability to turn SOAP support off for a particular service. Shouldn’t be too hard. And actually it seems like some services don’t support it at all like WMS… so probably a good idea.

Nothing WSDL related has been done. To be honest we did the absolute minimum to support SOAP for WFS and the client did not mandate us to implement the WSDL for the service. The WSDL is published in static files along with the xml schemas… so we could simply just download them, make them http accessible and call it a day, like we do for the XML schemas.

Also checking some of the other specifications that support SOAP not all require WSDL bindings… for instance WCS 2.0 seems to have this as “future work”.

  • Extended operators → ok (we are going to have a ton of extended ops
    out of the box!)

  • Backwards compatibility → yep, the usual drill. Meh, one day we
    should allow the administrator
    to choose what the default version of each protocol is.

Tomorrow I’ll try to have a look at the patches too :slight_smile:

One remaining thing I failed to do was to run the wfsv tests. I tried setting up the database and the fixture locally to run the tests but still failed. It seems LegacyDbmsTestData.getDatabaseConnection() is unable to get the underlying connection from the datastore… not sure if the structure has changed recently or not… any thoughts/guidance there would be appreciated.

I honestly would not know. I’m inclined to just drop WFSV back in
community land, what do you think?

Yeah I think I agree. Unless I am mistaken wfsv was sort of an experiment and not something that sees active use in production. Again I could be wrong about that. Anyways, I guess it boils down to someone willing to maintain it… at this point it seems probably not, especially given the usage of the module.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.