[Feature][WMS] Add crs information in WMS GetFeatureInfo output when it differs from WGS84

[troopa81]

GeoJSON states that CRS should always be OGC:CRS84, but when user requests explicitly a given CRS different from WGS84 on WMS GetFeatureInfo, it's better to expose the output CRS using the old GeoJSON specification format.

Related to a QWC issue, see comment

Funded by Eurométropole de Strasbourg

cc @benoitblanc

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 713b5be)

[pathmapper]

I'm not against this change (it improves the current situation 👍 ), but wonder if it wouldn't be an option to reproject the coordinates to WGS 84 to get RFC 7946 GeoJSON if the request is using a different CRS parameter.

From https://geojson.org/:

RFC 7946 was published in August 2016 and is the new standard specification of the GeoJSON format, replacing the 2008 GeoJSON specification.

It's now more than 7 years since RFC 7946 and there are some tools already complaining if they are provided with a GeoJSON with CRS member, e.g. https://geojsonlint.com or https://geojson.io/:

[troopa81]

I'm not against this change (it improves the current situation 👍 ), but wonder if it wouldn't be an option to reproject the coordinates to WGS 84 to get RFC 7946 GeoJSON if the request is using a different CRS parameter.

You don't want to reproject the coordinates in WGS84 because user requests their GetFeatureInfo result in a given coordinate system (using CRS/SRS parameter) and expect their result in that coordinate system.

It's now more than 7 years since RFC 7946 and there are some tools already complaining if they are provided with a GeoJSON with CRS member, e.g. https://geojsonlint.com/ or https://geojson.io/:

Funny thing with https://geojsonlint.com/ is that he just checks if the root GeoJSON object has a "crs" item. But the GeoJSON spectification allows to have any additionnal members... so actually, the GeoJSON IS valid. If I replace "crs" with "srs" everything is fine.

And If I give the linter coordinates in 3857, it doesn't yell. So what its best:

• Having a GeoJSON in a different CRS and not knowing which one ?
• Having a GeoJSON in a different CRS and advertising its CRS with an old, deprecated format (But still GeoJSON valid) ?

I 'd vote the second one. @elpaso Any opinion on this ?

[elpaso]

I'm not against this change (it improves the current situation 👍 ), but wonder if it wouldn't be an option to reproject the coordinates to WGS 84 to get RFC 7946 GeoJSON if the request is using a different CRS parameter.

You don't want to reproject the coordinates in WGS84 because user requests their GetFeatureInfo result in a given coordinate system (using CRS/SRS parameter) and expect their result in that coordinate system.

It's now more than 7 years since RFC 7946 and there are some tools already complaining if they are provided with a GeoJSON with CRS member, e.g. https://geojsonlint.com/ or https://geojson.io/:

Funny thing with https://geojsonlint.com/ is that he just checks if the root GeoJSON object has a "crs" item. But the GeoJSON spectification allows to have any additionnal members... so actually, the GeoJSON IS valid. If I replace "crs" with "srs" everything is fine.

And If I give the linter coordinates in 3857, it doesn't yell. So what its best:

* Having a GeoJSON in a different CRS and not knowing which one ?

* Having a GeoJSON in a different CRS and advertising its CRS with an old, deprecated format (But still GeoJSON valid) ?

I 'd vote the second one. @elpaso Any opinion on this ?

Well, I don't have a strong opinion: the first option makes sense because the client should know the response CRS (because it asked for it in the first place) but is also true that the server might not be able to honor the request, explicit is better than implicit and having the crs exposed in the response is not a bad idea.

Would this also affetc WFS3/oapif ? I implemented CRS in the response even if it wasn't in RFC 7946 because I thought it was too useful to not to, but the CRS is not currently exposed in the response.

[troopa81]

Would this also affetc WFS3/oapif ? I implemented CRS in the response even if it wasn't in RFC 7946 because I thought it was too useful to not to, but the CRS is not currently exposed in the response.

It only affects WMS/GetFeatureInfo for now, but it could (and maybe should?)

[elpaso]

Would this also affetc WFS3/oapif ? I implemented CRS in the response even if it wasn't in RFC 7946 because I thought it was too useful to not to, but the CRS is not currently exposed in the response.

It only affects WMS/GetFeatureInfo for now, but it could (and maybe should?)

Yeah, probably better to add it there too.

[troopa81]

Yeah, probably better to add it there too.

Done f7d5feb

[troopa81]

unrelated test failure

[github-actions]

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

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[rldhont]

@troopa81 A WFS GetFeature request can also be used to request data in GeoJSON format in a non-EPSG:4326 CRS. As you add toOgcUrn() method, I think the CRS is not added to the GeoJSON provided by WFS GetFeature request. Do you mind to do it to get consistent GeoJSON in QGIS Server ?

[troopa81]

@troopa81 A WFS GetFeature request can also be used to request data in GeoJSON format in a non-EPSG:4326 CRS. As you add toOgcUrn() method, I think the CRS is not added to the GeoJSON provided by WFS GetFeature request. Do you mind to do it to get consistent GeoJSON in QGIS Server ?

I added it in f7d5feb following @elpaso comment

[rldhont]

@troopa81 A WFS GetFeature request can also be used to request data in GeoJSON format in a non-EPSG:4326 CRS. As you add toOgcUrn() method, I think the CRS is not added to the GeoJSON provided by WFS GetFeature request. Do you mind to do it to get consistent GeoJSON in QGIS Server ?

I added it in f7d5feb following @elpaso comment

Sorry I have not seen it. Thanks !

[qgis-bot]

@troopa81

This pull request has been tagged for the changelog.

• The description will be harvested so please provide a "nearly-ready" text for the final changelog
• If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
• If you can, it's better to give credits to your sponsor, see below for different formats.

You can edit the description.

Format available for credits

• Funded by NAME
• Funded by URL
• Funded by NAME URL
• Sponsored by NAME
• Sponsored by URL
• Sponsored by NAME URL

Thank you!