WMSGetFeatureInfo not returning results

Question

I am having a problem getting the results back from a WMSGetFeatureInfo call to my GeoServer. Using OpenLayers 2.12, GeoServer 2.4.0, Windows Server2008, and Microsoft IIS 7.5 with Application Request Routing Cache and URL Rewrite. I do NOT use a proxy because I use URL Rewrite. The URL Rewrite takes my incoming requests and formats them to avoid the cross domain/same origin problem.

I have been successfully querying WFS data using this setup for 2 years but when I try to use the WMSGetFeatureInfo it fails.

Here is my process:

1. I serve multiple WMS layers from GeoServer to my web page.
2. The user selects a WMS layer from a dropdown. This sets the variable "selLayer" so my WMSGetFeatureInfo call is pointing at the layer the user wants to get information about.
3. When the user clicks on the layer it fires this code which creates a OpenLayers WMSGetFeatureInfo control with an event listener that should accept the return text & xmlHttp request and display them in a div. :

     var infoControl = new OpenLayers.Control.WMSGetFeatureInfo({
         url: 'http://xx.xx.xx.xx:8080/geoserver/wms',
         title: 'Identify features by clicking',
         layers: [selLayer],
         queryVisible: true,
         //eventListeners: { getfeatureinfo: function (event) { alert("TEXT: " + event.text + ", XY: " + event.xy + ", REQUEST" + event.request + ", FEATURES: " + event.features); } } 
         eventListeners: { getfeatureinfo: function (event) {
             document.getElementById("divAttributes").innerHTML = event.text + "Test Text";
             alert("PUT TEXT HERE!!!");
         } 
         }
     });


     map.addControl(infoControl);
     infoControl.activate();

But, when the script runs I do not get return values for the event.text. When I run this in FireFox (with FireBug) I can copy the GetFeatureInfo request into a new browser window and I get the desired return values.

So my question is: Why am I not getting the return values when I run this on my map webpage but I do get results by posting the request into a new browser window.

Answer 1

I ran into something similar a couple of weeks back and enabling CORS took care of it for me. there are step by step instructions here http://enable-cors.org.

this is the advice I recieved:

You may not want to allow cross-domain requests from all hosts, so you could set the value of the Access-Control-Allow-Origin header to the host of your ol3 application instead of '*'. So if your GeoServer runs on myhost.com:8080 and your ol3 app runs on myhost.com:80, your Access-Control-Allow-Origin header's value could be 'myhost.com'

Answer 2

I faced the same problem myself and i tried many solutions that discussed here or in other forums and finally i managed to solve the problem of enabling the Cross Origin in Geoserver.

After many trials i discovered that the solution is pretty simple following the exact steps that found in the Jetty webpage Jetty Cross Origin Filter.

But with a small change, the page said that we have to copy the following Cross-Origin filter to the (Web.xml) configuration file, but the solution that worked with me is copying this filter xml configuration in to (webdefault.xml) configuration file, when applying this change the geoserver worked like a charm and i could run any WFS, WMS GetFeatureInfoRequest in JSON format using AJAX instead of using IFrame soultion.

I'm using the following software versions:

• Boundless OpenGeo v4.5 .
• Geoserver v 2.6.2 .
• Jetty v 7.6.13.v20130916 .

Here is the detailed steps:

1. Download the matched version of the Jetty servlets according to your jetty version from this page Jetty Servlets .
2. In this example i'm using jetty v7.6.13.v20130916 so the jar file should be named
   (jetty-servlets-7.6.13.v20130916.jar) the filename will be different according to the jetty version - don't change its name because jetty matching the servlet name with its version like :
   jetty-servlets-<%JETTY_VERSION%>.jar, so don't rename it.

3. Stop the (GeoServer, Postgres) services and Take a copy from the OpenGeo directory located in
   (C:\Program Files (x86)\boundless\OpenGeo) and also Copy the OpenGeo directory located in
   (C:\ProgramData\boundless\OpenGeo) before starting this tutorial, as a precaution step.

4. Copy the file (jetty-servlets-7.6.13.v20130916.jar) (As-is) into the jetty Lib directory
   (*C:\Program Files (x86)\boundless\OpenGeo\jetty\lib*) also the directory may change according your installation directory.

5. Copy and paste the following xml lines into the (webdefault.xml) located in
   (C:\Program Files (x86)\boundless\OpenGeo\jetty\ect\webdefault.xml), i'm not sure that the location for these lines to place in the file is important or not but i paste them starting from line #306 after </serlet-mapping>.

<filter>
    <filter-name>cross-origin</filter-name>
    <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>cross-origin</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

6. Start the (GeoServer, Postgres) services, wait for a few seconds and browse to the geoserver page, the geoserver will start correctly.

This tutorial worked for me and i hope it work for anyone facing the same problem.

Answer 3

Why am I not getting the return values when I run this on my map webpage but I do get results by posting the request into a new browser window?

I'm not sure if this can answer your question above, but I had a similar question and problem time ago. At the end I found that the problem was the app serving the features, in this case FeatureServer. It happened that this app wasn't reading correctly the requested feature (in GeoJSON format) and it wasn't parsed correctly to the XMLHttp request (or read it correctly by it).

I'm thinking that you can keep investigating with Firebug, put some breaks with it and check the XMLHttpRequest. The problem could be related to the IIS also, check there also because I read somewhere before people having communication issues between GeoServer and IIS on Windows.

Hope this helps,

Answer 4

I had a similar problem recently on a project and implemented a proxy in PHP on the main web site to make the WFS query to my Geoserver on another URL. The issue was definitely CORS related ..

Proxy can be see at

https://raw.githubusercontent.com/eslachance/php-transparent-proxy/master/proxy.php