Bug report #19195
WMS layer loaded in incorrect CRS when using drag and drop from Browser panel
| 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
[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 almost 6 years ago
- Assignee set to Alessandro Pasotti
#2
Updated by Alessandro Pasotti almost 6 years ago
- Pull Request or Patch supplied changed from No to Yes
- Status changed from Open to In Progress
#3 Updated by Anonymous almost 6 years ago
- % Done changed from 0 to 100
- Status changed from In Progress to Closed
Applied in changeset qgis|cb91176edd1a51dca7d4ec40f529ed6daec48382.
#4
Updated by Tilman Brock-Hesse about 5 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 about 5 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 about 5 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 about 5 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.