Bug report #11518
Not able to view a mapcache layer exposed in WMS in qgis
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Web Services clients/WMS | ||
| Affected QGIS version: | 2.4.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19788 |
Description
This opendata portal shows temperature data
http://geoegl.msp.gouv.qc.ca/golocmsp/?id=014a3c210f
This layer is a WMS layer whom calls a mapcache layer exposed in WMS. You can see in firebug that request:
http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc.fcgi?EXCEPTIONS=application%2Fvnd.ogc.se_inimage&LAYERS=inspq_temperature_surface&TRANSPARENT=TRUE&NOCACHE=0.5023520144168288&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fpng&SRS=EPSG%3A3857&BBOX=-8193944.5746763,5782748.6769223,-7752291.4253237,5961611.3230777&WIDTH=1444&HEIGHT=585
In qgis 2.4, if I create a WMS connection with this URL http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc.fcgi? and add the layer inspq_temperature_surface, getmap request doesn't work.
It generates a direct call to geoegl.../mapcache.fcgi instead of http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc.fcgi?
/mapcache.fcgi is secured and can only be accessed by gouvouvertqc.fcgi?
Does qgis should call gouvouvertqc.fcgi?
History
#1
Updated by Jukka Rahkonen over 9 years ago
Testing GetCapabilities
http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc.fcgi?service=wms&version=1.3.0&request=getcapabilities
I can't read from GetCapabilities anything that refers to "mapcache.fcgi" and I could not repeat your issue with QGIS 2.0.1 which is the only one I have at hand now. QGIS is using the "gouvouvertqc.fcgi" URL for me. Are you sure that you have not played with the other URL before? I can't imagine how QGIS could ever guess to use the mapcache URL. Or have you contacted service admins meanwhile and made them to change the configuration somehow?
#2
Updated by Steve Toutant over 9 years ago
This http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc.fcgi? WMS is defined by a mapserver mapfile. The temperature layer is a Connection WMS and DATA is the mapcache url. So, I agree to
"I can't imagine how QGIS could ever guess to use the mapcache URL." and "can't read from GetCapabilities anything that refers to "mapcache.fcgi"
I do have access to the apache access_log of this opendata portal. That is how I know that the call made by the web interface of this portal and the call from qgis is different. I do have the same problem in GAIA.
"QGIS is using the "gouvouvertqc.fcgi" URL for me."
How can you see that? I don't see the request in the logs panel.
#3
Updated by Giovanni Manghi over 9 years ago
- Status changed from Open to Feedback
I'm not sure I have undertsand the issue:
the described layer and server works fine for me, it just happen that if the layer if downloaded in certain CRSs it does not show, while others are working ok (example wgs84 does not show, 3857 shows). Seems to me a server/configuration issue.
#4
Updated by Steve Toutant over 9 years ago
- Status changed from Feedback to Closed
Thanks for your comments Giovanni,
I successfully loaded the layer. I needed to specify the projection 3857 before add it to the map.
I will explore why qgis cannot know what is the projection.
The fact that the getMap request was different misleaded me.
thanks
#5
Updated by Giovanni Manghi over 9 years ago
Steve Toutant wrote:
Thanks for your comments Giovanni,
I successfully loaded the layer. I needed to specify the projection 3857 before add it to the map.
I will explore why qgis cannot know what is the projection.
The fact that the getMap request was different misleaded me.
thanks
I don't think is qgis that cannot recognize the projections:
wms layers are available in a number of different CRSs, it depends on how the server/service is configured. In this case if you try download the layers in 4326 they do not show, I suspect for a server issue, not a qgis one.
#6
Updated by Steve Toutant over 9 years ago
you are right