[Geoserver-users] Bug in WMS GetFeatureInfo in lastest nightly

Roger_Bedell · June 30, 2009, 11:02am

Dear List,
Sorry to keep writing, but here’s another problem that just popped up, thought you should know…ogi:quad24 is a polygon layer, just the USGS 24k quad boundaries, stored in PostGIS.

In 1.7.3, this WMS GetFeatureInfo request works fine:

http://ogi.state.ok.us/geoserver/wms?LAYERS=ogi%3Aokcounties&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_xml&SRS=EPSG%3A900913&BBOX=-10861499.29308%2C4214678.6993069%2C-10831956.381652%2C4232335.6528383&X=350&Y=204&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=ogi:quad24&WIDTH=773&HEIGHT=462

However, in latest nightly, it errors out, and the debug log is:

2009-06-30 05:41:38,524 DEBUG [geoserver.filters] - filtering http://ogi.state.ok.us/geoserver/wms
2009-06-30 05:41:38,524 DEBUG [geoserver.global] - getting type ogi:okcounties
2009-06-30 05:41:38,524 DEBUG [readers.wms] - Assigning default style to all the requested layers
2009-06-30 05:41:38,524 DEBUG [geoserver.global] - getting type ogi:quad24
2009-06-30 05:41:38,524 TRACE [wms.responses] - ENTRY org.vfny.geoserver.wms.requests.GetFeatureInfoRequest@anonymised.com
2009-06-30 05:41:38,524 DEBUG [wms.responses] - request format is text/html
2009-06-30 05:41:38,524 DEBUG [wms.responses] - found GetFeatureInfoDelegate class org.vfny.geoserver.wms.responses.featureInfo.HTMLTableFeatureInfoResponse
2009-06-30 05:41:38,524 ERROR [geoserver.ows] -
org.vfny.geoserver.wms.WmsException
at org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.execute(AbstractFeatureInfoResponse.java:410)
at org.vfny.geoserver.wms.responses.featureInfo.GetFeatureInfoDelegate.execute(GetFeatureInfoDelegate.java:145)
at org.vfny.geoserver.wms.responses.featureInfo.GetFeatureInfoDelegate.execute(GetFeatureInfoDelegate.java:94)
at org.vfny.geoserver.wms.responses.GetFeatureInfoResponse.execute(GetFeatureInfoResponse.java:97)
at org.geoserver.ows.adapters.ResponseAdapter.getMimeType(ResponseAdapter.java:48)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:699)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:216)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:124)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.getActiveRules(AbstractFeatureInfoResponse.java:438)
at org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.execute(AbstractFeatureInfoResponse.java:245)
… 54 more

Andrea_Aime3 · June 30, 2009, 12:26pm

Roger Bedell ha scritto:

Dear List,
Sorry to keep writing, but here's another problem that just popped up, thought you should know...ogi:quad24 is a polygon layer, just the USGS 24k quad boundaries, stored in PostGIS.
In 1.7.3, this WMS GetFeatureInfo request works fine:
http://ogi.state.ok.us/geoserver/wms?LAYERS=ogi%3Aokcounties&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_xml&SRS=EPSG%3A900913&BBOX=-10861499.29308%2C4214678.6993069%2C-10831956.381652%2C4232335.6528383&X=350&Y=204&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=ogi:quad24&WIDTH=773&HEIGHT=462
However, in latest nightly, it errors out, and the debug log is:

...

Caused by: java.lang.NullPointerException
at org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.getActiveRules(AbstractFeatureInfoResponse.java:438)
at org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.execute(AbstractFeatureInfoResponse.java:245)
... 54 more

Hmmm... this can only happen if no style was found for the current
layer. Before this was not evaluated, but now GeoServer inspects it
in order to dynamically compute a good search radius for the
GetFeatureInfo based on the symbolizers size (explicit size elements,
line widths and the like).

However I'm not sure why you're experiencing this, the layer you
are exposing with 1.7.3 does have a style associated to it.
Is the default style for that layer lost when you use 1.7.5?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Roger_Bedell · June 30, 2009, 1:15pm

Thanks Andrea for your quick reply.

No, all style info should still be there, because when I'm switching between 1.7.3 and latest nightly, the data directory stays the same.

However looking at the request, I see a different LAYERS=ogi%3Aokcounties, whereas the QUERY_LAYERS=ogi:quad24. Would that have an impact? I would think that the LAYERS and FORMAT would be ignored in the GetFeatureInfo, and are just there to look pretty. But I'm no WMS expert.

Roger

--------------------------------------------------
From: "Andrea Aime" <aaime@anonymised.com>
Sent: Tuesday, June 30, 2009 2:26 PM
To: "Roger Bedell" <roger@anonymised.com>
Cc: <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] Bug in WMS GetFeatureInfo in lastest nightly

Roger Bedell ha scritto:

Dear List,
Sorry to keep writing, but here's another problem that just popped up,
thought you should know...ogi:quad24 is a polygon layer, just the USGS
24k quad boundaries, stored in PostGIS.

In 1.7.3, this WMS GetFeatureInfo request works fine:

http://ogi.state.ok.us/geoserver/wms?LAYERS=ogi%3Aokcounties&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_xml&SRS=EPSG%3A900913&BBOX=-10861499.29308%2C4214678.6993069%2C-10831956.381652%2C4232335.6528383&X=350&Y=204&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=ogi:quad24&WIDTH=773&HEIGHT=462

However, in latest nightly, it errors out, and the debug log is:

...

Caused by: java.lang.NullPointerException
at
org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.getActiveRules(AbstractFeatureInfoResponse.java:438)
at
org.vfny.geoserver.wms.responses.featureInfo.AbstractFeatureInfoResponse.execute(AbstractFeatureInfoResponse.java:245)
... 54 more

Hmmm... this can only happen if no style was found for the current
layer. Before this was not evaluated, but now GeoServer inspects it
in order to dynamically compute a good search radius for the
GetFeatureInfo based on the symbolizers size (explicit size elements,
line widths and the like).

However I'm not sure why you're experiencing this, the layer you
are exposing with 1.7.3 does have a style associated to it.
Is the default style for that layer lost when you use 1.7.5?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · June 30, 2009, 1:47pm

Roger Bedell ha scritto:

Thanks Andrea for your quick reply.

No, all style info should still be there, because when I'm switching between 1.7.3 and latest nightly, the data directory stays the same.

However looking at the request, I see a different LAYERS=ogi%3Aokcounties, whereas the QUERY_LAYERS=ogi:quad24. Would that have an impact? I would think that the LAYERS and FORMAT would be ignored in the GetFeatureInfo, and are just there to look pretty. But I'm no WMS expert.

Nope, the request is invalid in that case. The GetFeatureInfo should respond properly only if you take the original GetMap request and add
the necessary bits to make it a GetFeatureInfo.
QUERY_LAYERS must also be a subset of LAYERS.

The intent of GetFeatureInfo is to ask the server what was in a certain
pixel postion of a point that it _painted_.

So I guess a service exception is in order, but one that tells you the
request is invalid, not the one you're getting:
http://jira.codehaus.org/browse/GEOS-3209

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.