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

WFS: DescribeFeatureType: typename or typenames in KVP encoding? #31

Closed
thijsbrentjens opened this Issue Mar 4, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@thijsbrentjens
Copy link
Member

thijsbrentjens commented Mar 4, 2016

WFS 2.0.0 specifies for DescribeFeatureType KVP encoding to use the parameter name "typenames", see section 9.2.4.1. Although there is also a table using "typename". Which should be used in the requests?

Edit: in WFS 2.0.2 this also occurs: http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#149

@thijsbrentjens

This comment has been minimized.

Copy link
Member Author

thijsbrentjens commented Mar 4, 2016

This is relevant for many implementations in NL (from PDOK for example), where the parameter is only accepted if the keyword "typename" is used. When using "typenames", the DescribeFeatureType request returns schemas for ALL featuretypes

@cportele

This comment has been minimized.

Copy link
Collaborator

cportele commented Mar 4, 2016

@thijsbrentjens
TYPENAMES is correct: "For KVP-encoded requests the typeNames parameter shall be encoded using the TYPENAMES keyword", see http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#149.

The use of TYPENAME in table 15 is an error that needs to be fixed in the WFS standard (@pvretano). Probably this is a leftover from WFS 1.x, where it was TYPENAME.

@thijsbrentjens

This comment has been minimized.

Copy link
Member Author

thijsbrentjens commented Mar 4, 2016

Okay, clear. Nasty detail for some implementations I guess.

For now: I can imagine we will have discussions on this when testing: both are still found in the standard.
So I tested sing both (typename=&typenames=) now, to use in a DescribeFeatureType request. This works (and avoids for a service offering more than 500 featuretypes that we will retrieve all schemas every request). It is a bit more relaxed than it should be, what do you think about this?

(I'll create a pull request, you'll see the changes)

@cportele

This comment has been minimized.

Copy link
Collaborator

cportele commented Mar 4, 2016

Yes, that makes sense as we have both parameter names in the standard at the moment.

@thijsbrentjens

This comment has been minimized.

Copy link
Member Author

thijsbrentjens commented Mar 4, 2016

I'll merge the pull request then.

thijsbrentjens added a commit that referenced this issue Mar 4, 2016

Merge pull request #32 from Geonovum/wfs-describefeaturetype-typenames
fix #31: allow using both typename and typenames in DescribeFeatureTy…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment