Subscribe to this thread
Home - General / All posts - WMS problems in M9

273 post(s)
#25-Jun-20 04:56

I reported having problems with getting WMS images from here in 2019 using Manifold 8.

I see that I had reported it was working with M9 at the time.

Today I've been trying to link to the WMS with M9 with no success. The folder structure appears below Data Source and the raster icon but no image can be viewed. The table can be viewed and seems to have tile data.

It works fine in QGIS and ArcMap 10.8 but not M9


6,364 post(s)
#25-Jun-20 06:03

Today I've been trying to link to the WMS with M9 with no success.

Details? Example: the URL you're using, what you do step by step, not leaving any details out, etc.


9,470 post(s)
#25-Jun-20 07:59

Are there any complaints in the log window?

As Dimitri says, we need the URL of the server to check what is going on. As regards ArcMap and QGIS seemingly being able to work with the same server, this might of course be a bug on our part, but might also be a problem related to the server. We had a thread not too long ago with one of the latter cases: WMS Image not showing, a fellow user of 9 took time to report the problem to the server admins and it seems that the server will be fixed as a result.


273 post(s)
#25-Jun-20 08:56

Thanks Adam and Dimitri.

Yes, I read the thread about the misconfigured server and am aware that this is common.

My observations are in no way accusatory toward Manifold.

The URL is in the link on the word 'here' in the first line.

As for the procedure, it is the same one that works with other wfs/wms servers in M9 so I won't bother you with it yet. If you tell me "it works for me!" then I'll happily lay out all the details.

Sorry Adam, I almost forgot. Log window:

2020-06-25 17:58:31 Web request: (root)::[VicMap BaseMaps_1] (GetCapabilities v.1.3.0) (0.352 sec, 9.5 KB)

2020-06-25 17:58:38 Web request: (root)::[VicMap BaseMaps_1]::[AERIAL_VG] (GetMap) (0.248 sec, 372 B)

2020-06-25 17:58:38 *** (root)::[VicMap BaseMaps_1]::[AERIAL_VG] (GetMap) Invalid content type 'text/xml; charset=utf-8'.

2020-06-25 17:58:38 Render: [VicMap BaseMaps_1]::[AERIAL_VG Image] (0.322 sec)


6,364 post(s)
#25-Jun-20 09:39

That's a misconfigured server.

Note the following in your log window report:

2020-06-25 17:58:38 *** (root)::[VicMap BaseMaps_1]::[AERIAL_VG] (GetMap) Invalid content type 'text/xml; charset=utf-8'.

Whoa! What the heck is a WMS server doing announcing that an obviously tile layer is text? Nope. That's not right.

From the Web Servers topic:

Some WMS servers are erroneously configured so the server mislabels image tiles as text/xml. A WMS compliant client will reject such mislabeled tiles, but because webmasters often fail to test their sites using WMS compliant clients such mislabeling errors are frequent.

Manifold tries to deal with such errors, but second guessing web server errors cannot fix all possible errors.

Solution: contact the web server operator, and let them know they have a configuration error where they are saying an image tile server is sending text. That's flat out wrong.

If they're honest people who care that when they say they are operating a WMS server they are telling the truth, they'll be glad to hear of the error and will fix it right away.

Of course, there's always the problem, as the Web Servers topic puts it:

Some webmasters may insist their web servers are correctly configured even when explicit errors are pointed out.

424 post(s)
#25-Jun-20 09:54

If I set "SourceCoordSystemPreferred": "3111" then I get images.

If not, then I get Invalid content type 'text/xml; charset=utf-8'


6,364 post(s)
#25-Jun-20 10:17

Hmm.. could be a Manifold error then.


9,470 post(s)
#25-Jun-20 10:24

Thanks and sorry I missed the link the first time.

We checked and this might be an error in our code indeed. The layer supports two coordinate systems but advertises bounding box data for one more system. Because of bounding box data for the extra system we end up deciding that the server supports that system as well and ask it to provide data in that system. The server then fails noting that no, it doesn't support the system. We'll check the spec to be sure, but our code is probably wrong here. If it is, we'll fix it.

