06-06-2018 10:32 PM - edited 06-07-2018 02:35 PM
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,
Solved! Go to Solution.
06-07-2018 04:07 AM
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?
06-07-2018 10:07 PM - edited 06-07-2018 10:13 PM
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
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,
06-08-2018 01:45 AM - edited 06-08-2018 01:46 AM
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.
Attached is the xml returned.
06-08-2018 01:52 AM - edited 06-08-2018 01:53 AM
Yes, exactly. I just called
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.
06-11-2018 09:42 PM
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:
Following order will result in wrong result:
See next for more expanded replication.
06-11-2018 10:03 PM
My reakoning -
Background on why problem is occurring.
There are two components involved in the problem:
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.
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.
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.
=> 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)
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)
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)
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
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
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:
06-11-2018 10:27 PM
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.
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
<applicationInitialization skipManagedModules="true" doAppInitAfterRestart="true">
<add initializationPage="/service.svc/get?request=GetCapabilities&service=WMS" />
(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.
- 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.
06-13-2018 03:32 AM
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).