MSS provides unhelpful error message when requesting unsupported projections from non-WMS servers

Issue #244 closed
Joern Ungermann created an issue

Accessing images for stereographic projections from a non-WMS server results in a unhelpful BytesIO error. Instead, it should display the service exception of the server in question.

2017-07-27 18:31:09,884 (wms_control.process_map:302): MapPrefetcher Exception <type 'exceptions.IOError'> - cannot identify image file <_io.BytesIO object at 0x000000000E19D0A0>.
2017-07-27 18:31:09,884 (wms_control.continueRetrieveImage:1488): False False c:\Users\icg173\.mss\msui\wms_cache\3e351fc94c3038a4de92d888276ae190.png
2017-07-27 18:31:09,895 (wms_control.displayException:621): ERROR: <type 'exceptions.IOError'> cannot identify image file <_io.BytesIO object at 0x000000000E19D0A0>

Comments (9)

  1. Reimar Bauer

    Why did we get to the Image request at all, shouldn't get cababilities failed and disable that server?

  2. Joern Ungermann reporter

    get capabilities contains the supported projections.

    WMS, however, does not detail all supported projections and accepts basically everything that is supported by basemap plus some special EPSG codes.

    This is, overall, quite a bit of a mess that we have one the one hand a set of projections in MSUI and a different, partially unannounced set of prjections in the WMS. Detailing all feasible projections in the capability XML is infeasible or at least undesirable as these are billions.

    I am not deep enough in the standard. For WMS the current state is basically fine, but the support of other servers isn't. If we could identify a WMS server, one could treat these different.

    However, there is almost certainly an error message provided by the server that is not displayed. As such I think this issue should deal with the hopefully simple problem of displaying that error message.

    How one could handle the projections in general would be a different issue, but I do not have good ideas so far how handle this better than currentl.y, especially without loosing "convinient" functionality.

  3. Log in to comment