Subscribe to this thread
Home - General / All posts - WMS Image not showing
Forest
617 post(s)
#08-Jun-20 05:36

I am missing something again. The wms url is

http://gaservices.ga.gov.au/site_13/services/Geophysical_Grids/MapServer/WMSServer?request=GetCapabilities&service=WMS

and a connection is made, however no image displays. It looks like tiles download but the tile column shows NULL still.

The image does not display anything when opened. Manifold 9.172.2.

Would anyone know how I get the image to display?

Attachments:
WMS_Tiles_Null.jpg

Dimitri

6,104 post(s)
#08-Jun-20 05:45

See the Problems connecting note in the Web Servers topic.

The note immediately following it, Web servers are often slow or mis-configured, is also useful.

Forest
617 post(s)
#08-Jun-20 06:11

I had a look in the log file and it is stating that the data type returned is invaliid (text/xml). It looks like Manifold was expecting tile data but instead gets the wms specification for a child page. I can't find or figure out how to get a direct url to the child page. I am trying to display the kThU layer, which is one of about 20 layers in this collection.

Is there a way to deal with WMS services that list services inside folders?

adamw


9,299 post(s)
#08-Jun-20 09:37

It doesn't matter whether a WMS layer is inside a folder or not, folders don't affect communication between Manifold and the server.

I reproduced the issue with the kThU layer (full name: 'Radiometrics2015_ternary_KThU') - no image - and digged into what happens. We send the server a request for the image data and it returns an error:

Style 'Radiometrics2015_ternary_KThU' not assigned for layer 'Radiometrics2015_ternary_KThU'.

But if we look into the capabilities document where the server describes the layers, the layer is documented like this (I removed details that do not matter):

#

<Layer queryable="1">

  <Name>Radiometrics2015_ternary_KThU</Name>

  <Title>Radiometrics Ternary KThU image 2010</Title>

  <Abstract>The national ternary radiometric image ...</Abstract>

  <CRS>EPSG:4283</CRS>

  <!-- GDA94 lat-long -->

  <CRS>EPSG:4326</CRS>

  <!-- WGS84 lat-long -->

  <CRS>CRS:84</CRS>

  <!-- WGS84 with reversed coordinate order -->

  <CRS>EPSG:3857</CRS>

  <!-- Web Mercator WGS84 -->

  ...

  <EX_GeographicBoundingBox> ... </EX_GeographicBoundingBox>

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

  <BoundingBox CRS="EPSG:4326" minx="-43.740500" ... />

  <BoundingBox CRS="EPSG:4283" minx="-43.740500" ... />

  <MetadataURL type="TC211"> ... </MetadataURL>

  <Style>

    <Name>Radiometrics2015_ternary_KThU</Name>

    <Title>Radiometrics2015_ternary_KThU</Title>

    <LegendURL width="276" height="234"> ... </LegendURL>

  </Style>

</Layer>

...so, the layer is documented as supporting that style. In fact, there's no other style to ask for.

This seems like a problem with the configuration of the server.

Forest
617 post(s)
#08-Jun-20 23:59

Thanks for investigating the issue. The issue may be how the legend is set up. I have added a screenshot from Q to show what it looks like. All the data comes out of ESRI products which the government seems to have a strong preference for. It is often a bit of a struggle to get started if not using ESRI.

Attachments:
WMS_Legend_KThU.jpg

Dimitri

6,104 post(s)
#09-Jun-20 08:20

WMS isn't an ESRI standard. If Geoscience Australia have misconfigured their WMS server to say it uses a style that the server itself rejects, that's simply a server configuration error.

Have you contacted the webmaster for that site? Send them a copy of adamw's post. Webmasters are often very grateful to be notified of such errors.

adamw


9,299 post(s)
#09-Jun-20 10:11

The issue is in the handling of the STYLES parameter on the server.

The server declares a named style for the layer. So we take that style and put it into STYLES. The server then returns an error saying that the style is not supported. That's a bug on the server.

Some software don't bother with the styles and pass a blank string even if the server defines them. The spec allows that and says that the server should then select the style automatically. Passing a blank string does work with this particular server. But if we switch from passing the styles to passing a blank string, all that will accomplish is that this particular server will start working but other servers with symmetric issues that have been working before will stop working and start reporting errors.

The real solution is to fix the server, the problem is there.

