-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
misc qgis server wfs getFeature fixes when crs is defined as a ogc urn #58355
Conversation
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
The `srsName` used in `QgsWfsGetFeature::startGetFeature` can be defined with the `urn:ogc:def:crs:EPSG::X` syntax. In that case, the destination crs is not valid because it is created with the default `QgsCoordinateReferenceSystem` constructor which does not handle this syntax. Therefore, in that case, the requested transformation fails and the envelope coordinates are always in the input crs (the layer one). This issue is fixed by using `QgsCoordinateReferenceSystem::setDestinationCrs` which handles the ogc urn syntax. The test suite already covers the `urn:ogc:def:crs:EPSG::X` syntax case. However, this issue is not detected because the requested output crs is the same as the input one.
The axis inversion needs to be checked on the output crs, not the input one. The existing test does not detect this issue because the requested output crs is the same as the input one. To cover this case, a new test with a output crs different from the input one is added.
This makes it easier to understand its usage.
There are 2 different parameters to check to define the output crs: - the request parameter (`SRSNAME` from the request) - the query crs parameter For a `GET` request, if `SRSNAME` is set, both parameters are set and equal. For a `POST` request, only the query parameter is set if defined. In `writeGetFeature()`, the `outputCrs` correctly takes into account the query parameter. However, this is not the case for the output srs name (`srsName`) which only takes into account the query CRS as an auth id. Therefore, the output srsName will always be defined as an authid even if the parameter is an ogc urn. This issue is fixed by first computing the output srs name (`outputSrsName`) by taking into account the query and the query parameters. Then, this name is used to compute `outputCrs`.
fca15d1
to
c492df9
Compare
Description
This fixes 3 issues when the crs parameter is defined with the a ogc urn syntax. From the commit messages:
Fix outputCrs in startGetFeature if defined as ogc urn
Properly check axis inversion in startGetFeature
Properly handle ogc urns in post requests
cc @elpaso @troopa81