ThinkGeo.com    |     Documentation    |     Premium Support

V14.2 - WmsLayer and V10.6 WmsServer Issue

#21

hi Ben,

The code that was written for my WmsServer does not set ContentType and has not been modified to accommodate V14.2.

The V13.3 client works so V13.3 had to have been designed to accommodate image/image/png.

The only thing that changed in the equation is the introduction of the async methodology. How does V13.3 accommodate this?

Below is an example of the GetMap Request, which contains the FORMAT specification…

From a Bing search of what is wms image/image/png versus image/png? the below result distinguishes between Image/png and image/image/png.

Does this have anything to do with the use of the new HTTP implementation?

Thanks,
Dennis

REQUEST=GetMap&BBOX=-10750391.358502172,4481187.063865244,-10750238.823117875,4481339.599249542&WIDTH=512&HEIGHT=512&LAYERS=NearMapChicagoOemc&STYLES=&FORMAT=image/jpeg&SRS=EPSG:3857&VERSION=1.1.1&SERVICE=WMS&DATUM=WGS84

Copilot

The difference between wms image/image/png and image/png lies in their context and usage:

WMS (Web Map Service) Context :

wms image/image/png : This format is used in the context of a Web Map Service (WMS). WMS is a standard protocol developed by the Open Geospatial Consortium (OGC) for serving georeferenced map images over the internet. When you request a map image from a WMS, you can specify the format of the image you want to receive. wms image/image/png indicates that the requested image format is PNG within the WMS protocol.

General Image Format :

image/png : This is a standard MIME type used to specify that the image is in PNG format. It is commonly used in various contexts, such as HTML, HTTP headers, and other web technologies, to indicate that the content being served or requested is a PNG image.

In summary, wms image/image/png is specific to WMS requests, while image/png is a general MIME type for PNG images. Both indicate the PNG format, but the former is used within the WMS protocol.

#22

Hi Dennis,

  1. The returning ContentType should be “image/png”, it is a bug on the server side returning an invalid value such as “image/image/png”
  2. We’ve made many WMS related changes in V14, one of them is making the WMS Layer more restrictive by checking the returning ContentType, That is the reason why v13 client works while v14 doesn’t, (not because of the async)

To fix it:

  1. option 1: Update the wms server, make the ContentType “image/png”.
  2. option 2: Update the client by assuming the content is an image if ContentType is null, (you already did it), it’s more like a workaround than a solution.

I’m not very sure how hard it is to go with option #1, as the WMS server edition is out of date and I don’t have your server side code. Just go ahead and have a try on your side and let us know if you have any questions.

Thanks,
Ben

#23

hi Ben,

Thanks for the update. I would agree that it’s a good idea to verify ContentType. Now I know why V13.3 works.

At this point it’s not worth modifying my WmsServer as it needs to be replaced anyway. I’ll continue to use the class code you sent and attempt to put in a check for image/image/xxxxx.

I had the thought that maybe the ThinkGeo WmsServer is setting ContentType to image/image/png to signify that the image is being returned thru a proxy. Just a thought.

Thanks for getting to the bottom of all this, much appreciated.

Dennis

#24

No problem! Always glad to help!