As Riivo says, you can override the coordinate system used by the dataport by setting the preferred coordinate system to one of the supported ones: either EPSG:3857 or EPSG:3111. We saw EPSG:3857 also fail with a server error on some layers, which we'll investigate separately (the failure might have been intermittent), but EPSG:3111 seems to work fine.

Thanks a lot for taking the time to report the issue!


273 post(s)
#25-Jun-20 10:29

Thank you very much Dimitri, Adam and rk.

You can't get better and more prompt service than that!

I will await the final determination and alert the web server tech if appropriate.



9,470 post(s)
#25-Jun-20 12:14

All right, we have the final determination.

We checked the spec and the problem is actually with the server.

The capabilities document is at:

Let's take the layer named AERIAL_VG (the first one in the order used by the Project pane in 9). That layer is part of a bigger unnamed layer from which it inherits parts of its declaration. The definition of the parent layer is this:


  <Title>Vicmap Basemaps</Title>



  <EX_GeographicBoundingBox> ... </EX_GeographicBoundingBox>

  <BoundingBox CRS="CRS:84" ... />

  <BoundingBox CRS="EPSG:3857" .../>



The definition of AERIAL_VG is this:



  <Title>Vicmap Basemap - VicGrid94 - Aerial</Title>

  <Abstract>Vicmap Basemap - VicGrid94 - Aerial</Abstract>

  <EX_GeographicBoundingBox> ... </EX_GeographicBoundingBox>

  <BoundingBox CRS="CRS:84" ... />

  <BoundingBox CRS="EPSG:3857" ... />

  <BoundingBox CRS="EPSG:3111" ... />

</Layer> in the WMS spec (WMS 1.3.0, OGC 06-042) describes the use of BoundingBox elements for a layer. According to the spec, "A Layer shall not provide a BoundingBox for a CRS it does not support". However, fragments above show that the layer includes a BoundingBox element for CRS:84 which is not declared as supported using a corresponding CRS element. Further, if the client ends up making a request for layer data in CRS:84, as 9 does, the server reports that the coordinate system is unsupported.

The server has to follow the spec and stop providing BoundingBox elements for coordinate systems that it does not support.

The reason we choose CRS:84 in this case is that its bounding box is listed first. While not mandated by the standard, it is common for server implementations to list data for the native coordinate system of the layer first, so we use that as a criteria for the automatic selection of the coordinate system when there are multiple systems available. (The selection logic is more sophisticated than just 'use the first listed system' because, for example, some of the systems might not be recognized, etc, but it does try to prefer the first system over others.)

ArcMap and QGIS likely use a different logic and don't take hints from bounding box info, so their default selection ends up being different.

You can override the default coordinate system when linking the server in 9 using the preferred coordinate system setting in the New Data Source dialog.

In addition to WMS 1.3.0 the server also supports WMS 1.1.1, available from:

Linked that way, the server works. From the inspection of the capabilities document for 1.1.1 it seems that the breakage was introduced in automatic conversion from 1.1.1 to 1.3.0 where each LatLonBoundingBox element got replaced with an EX_GeographicBoundingBox element plus a BoundingBox CRS="CRS:84" element. The conversion should have only generated the EX_GeographicBoundingBox element because the meaning of the BoundingBox element is slightly different.

Further, in both 1.1.1 and 1.3.0, some of the layers refuse to show and this also seems to be the fault of the server.

This request for the CARTO_VG layer works (I added extra spaces and shortened the bounding box numbers for display purposes, click the link to get the original URL): REQUEST=GetMap& LAYERS=CARTO_VG& STYLES=& CRS=EPSG%3a3857& BBOX=15194443.512656,-5087496.483329,18053007.294871,-3597497.714494& WIDTH=1218& HEIGHT=635& FORMAT=image%2fpng& TRANSPARENT=TRUE& BGCOLOR=0xFFFFFF

A similar request for the AERIAL_VG layer, however, fails with a server error: REQUEST=GetMap& LAYERS=AERIAL_VG& STYLES=& CRS=EPSG%3a3857& BBOX=15194443.512656,-5087496.483329,18053007.294871,-3597497.714494& WIDTH=1218& HEIGHT=635& FORMAT=image%2fpng& TRANSPARENT=TRUE& BGCOLOR=0xFFFFFF

This should be fixed as well.

Hope this helps.

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.