WebGIS Discussions

[Bob]

HI team,

Our client is using WebMap 16.5, they have a consumer portal and some WMS services. These WMS services have layer queryable set to true and they are used in consumer portal's workspace. For some reason, using feature info tool in the consumer portal keeps showing "No feature info avaiable", but if we re-use that workspace in our consumer portal in our environment, the feature info does work. We also observe that if I use lower case for the queryable WMS, then it starts to work again. It is very strange.

We are puzzled on what could causes this behavior. I uncompressed the app.js, so it can be readable, and confirm that the portal does get the queryable layer right; however, I haven't traced where went wrong.

The backend https://devmaps.southlanddc.govt.nz/backend/v2/connection/wms return the services info and queryable value  in two version (normal an lowercase) is different. 

Appreciate all suggestions and ideas,

Kind regards,

[jan.neumann]

Hi Bob,

I cannot reproduce this behavior locally too, even using HTTPS access. I quite don't understand this sentence though:

The backend https://devmaps.southlanddc.govt.nz/backend/v2/connection/wms return the cap info and queryable value  in two version (normal an lowercase) is different.

Do you actually see different response from the Backend call(s) when comparing your and your client's installation?

Jan

[Bob]

Hi Jan,

Sorry for the confusion, we have been doing a lot of investigations on this. Let me explain the whole thing.

Our client has 2015 webmap that has consumer portal and wms services. We upgrade it to 16.5 version, we did clean the environment after we uninstall all the software. We upgraded existing wms services by using the upgrade button. Some of layers in the upgraded WMS are queryable, but when we use feature info in the consumer portal, it somehow shows "No feature info avaiable", we recheck the get capabilities of the wms in version 1.1.1 and it shows queryable value false for those queryable layers, which is very strange and I believe this is how backend service queries services in the starting workspace to get information for the consumer portal, as the result of this, the consumer portal gets wrong information about queryable layers. We restart IIS, webmap and delete the instances in the temporary folder, the problem gone then back again which we don't know why. We believe that the service procduce wrong information about queryable layer in the capabilities document in the verison 1.1.1 is the cause if the problem, but we don't know how it happens. We did check the content of the upgraded wms and it has the latest files and dll(s), identical as the out of the box wms instance.

Here is the service

https://devmaps.southlanddc.govt.nz/PublicCemeteryWMS/Service.svc/get?request=GetCapabilities&servic...

It has the layer Burial queryable, but the wrong capabilities document (version 1.1.1) (I attached) shows it is non queryable.

Appreciate all suggestions and ideas on the issue,

Kind regards,

Incorrect Capabilities in 1.1.1.zip ‏2 KB

[amarques]

Hi Bob.

Couldn't it be a cache problem?

I'm asking this because I just call the capabilities document (in the 1.1.1 version as you mentioned) and it seems ok for the layer Burial.

This was the request: https://devmaps.southlanddc.govt.nz/PublicCemeteryWMS/Service.svc/get?request=GetCapabilities&servic...

Attached is the xml returned.

Best regards,

António

get.zip ‏2 KB

[jan.neumann]

Yes, exactly. I just called

https://devmaps.southlanddc.govt.nz/PublicCemeteryWMS/Service.svc/get?request=GetCapabilities&servic...

And it has:

<Layer noSubsets="0" opaque="0" queryable="1">
   <Name>Burial</Name>
   <Title>Burial</Title>
...

Can you perhaps try to clear the browser cache? AFAIK Consumer Portal does not cache this document, it just sends the GET request to the server, but the Capabilities XML might be stored in the browser cache repository.

[ShaunF]

Problem occurs when ‘Hierarchy Mode’ is set to ‘Treat groups as single layers’

and the locatable (queryable) WMS entry is part of a legend grouping.

With this setup, the response from the getcapabilities request varies depending on order made.

Following order will result in correct result:

• Restart WMS application pool and backend application pool
• Make an WMS get capabilities request using version=1.3.0
  Exotic layer queryable will be 1 (always willl be for version 1.3.0 requests)
• Make an WMS get capabilities request using version=1.1.1
  Exotic layer will still return queryable as 1 which is as expected.
• Launch Consumer Portal and the feature info works correctly

Following order will result in wrong result:

