Bug report #19195

WMS layer loaded in incorrect CRS when using drag and drop from Browser panel

Added by Jean-François Bourdon over 6 years ago. Updated almost 6 years ago.

Status:Closed
Priority:Normal
Assignee:Alessandro Pasotti
Category:Web Services clients/WMS
Affected QGIS version:3.0.0 Regression?:No
Operating System:Windows 7 64x Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:27024

Description

When a WMS layer is loaded into the canva using a double-click in the Browser panel, the layer is projected with the project CRS. That's expected. However, when dragging the WMS layer from the Browser panel, the layer seems to be projected using the first defined CRS by the WMS server. I supposed that is not the expected behavior.

The problem is apparent when using this WMS (https://geoegl.msp.gouv.qc.ca/ws/mffpecofor.fcgi?) and adding the layer Produits dérivés du LiDAR -> Modèle relief ombré LiDAR.
The first CRS defined by the server is EPSG:2036 (which is one that should not be used with this data as is doesn't cover the extent of the data) and you will be able to see a shift of several meters if you compare the same layer using both methods to import it.

Associated revisions

Revision cb91176e
Added by Alessandro Pasotti over 6 years ago

[bugfix] Fix double escping of colon in QgsMimeDataUtils

Fixes #19195 - WMS layer loaded in incorrect CRS when using drag and drop from Browser panel

History

#1 Updated by Alessandro Pasotti over 6 years ago

  • Assignee set to Alessandro Pasotti

#2 Updated by Alessandro Pasotti over 6 years ago

  • Pull Request or Patch supplied changed from No to Yes
  • Status changed from Open to In Progress

#3 Updated by Anonymous over 6 years ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Closed

#4 Updated by Tilman Brock-Hesse almost 6 years ago

This seems to be closed in error - the commit has nothing to do with WMS handling and mentiones correcting the title. Maybe some issue numbers got mixed up? The behaviour mentioned is still observable by me (in 3.0.2)!

#5 Updated by Giovanni Manghi almost 6 years ago

Tilman Brock-Hesse wrote:

This seems to be closed in error - the commit has nothing to do with WMS handling and mentiones correcting the title. Maybe some issue numbers got mixed up? The behaviour mentioned is still observable by me (in 3.0.2)!

you must test 3.4.4 anyway, if is still valid there then we can reopen.

#6 Updated by Tilman Brock-Hesse almost 6 years ago

Giovanni Manghi wrote:

Tilman Brock-Hesse wrote:

This seems to be closed in error - the commit has nothing to do with WMS handling and mentiones correcting the title. Maybe some issue numbers got mixed up? The behaviour mentioned is still observable by me (in 3.0.2)!

you must test 3.4.4 anyway, if is still valid there then we can reopen.

Thanks for the hint - 3.4.4 seems unaffected of this issue, so it can stay closed.

I also found commit https://github.com/qgis/QGIS/commit/1bce9cc6feab5af4de97aa4fd40ee339680749a8 which seems to be the commit that fixes this bug and also contains some regex changes. Thanks again for your contributions and sorry for not having tested against a recent QGIS.

#7 Updated by Jean-François Bourdon almost 6 years ago

I'm now using QGIS 3.4.1 and the issue has beeen corrected. I can't say however if the commit has something to do with it or not.

Also available in: Atom PDF