I've recently switched from a patched up 1.5.0 beta2 to 1.5.1, and to my utter surprise I've found out that a WFS query of mine didn't select what it used to with the old version of GeoServer.
After many a test, I've restricted the anomaly to this: when I use data stored in EPSG:3034 (hence with a 4.000.000 false easting) the false easting is ignored in WFS requests, while WMS requests work as usual.
An example my clarify the matter:
This WMS request shows the marker as they should:
http://sidimar-dev:8080/geoserver/wms?request=GetMap&version=1.1.1&format=image/png
&srs=EPSG:3034
&bbox=6322140.796348,293329.19491,10375401.236205,2995502.821481
&width=600&height=400&transparent=false&bgcolor=0xB6C4E7
&sld=http://82.91.119.42:8080/cocoon/sa/sld--sdm:GEOAVVISTAMENTI-sdm:GEOCOSTA--briozoi-costa--it.sld
&wfs=http://sidimar-dev:8080/geoserver/wfs
This WFS request, though, shows nothing (the bbox is the same):
http://sidimar-dev:8080/geoserver/wfs?request=GetFeature&version=1.0.0
&propertyname=*&featureversion=1&typename=sdm:GEOAVVISTAMENTI
&filter=
<ogc:Filter
xmlns:ogc="http://www.opengis.net/ogc" xmlns:str="http://exslt.org/strings">
<ogc:And>
<ogc:BBOX>
<ogc:PropertyName>SHAPE</ogc:PropertyName>
<gml:Box xmlns:gml="http://www.opengis.net/gml">
<gml:coordinates>6322140.796348,293329.19491 10375401.236205,2995502.821481</gml:coordinates>
</gml:Box>
</ogc:BBOX>
<ogc:Or>
<PropertyIsEqualTo>
<PropertyName>TAXA</PropertyName>
<Literal>Briozoi</Literal>
</PropertyIsEqualTo>
<PropertyIsEqualTo>
</ogc:Or>
</ogc:And>
</ogc:Filter>
If I add 4.000.000 or so to the WFS request BBOX, the points are returned as they should.
The anomaly doesn't happen with UTM, only with EPSG:3034 (Lambert Conformal Conic).
My environment:
- Fedora Core 5
- JVM 1.5
- GeoServer 1.5.1
- DB2 9 with Spatial Extender (yes all vector data are stored in there).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Luca Morandini wrote:
> <PropertyIsEqualTo>
> <PropertyName>TAXA</PropertyName>
> <Literal>Briozoi</Literal>
> </PropertyIsEqualTo>
> <PropertyIsEqualTo>
^^^^^^^^^^^^^^^^^^^
Please ignore the repeated PropertyIsEqualTo element (just a typo).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Luca Morandini ha scritto:
I've recently switched from a patched up 1.5.0 beta2 to 1.5.1, and to my utter surprise I've found out that a WFS query of mine didn't select what it used to with the old version of GeoServer.
After many a test, I've restricted the anomaly to this: when I use data stored in EPSG:3034 (hence with a 4.000.000 false easting) the false easting is ignored in WFS requests, while WMS requests work as usual.
Arg, how is the layer setup in DB2 (which CRS is declared there?).
In 1.5.0 final we setup things so that if a layer has a CRS declared
in the datastore, we trust it, and we do eventually reproject to the
one declared in FeatureType configuration page. I've been regretting
this decision so far, we'll probably move back to have CRS forcing instead of reprojecting (we just cannot keep the native CRS unless
it's strictly equivalent to an EPSG official code).
Luca, any chance you can give me a dump of that DB2 database, or
a shapefile and instructions to set it up just like yours, so
that I can make sure things are working when I'll try to make
a fix? (and so that I can make sure my diagnosis is right, it may
well be another issue).
In the meantine, can you try out a 1.5.x nightly? (June 29 onwards
should be ok).
http://geo.openplans.org/nightly/1.5.x/
I turned back the WFS code to force the crs instead of reprojecting in the GetFeature code, but not sure I really fixed all places.
Cheers
Andrea
Andrea Aime wrote:
Arg, how is the layer setup in DB2 (which CRS is declared there?).
In 1.5.0 final we setup things so that if a layer has a CRS declared
in the datastore, we trust it, and we do eventually reproject to the
one declared in FeatureType configuration page.
This is consistent with the symptoms I've seen.
Luca, any chance you can give me a dump of that DB2 database, or
a shapefile and instructions to set it up just like yours, so
that I can make sure things are working when I'll try to make
a fix? (and so that I can make sure my diagnosis is right, it may
well be another issue).
I suppose (see the exception stack at the end of this message, caused by an WMS request) the coordinate system definition is somehow wrong, though Spatial Extender didn't complain when I created it... I'll investigate the matter.
In the meantine, can you try out a 1.5.x nightly? (June 29 onwards
should be ok).
http://geo.openplans.org/nightly/1.5.x/
I turned back the WFS code to force the crs instead of reprojecting in the GetFeature code, but not sure I really fixed all places.
Well, now the WFS layer show... but WMS and WFS are still shifted.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
15:35:01,008 INFO [STDOUT] 2187531 [AVVERTENZA] org.vfny.geoserver.ServiceException - encountered error: null error:Translator error
StackTrace: javax.xml.transform.TransformerException: Translator error
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:130)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:105)
at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(GML2FeatureResponseDelegate.java:212)
at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureResponse.java:127)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:582)
at org.vfny.geoserver.servlets.AbstractService.doGet(AbstractService.java:315)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:192)
at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:52)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: Exception occurred while computing reprojected bounds
at org.geotools.data.crs.ReprojectFeatureResults.getBounds(ReprojectFeatureResults.java:183)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode(FeatureTransformer.java:407)
at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(TransformerBase.java:625)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.java:293)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:126)
... 37 more
Caused by: org.geotools.data.DataSourceException: Problem moving on to the next attribute
at org.geotools.data.jdbc.QueryData.hasNext(QueryData.java:318)
at org.geotools.data.jdbc.JDBCFeatureReader.hasNext(JDBCFeatureReader.java:74)
at org.geotools.data.MaxFeatureReader.hasNext(MaxFeatureReader.java:78)
at org.geotools.data.crs.ReprojectFeatureReader.hasNext(ReprojectFeatureReader.java:184)
at org.geotools.data.crs.ReprojectFeatureResults.getBounds(ReprojectFeatureResults.java:175)
... 42 more
Caused by: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -443, SQLSTATE: 38SSH, SQLERRMC: DB2GSE.ST_ASTEXT;ST_ASTEXT;GSE3417N Invalid coordsys definition.
at com.ibm.db2.jcc.c.wf.b(wf.java:2952)
at com.ibm.db2.jcc.c.wf.a(wf.java:2935)
at com.ibm.db2.jcc.b.gb.a(gb.java:709)
at com.ibm.db2.jcc.b.hb.a(hb.java:220)
at com.ibm.db2.jcc.b.hb.c(hb.java:33)
at com.ibm.db2.jcc.b.x.a(x.java:34)
at com.ibm.db2.jcc.b.j.Ib(j.java:257)
at com.ibm.db2.jcc.c.wf.R(wf.java:2805)
at com.ibm.db2.jcc.b.d.f(d.java:1485)
at com.ibm.db2.jcc.c.s.a(s.java:191)
at com.ibm.db2.jcc.c.wf.c(wf.java:267)
at com.ibm.db2.jcc.c.wf.next(wf.java:234)
at org.geotools.data.jdbc.QueryData.hasNext(QueryData.java:315)
... 46 more
Luca Morandini wrote:
I suppose (see the exception stack at the end of this message, caused by an WMS request) the coordinate system definition is somehow wrong, though Spatial Extender didn't complain when I created it... I'll investigate the matter.
I did investigate, and found out the Well-Known Textual definition of a coordinate system is not *that* well known to Spatial Extender... after a few silly changes (such as "Lambert_Conformal_Conic" instead of "Lambert Conic Conformal") the coordinate system was accepted and the problem didn't show up anymore (previously I had copied the EPSG:3034 definition found in GeoServer under Spatial Extender verbatim).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Luca Morandini ha scritto:
Luca Morandini wrote:
I suppose (see the exception stack at the end of this message, caused by an WMS request) the coordinate system definition is somehow wrong, though Spatial Extender didn't complain when I created it... I'll investigate the matter.
I did investigate, and found out the Well-Known Textual definition of a coordinate system is not *that* well known to Spatial Extender... after a few silly changes (such as "Lambert_Conformal_Conic" instead of "Lambert Conic Conformal") the coordinate system was accepted and the problem didn't show up anymore (previously I had copied the EPSG:3034 definition found in GeoServer under Spatial Extender verbatim).
Crazy stuff, but I've seen worse in Oracle I guess (their WKT syntax
for TOWGS84 parameters is totally wrong).
Anyways, Adler, is there any suggestion we can give to people trying
to use DB2 and Geoserver so that nobody else falls in this naming
trap? I don't know, where to look to find a name DB2 will understand,
any function that can be used to validate a CRS definition to make
sure DB2 likes it?
Cheers
Andrea