Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to WFS 2.0.0 #194

Closed
Roel opened this issue Sep 6, 2019 · 6 comments · Fixed by #358
Closed

Switch to WFS 2.0.0 #194

Roel opened this issue Sep 6, 2019 · 6 comments · Fixed by #358
Labels
enhancement upstream Relates to and/or depends on upstream libraries
Milestone

Comments

@Roel
Copy link
Member

Roel commented Sep 6, 2019

At some point we might want to switch from current WFS 1.1.0 to WFS 2.0.0.

This would for instance allow to:

  • get the maximum feature limit per GetFeature requests (i.e. 10000) from the capabilities of the service instead of hardcoding this in pydov
  • work around this limit entirely by using paged requests (which is not supported in WFS 1.1.0)
@pjhaest
Copy link
Collaborator

pjhaest commented Sep 17, 2019

👍

@Roel
Copy link
Member Author

Roel commented Jan 29, 2020

I think we can/need to implement this in different stages:

  • add WFS 2.0.0 GetFeature support via POST in OWSLib (although we could also implement this in pydov as we do now for WFS 1.1.0)

  • add support in OWSLib for FES 2.0 filters, a.o. this means

  • add support for GML3.2 in the spatial filtering

    • I can look into extending this in pydov, so we can switch once the first two improvements have landed in OWSLib
    • in time we can contribute the spatial filtering with GML3.2 (for WFS 2.0.0) to OWSLib too

Apart from upgrading the stack to WFS 2.0.0, I think it still makes sense to contribute support for WFS 1.1.0 GetFeature via POST as well as the spatial filters for WFS 1.1.0 to OWSLib. I'll create a separate issue for this.

@stijnvanhoey
Copy link
Collaborator

I'm adding the first PR asap.

@johanvdw
Copy link
Collaborator

FYI, I have my code to start working on FES filters here:
https://github.com/johanvdw/OWSLib/tree/fes_test

It does not work yet, but if anyone wants to continue working on it, you may have a look.

@jorisvandenbossche
Copy link
Contributor

I pushed a branch (and opened #242 from that to more easily see it) with the changes that I made to pydov while testing out WFS 2.0 in pydov.

Based on that experiment, my impression was that it would not be very hard to already switch to WFS 2.0 in pydov if that would be desired. The main blocker is FES 2.0 support in OWSLib, but for now, that could also be worked around by "fixing" the xml for the filters generated by OWSLib (switching ofc -> fes namespace, replacing PropertyValue with ValueReference).

For properly improving OWSLib to support FES 2.0, maybe the first step is also to open an issue on the OWSLib side? I didn't directly find one (they have an old one for the spatial filters: geopython/OWSLib#128). Because I suppose there are several ways to tackle this: eg adding a version keyword in the toXML as @johanvdw did (or in the main object constructor), or having a separate fes200.py file (similarly like they have wfs100.py, wfs110.py, wfs200.py)

@johanvdw
Copy link
Collaborator

FYI, my goal was having a minimal working implementation (ie, not all possible filters, just one) to gain some insight before opening an issue.

@Roel Roel added the upstream Relates to and/or depends on upstream libraries label Jan 30, 2020
@Roel Roel added this to the v3.0.0 milestone Aug 16, 2022
@Roel Roel closed this as completed in #358 Sep 20, 2022
@Roel Roel mentioned this issue Mar 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement upstream Relates to and/or depends on upstream libraries
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants