Problem loading a WMS - Githubissues

jsanz commented 9 years ago

Following this issue with a GeoWebCache WMS layer that is not working when we add it to the editor we got this on the logs

==> mapproxy-source-requests.log <==
[2015-08-24 14:05:41,186] GET http://192.168.100.82:8180/geowebcacheWM/service/wms?SERVICE=WMS&&styles=&format=image%2Fpng&height=256&bbox=10018754.1714,-10018754.1714,20037508.3428,3.08454036713e-06&transparent=True&layers=SATELLITE_WM&service=WMS&width=256&request=GetMap&srs=EPSG%3A3857&version=1.1.1 - - 60027

On the other hand the Capabilities document is giving proper GetMap urls so it seems something internal on the proxy that produces that IP address.

<GetMap>
<Format>image/png</Format>
<DCPType><HTTP><Get>
<OnlineResource xlink:type="simple" xlink:href="http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS&"/>
</Get></HTTP></DCPType>
</GetMap>

Any pointer on what could be wrong?

olt commented 9 years ago

I think this actually belongs to https://github.com/omniscale/wmtsproxy/ However, I'm able to add both services from the issue to WMTSProxy. Maybe the IP was a temporary glitch in the configuration of the external service?

jsanz commented 9 years ago

Hi @olt, I'm still having the same issue my colleague reported, I can add the server, get the layers and select one of them but afterwards the tiles from the server are not shown as a basemap.

olt commented 9 years ago

What URLs are you sending to the WMTSProxy API?

The following request gives me:

/check?url=http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS%26request=GetCapabilities

{
  "layers": [
    {
      "llbbox": [
        -180.0,
        -90.0,
        180.0,
        90.0
      ],
      "name": "WEB_MERCATOR",
      "srs": [
        "EPSG:3857"
      ],
      "title": "WEB_MERCATOR"
    },
    {
      "llbbox": [
        -180.0,
        -90.0,
        180.0,
        90.0
      ],
      "name": "HYBRID_MERCATOR",
      "srs": [
        "EPSG:3857"
      ],
      "title": "HYBRID_MERCATOR"
    },
    {
      "llbbox": [
        -180.0,
        -90.0,
        180.0,
        90.0
      ],
      "name": "SATELLITE_WM",
      "srs": [
        "EPSG:3857"
      ],
      "title": "SATELLITE_WM"
    }
  ],
  "title": "Web Map Service - GeoWebCache",
  "type": "wms"
}

And I can add each of them with the following requests:

/add?type=wms&url=http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS%26request=GetCapabilities&layer=HYBRID_MERCATOR&srs=EPSG:3857
/add?type=wms&url=http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS%26request=GetCapabilities&layer=SATELLITE_WM&srs=EPSG:3857
/add?type=wms&url=http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS%26request=GetCapabilities&layer=WEB_MERCATOR&srs=EPSG:3857

The tile request /api_maps_vic_gov_au_HYBRID_MERCATOR_EPSG_3857/wmts/map/webmercator/6/57/39.png returns a valid image.

The source request for that tile goes to http://api.maps.vic.gov.au/geowebcacheWM/service/wms?SERVICE=WMS&&styles=&format=image%2Fpng&height=1184&bbox=14832452.4647,-5205055.87811,17728498.5924,-2309009.75044&transparent=True&layers=HYBRID_MERCATOR&service=WMS&width=1184&request=GetMap&srs=EPSG%3A3857&version=1.1.1

Can you compare these requests with the URLs CartoDB sends?

viddo commented 9 years ago

Examples of requests from our end (that yields 503 errors):

viddo commented 9 years ago

…using the same URI path for the tile request you mentioned above: http://cartodb-wms.global.ssl.fastly.net/mapproxy/api_maps_vic_gov_au_HYBRID_MERCATOR_EPSG_3857/wmts/map/webmercator/6/57/39.png

olt commented 9 years ago

Are you still seeing requests to 192.168.100.82:8180? Can you remove the cached mapproxy configurations? api_maps_vic_gov_au_*.yaml

viddo commented 9 years ago

Yes, that seems to work indeed :+1: …although, does it make sense to create/cache those .yaml files if a service returns local IPs that obviously aren't going to work outside that network?

olt commented 9 years ago

It's hard for MapProxy to tell if a configuration actually makes sense. But yes, it is likely that you will hit a broken WMS service in the future.

We could store a timestamp in the services.csv and compare that timestamp to the cached MapProxy config. That way you could refresh a config by /adding the service again.

viddo commented 9 years ago

Yeah that could be. Re: your proposal, do I understand it correctly that with that kind of change all existing services would stay as they are (just like now), unless refreshed through an /add endpoint?

olt commented 9 years ago

Yes. Old CSV entries won't have a timestamp and so they will not be recreated. We could also add the timestamp (if present) to the cache name. That way any cached tiles will also be ignored on /add. The old tiles will be removed by the cron job on that system (not sure what time interval is configured for that).

olt commented 9 years ago

Ok, I've implemented the change in the WMTSProxy repo: https://github.com/omniscale/wmtsproxy Existing services are unaffected by this. The Capabilities document will only be re-requested if you add a service again.

omniscale / cartodb-wmsproxy

Problem loading a WMS #1