Add srsname to wfs200.py getfeature GET request

[lpartington]

WebFeatureService_2_0_0.getfeature() is missing an srsName argument. This issue has been reported previously in #910, #905, and #682. This prevents features being retrieved with a non-default crs when using WFS 2.0.0. srsName is supported by WebFeatureService_1_1_0.getfeature() and WebFeatureService_1_0_0.getfeature(). This seems to be an oversight as srsname is a valid KVP ('key value pair') parameter - see OGC WFS 2.0.2 specification https://portal.ogc.org/files/?artifact_id=39967 Sections 7.9.2.3 and 7.9.2.4.4.

Changes in this PR:

• Add srsname arg to WebFeatureService_2_0_0.getfeature() for GET requests
• Add srsname arg to WebFeatureService_.getGETGetFeatureRequest() (which is called by getfeature)

Note that srsname hasn't been added for POST requests. This is actually consistent with the implementation of getfeature() in wfs110.py, where srsname can be specified for GET requests but not POST requests. It seems this is likely to be unintentional, but fixing up POST requests across all WFS versions is better done in a separate PR.

A suggestion for future improvement would be to support kwargs in getfeature(), so that arbitrary query parameters can be supported without having to explicitly declare them in the function argument list. These parameters would merely be added verbatim to the request's query params. However, this is beyond the scope of the current issue.

[geographika]

@lpartington - would you be able to add a test for this? Some basic tests of getGETGetFeatureRequest with srsName should be fine.

[coveralls]

coverage: 60.203% (+0.08%) from 60.128%
when pulling d14d447 on SearcherSeismicGeodata:wfs_getfeature_srs
into d4e7080 on geopython:master.

[lpartington]

No problem. I will look at it tomorrow.

…

On Mon, 7 Oct 2024 at 15:48, Seth G ***@***.***> wrote: @lpartington <https://github.com/lpartington> - would you be able to add a test for this? Some basic tests of getGETGetFeatureRequest with srsName should be fine. — Reply to this email directly, view it on GitHub <#945 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZUOOIBV3W2I26GZAXXIC3Z2I4D3AVCNFSM6AAAAABPCSW4Z6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWGE3TANZTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lpartington]

I added test case test_srsname_wfs_200 in test_wfs_generic.py, using the same approach as the wfs_100 and wfs_110 cases. However, I noted these issues:

1. most of the cases in test_wfs_generic.py depend on wfs service https://www.sciencebase.gov/catalog/item/53398e51e4b0db25ad10d288, but it appears that sciencebase services don't currently work. In all examples I tried, an ows:ExceptionReport was returned with

<ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows https://www.sciencebase.gov:443/catalogMaps/schemas/ows/1.0.0/owsExceptionReport.xsd">
<script/>
    <ows:Exception exceptionCode="NoApplicableCode">
        <ows:ExceptionText>java.lang.NoClassDefFoundError: Lorg/eclipse/core/resources/IWorkspaceRoot; Lorg/eclipse/core/resources/IWorkspaceRoot; org.eclipse.core.resources.IWorkspaceRoot</ows:ExceptionText>
    </ows:Exception>
</ows:ExceptionReport>

The WMS services are also not working (but returning a slightly different ExceptionReport).

2. Due to the above, I have changed all of the 'online' tests in test_wfs_generic.py to use the service that was used in the test_xmlfilter_wfs_xxx cases - https://services.ga.gov.au/gis/stratunits/ows. All but one of the 'online' cases are now passing.

All of the 'online' cases in test_wfs_generic.py were marked with xfail. I've removed xfail from all cases that are now passing.

3. The test case that is failing is test_srsname_wfs_110. The request for EPSG:99999999 is not raising a ServiceException. It seems that there is an issue with how openUrl and the getfeature implementations are handling errors for WFS 1.1.0.

For the wfs_110 case, the service returns 200 OK with an ows:ExceptionReport body. It looks like the intention of openURL is to catch such errors and raise a ServiceException in the possible_errors code, but this doesn't occur because the Content-Type of the response is "application/xml;charset=utf-8" rather than "application/xml". I wonder if substrings starting with ';' should be removed from the content type prior to the comparison?

Note that the wfs_100 and wfs_200 cases DO raise ServiceException for this EPSG. This is because the service returns 400 Bad Request (it doesn't seem right that the service returns different status codes for the different WFS versions, but it does!) and openUrl raising ServiceException as a result.

4. It is worth mentioning that the GA stratunits feature type doesn't have any geometry, so updated the test_schema_wfs_xxx cases to verify that geometry is None. This doesn't seem ideal; perhaps a different service/feature type should be used that has geometry.

[geographika]

Thanks @lpartington for adding those tests, and taking the time to get the WFS tests working again.
The CI is failing due to coveralls.io issues. If you're able to rebase this against the latest master it may fix it.

+1 from me on merging this in the next week, unless there are any other comments from others.

[geographika]

CI all passing. Thanks @lpartington !