Forest
617 post(s)
#10-Jun-20 07:19

Hi Adam and Dimitri,

I reported the issue to GeoSciences Australia and this is the response:

Unfortunately I must disagree with the Manifold forum that the problem lies with the web service. While I am not familiar with Manifold, the WMS, and the layer in question, and the style, work fine in all GIS (QGIS, ArcGIS) and web portal applications (eg http://portal.geoscidence.gov.au, http://soe.terria.io/) that I have tried. The WMS GetCapabilities is valid and well-formed xml, and the legend image URL is working. I believe that Manifold is not interpreting the WMS correctly. I am guessing about Manifold’s capabilities, but WMS specification allows two kinds of calls to get a legend – one is a WMS GetLegendGraphic request which requires the web server to generate a legend on the fly; the second is to provide a URL to a pre-prepared legend image. We use the second method in this particular case. If Manifold is only capable of interpreting the first method, then you won’t get a legend for the Radiometrics Ternary Image layer.

I have included links to the WMS GetCapabilities document and the style legend image below:

·http://gaservices.ga.gov.au/site_13/services/Geophysical_Grids/MapServer/WmsServer?REQUEST=GetCapabilities&SERVICE=WMS&VERSION=1.3.0

·http://services.ga.gov.au/gis/rest/directories/capabilities/Geophysical_Grids/RadiometricsTernary_legend.jpg.

tjhb

9,320 post(s)
#10-Jun-20 08:09

Good on you, this sort of communication is ideal.

If I’m not mistaken, Geosciences Australia is saying that they only support (to be brief) method B, although your report shows that their metadata also describes method A.

If they do not support A, they should remove A from their metadata, obviously, right?

Added. It is never enough for a data provider claiming to support public data standards to say “Well look, it works in all these common interfaces”. What they must show, if they take data standards seriously, is that they comply with the standards, and moreover do not depart from them.

Bernd Raab42 post(s)
#10-Jun-20 12:55

in M9 i cannot get the information from a wms-datasource. In GlobalMapper for example i click the feature info tool to get the info of the style. Same in QGIS with its info-tool.

Manifold shows the raster but with alt-cklick a certain style in the data there is no information available. That happens with nearly all wms-data i use. If i only want the raster, eg. an aerial image, this problem is not relevant.

Here is a screenshot of a geological map from a wms-datasource in Globalmapper and one from QGIS

Attachments:
geo_GM.PNG
ge_QG.PNG

rk
395 post(s)
#10-Jun-20 13:49

This is WMS GetFeatureInfo request that is imho kinda wierd addon to a raster layer. Handy though.

I think it would be quite easy to make a computed field for a drawing that makes GetFeatureInfo requests for every point in that drawing. I might try it in the evening.

rk
395 post(s)
#10-Jun-20 20:50

Oh, I was a bit wrong. GetFeatureInfo wants a pixel x-y of some GetMap request. Which one to use? Usually it would be the last GetMap (current view). But Manifold makes requests for tiles not for entire view. I could fake a bbox and width/height at some sufficiently large scale. I won't try it now.

Example from here:

http://localhost:8080/geoserver/wms?

request=GetFeatureInfo

&service=WMS

&version=1.1.1

&layers=topp%3Astates

&styles=

&srs=EPSG%3A4326

&format=image%2Fpng

&bbox=-145.151041%2C21.73192%2C-57.154894%2C58.961059

&width=780

&height=330

&query_layers=topp%3Astates

&info_format=text%2Fhtml

&feature_count=50

&x=353

&y=145

&exceptions=application%2Fvnd.ogc.se_xml

adamw


9,299 post(s)
#11-Jun-20 07:45

Clicking into floating-point X-Y using GetFeatureInfo can be done like this: pass BBOX= x-0.001, y-0.001, x+0.001, y+0.001 (eg, BBOX=34.999,74.999,35.001,75.001), pass WIDTH=1, HEIGHT=1, X=0, Y=0.

The WIDTH and HEIGHT define the dimensions of the output raster (which you aren't asking for, that would be GetMap). The BBOX defines the rectangle that corresponds to the raster in the coordinate system. So, you tell the server that you want a single pixel and click into it.

Some servers might have restrictions on minimum size, in which case you'll have to use something like WIDTH=101, HEIGHT=101, and click into X=50, Y=50, scaling BBOX accordingly. But that's usually only done for GetMap (and normally shouldn't be done at all).

Forest
617 post(s)
#17-Jun-20 07:09

Geosciences Australia have replied to the latest info and confirm that there is an issue.

We think we may have tracked down the problem. I appears to be a limitation in ESRI’s ArcGIS Server software around its support of custom styles. As a test of our theory, can you please tell me if you can, in Manifold, correctly render all the layers in this WMS, and display all their custom legend images.

I tried the wms layer and could not get it working. Maybe that is a user limitation and someone who really knows manifold could have a go.

adamw


9,299 post(s)
#17-Jun-20 09:06

Yes, that works fine!

The server defines a single style named 'default' for each layer, we put that name into the STYLES parameter in the GetMap request, the server recognizes the name of the style and returns image data without any issues.

Most of the layers have scale limits and only start showing data at a certain zoom level. That's fine. To see the data, start with opening the AUS_GeoRegions_5M Image, then drop other layers into the window with it and zoom to some place using AUS_GeoRegions_5M as a guide.

rk
395 post(s)
#17-Jun-20 10:19

A story about deceiving GetCapabilities responses.

Most of the layers have scale limits and only start showing data at a certain zoom level.

Yeah, I had recently a conversation with our national data provider.

They launced a new (second) web app for historic maps - now available at all zoom levels, they said. It was great. I wanted WMS too. The old WMS has scale limits. The new WMS is presumably not public although the GetCapabilites response is almost perfect, only the xlink:href values use internal server name, not the public ones that the web app uses. Easy to override when programming a web app.

When I told, I wanted wider scale on old WMS they said - oh, we removed the limit from most layers on the old WMS. Yeah, but not from capabilities document. Again, easy to overstep given parameters when programming a tailored app. A decent general client should respect the scale limit and not issue requests outside of it.

Seems that programmers treat server capabilities more as suggetions or hints, than constraints.

adamw


9,299 post(s)
#17-Jun-20 11:43

We've seen that, too.

Just to be clear, when we see a scale limit and the current scale is outside of the allowed range, we do NOT issue a request to the server at all. First, because that's what the scale limit is for - one of the things it is supposed to allow is dropping, say, 5 layers for the same data but different detail levels into a map, and then dynamically turning on only one of them for each particular scale depending on what that scale is. Second, because if the server ends up returning a non-empty image outside of the scale range it declared for a layer, rendering it might actually be unwanted -- the non-empty image for a scale declared to be unsupported might simply be a product of a crude implementation of the scale ranges: leave GetMap be happily oblivious of the scale limits imposed, and convey to the client via GetCapabilities which scales makes sense to use.

Dimitri

6,104 post(s)
#17-Jun-20 12:19

Yes, it does work fine. Here's a version that's been styled to use hill shading to provide relief, and using a different palette.

Attachments:
Aus_georegions.jpg

Forest
617 post(s)
#19-Jun-20 03:15

Thanks for checking the WMS out. The main server is now being fixed.

adamw


9,299 post(s)
#10-Jun-20 14:33

As Riivo says, we don't send GetFeatureInfo requests on clicks into WMS rasters because this feature feels a little weird and WMS is nearly the only technology that may support it as an option. We might still do this in the future, because as you say, the returned data might be valuable and because we already allow clicking into a raster to show its data (so why not also show data returned by the server).

Dimitri

6,104 post(s)
#10-Jun-20 14:47

If they do not support A, they should remove A from their metadata, obviously, right?

Yes, exactly. The reply from Geoscience Australia is way off base. It's not about legends, and it's not about the xml being well formed or not. It's about the server failing to do what the WMS spec requires it to do, given what the server itself says. Perhaps adamw's more extended discussion will help them.

adamw


9,299 post(s)
#10-Jun-20 14:05

Thank you.

First, it's not about the legend (GetLegendGraphic), it's about the map (GetMap).

Here's what happens:

We ask the server what layers it has and what styles they use:

http://gaservices.ga.gov.au/site_13/services/Geophysical_Grids/MapServer/WMSServer?request=GetCapabilities&service=WMS

The server responds that it has many different layers, eg, it has a layer named 'Radiometrics2015_ternary_KThU' and this layer supports the single style named 'Radiometrics2015_ternary_KThU' (the name of the style coincides with the name of the layer). The relevant fragment of the capabilities document is in my post above.

According to the WMS spec (OGC 06-042, available here), the GetMap request has to include the STYLES parameter and this STYLES parameter has to convey the desired style for each requested layer. We are only requesting data for one layer so we are talking about a single style. The style for a specific layer can be either (a) one of the styles supported by the layer mentioned in the capabilities document, or (b) a blank string, in which case the server is supposed to choose whichever style it wants. Since the capabilities document included information about the styles, we are using option (a) and passing the server the name of the style it said it supports. QGIS and other clients don't bother specifying the styles and are using option (b). The server should support both (a) and (b), but it only supports (b) and fails with (a). That's what the issue is.

Here's the full text of the relevant section in the spec:

7.3.3.4 STYLES

The mandatory STYLES parameter lists the style in which each layer is to be rendered. The value of the STYLES parameter is a comma-separated list of one or more valid style names. There is a one-to-one correspondence between the values in the LAYERS parameter and the values in the STYLES parameter. Each map in the list of LAYERS is drawn using the corresponding style in the same position in the list of STYLES. Each style Name shall be one that was defined in a <Style><Name> element that is either directly contained within, or inherited by, the associated <Layer> element in service metadata. (In other words, the client may not request a Layer in a Style that was only defined for a different Layer.) A server shall throw a service exception (code = StyleNotDefined) if an unadvertised Style is requested. A client may request the default Style using a null value (as in “STYLES=”). If several layers are requested with a mixture of named and default styles, the STYLES parameter shall include null values between commas (as in “STYLES=style1,,style2,,”). If all layers are to be shown using the default style, either the form “STYLES=” or “STYLES=,,,” is valid.

If the server advertises several styles for a layer, and the client sends a request for the default style, the choice of which style to use as default is at the discretion of the server. The ordering of styles in the service metadata does not indicate which is the default.

So, again, the client has two options - it may either specify the name of the style it wants to use, or it may specify a blank string and let the server use whatever it wants. The choice belongs to the client, the server has to support both.

Here's the request that we send (I added a new line after each parameter for readability, you can get the exact URL used by right-clicking the URL and invoking 'Copy link', or just by clicking the URL to open it):

http://gaservices.ga.gov.au/site_13/services/Geophysical_Grids/MapServer/WmsServer? VERSION=1.3.0 &REQUEST=GetMap &LAYERS=Radiometrics2015_ternary_KThU &STYLES=Radiometrics2015_ternary_KThU &CRS=CRS%3a84 &BBOX=112.9205000000000041,-43.7404999999999973,153.6394999999999982,-9.0675000000000026 &WIDTH=965 &HEIGHT=822 &FORMAT=image%2fpng &TRANSPARENT=TRUE &BGCOLOR=0xFFFFFF

This fails and returns text/xml with the following:

<ServiceException code="StyleNotDefined"> Style 'Radiometrics2015_ternary_KThU' not assigned for layer 'Radiometrics2015_ternary_KThU'. </ServiceException>

The style *is* defined in the capabilities document, but the server says it is not defined.

Here's the request that QGIS sends:

http://gaservices.ga.gov.au/site_13/services/Geophysical_Grids/MapServer/WmsServer? VERSION=1.3.0 &REQUEST=GetMap &LAYERS=Radiometrics2015_ternary_KThU &STYLES= &CRS=CRS%3a84 &BBOX=112.9205000000000041,-43.7404999999999973,153.6394999999999982,-9.0675000000000026 &WIDTH=965 &HEIGHT=822 &FORMAT=image%2fpng &TRANSPARENT=TRUE &BGCOLOR=0xFFFFFF

This succeeds and returns an image, because STYLES is set to a blank string.

The server has to either stop advertising styles in the capabilities document - this is permitted by WGS spec 7.2.4.6.5 for layers which only support a single style, or to recognize the name of the style in the STYLES parameter for GetMap.

Hope this helps.

Dimitri

6,104 post(s)
#11-Jun-20 05:43

I reported the issue to GeoSciences Australia and this is the response

Forest, not to pile on, but I cannot resist pointing out that the quotation at the bottom of the georeference.org home page today applies perfectly to the off-base response they sent:

This isn't right, this isn't even wrong. - Wolfgang Pauli, upon reading a young physicist's paper

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