• Restart WMS application pool and backend application pool
• Make an WMS get capabilities request using version=1.1.1
  (don't make an version 1.3.0 request)
• Exotic layer will still return queryable as 0 which is as incorrect and does not match previous call.
• Launch Consumer Portal and the feature info doe does not work.

See next for more expanded replication.

[ShaunF]

My reakoning -

Background on why problem is occurring.

There are two components involved in the problem:

1. Backend service requests WMS using version 1.1.1 for requests to determine which layers are queryable.

When loading a map, consumer portal calls the WebMap server backend service to obtain the WMS schema information in json format.

The backed service makes the WMS get capabilities request using parameter version=1.1.1 rather than obtaining latest version supported by the WMS.
e.g.
http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM...
instead of
http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM... which presently uses version=1.3.0 for GeoMedia WebMap 2018.

Note: as an aside, the backend service also caches the WMS information. Once the backend obtains an WMS schema from the capabilities document, it does not request it again unless the application pool is restarted. That means if the WMS is modified – such as which layers are requeryable changed from false to true – the backend service will continue to serve up previous cached result. To workaround need to restart the application pool BackendAppPool.

1. Behaviour of WMS getcapabilities result varies when grouped Hierarchy is enabled between version 1.1.1 and 1.3.0

When defining an WMS using GeoMedia WebMap, there is an option to set Hierarchy Mode to ‘Treat groups as single layers’.

‘Treat groups as single layers’ means that multiple legend entries can be grouped together as a single layer in the WMS and turned on/off together in Consumer Portal.
Example: Property layer consisting of Road frontage,

After restarting the WMS application pool, if the first call to the getcapabilities is for version 1.3.0, then subsequent request to getcapabilities using version=1.1.1 (as called by backend) will be correct. i.e. queryable for desired layers will be true.

After restarting the WMS application pool, if the first call to the getcapabilities is for version 1.1.1, then subsequent request to getcapabilities using version=1.1.1 (as called by backend) will not be correct. i.e. queryable for desired layers will be false.

Replication example:

1. GeoMedia WebMap meta-database for WMS configured
   1. Hierarchy Mode set to ‘Treat groups as single layers’
   2. Multiple legend entries in single legend group. One or more of the layers setup as Locatable (which corresponds as queryable in WMS)

=> Results in single layer in Consumer Portal legend allowing simple legend control, which is highly desired by customer

2. Stop/Start the WMSAppPool application pool

Request getcapabilities with version 1.1.1
(don’t do any other requests prior)
http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM...

Result:
exotic layer has queryable as 0 (should be 1)

3. Stop/Start the WMSAppPool application pool

Request getcapabilities with version 1.3.0
(don’t do any other requests prior)
http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM...
Result: Queryable is 1 for Exotic
(Is always 1 when using getcapabilities for version 1.3.0)

Then request getcapabilities with version 1.1.1
(don’t do any other requests prior)
http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM...

Result:
exotic layer has queryable as 1 as it should be (previously was 0)

As long as the WMS application pool is not recycled, then getcapatilities with version 1.1.1 will continue to return correct queryable.

To observe issue via Consumer Portal

1. Restart WMSAppPool application pool and BackendAppPool application pool
2. Don’t make any getcapability or other requests
3. Launch Consumer Portal nzsf18server/ConsumerPortal_WMSLocatableTest with developer tools enabled (ctrl-shift-i in Chrome or F12 in Edge)

Look for entry ‘WMS’ which is directed to backend. Look at result.

Note that IsQueryable is false for Exotic

Feature Info unavailable in portal for the exotic layer

To observe working correctly via Consumer Portal

1. Restart WMSApppool application pool and BackendAppPool
2. Make a getcapabilities request using version 1.3.0 (no other requests in between)
   http://nzsf18server.ingrnet.com/WMS_LocatableTest/service.svc/get?request=GetCapabilities&service=WM...
3. Launch Consumer Portal with developer tools enabled

Look for entry ‘WMS’ which is directed to backend. Look at result – queryable is set to true for exotic now

And getfeature info request works for exotic layer:

[ShaunF · Accepted solution]

Off course one workaround is to remove the queryable (locatable) features from the legend groups. I anticipate the WMS would then return queryable=1 correctly. However that means customers efforts to get a nice working simply layer control won't work so we are trying to avoid this option.

Current workaround we are trialling. Any better ideas appreciated.

Use IIS Application Initialization module to ensure WMS is always called using ‘version=1.3.0’ first, which causes any following calls involving version=1.1.1 to return correct queryable value in the capabilities document.

1. change all WMS to use http instead of https
   (the IIS initialize module used in workaround does not support ssl/https. This is actually a problem for client as they want to use ssl/https as much as possible. I tried using URL rewrite to get around it but was not possible unless there is some magic I missed.)
   
   
2. Deploy IIS ‘Application Initialization’ module

2. Change Application pool settings for wach WMS application pool

IIS>Application Pools, choose application pool for the WMS site, right click, advanced settings.

Change ‘Start Mode’ to ‘Always Running’

3. Locate the WMS site in IIS

Open Advanced Settings

Change ‘Preload Enabled’ from False to True

4. Locate wms web.config file by right clicking site in IIS, choose Explore then locate web.config 

1. Open web.config in notepad++
2. Location section <system.webServer>
3. Add following content:

                <applicationInitialization skipManagedModules="true" doAppInitAfterRestart="true">

        <add initializationPage="/service.svc/get?request=GetCapabilities&amp;service=WMS" />

      </applicationInitialization>

(or safer still use the IIS Configuration Editor

)

Next recycle the WMSAppPool and the BackEndAppPool application pools

At this point Consumer Portal should behave with Feature Info requests.

Notes:

- following an application pool stop/start (instead of recylce), IISRESET or similar, any calls to the WMS will return 500 - Internal server error until the initialization is complete.

Recycling an application pool should be fine as IIS keeps previous instance running until the replacement (recycled) site is up and available.

- After making a change to the WMS definition via GeoMedia or similar, restart the WMS application pool. That ensures an initialization call to version=1.3.0 is made otherwise original error can be observed. Also restart the BackendAppPool application pool as described earlier.

Limited testing perofrmed for workaround so far - trial has just commenced.

[jan.neumann]

Thanks for the report and workaround explanation!

I have logged bug regarding the wrong queryable generated on the first go, when version 1.1.1 is used (SR-5643).