Re: [Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data
On Fri, Nov 25, 2011 at 9:06 PM, Ryan Clark wrote: > The tables I'm dealing with are actually just points, so I don't think > that it should be any extended geometry type. I found that I can use > Geoserver to publish the layer by using the SQL View functionality, and > specifying > *select * from sde.azwellheaders* > This is really odd, since the same geometry reading code will be used by this sql view (same as the table used). Unless hmmm... is the column registred in "geography_columns"? If so, can you dump the contents of geographic_columns for that table/geometry? More in general, would it be possible for you to give me a dump of that database, or even just a portion to replicate the problem? Cheers Andrea -- --- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf --- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data
The tables I'm dealing with are actually just points, so I don't think that it should be any extended geometry type. I found that I can use Geoserver to publish the layer by using the SQL View functionality, and specifying /select * from sde.azwellheaders/ Then, if I define the geometry type as point and give it the SRID (4326), the layer works fine. It works as well if I leave the geometry type as "GEOMETRY" and specify the SRID. The SQL view UI doesn't seem to be able to guess the SRID properly. This is reasonable workaround, but I'm concerned about the trouble -- I was really hoping to be able to leverage SDE on top of PostGIS as a simple way to move all this ESRI data into an open format. For the interested reader, the logged error is below. Thanks, Ryan 2011-11-23 16:18:03,072 ERROR [geoserver.ows] - org.geoserver.platform.ServiceException: error:Translator error at org.geoserver.wfs.xml.GML2OutputFormat.encode(GML2OutputFormat.java:286) at org.geoserver.wfs.xml.GML2OutputFormat.write(GML2OutputFormat.java:295) at org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:141) at org.geoserver.ows.Dispatcher.response(Dispatcher.java:757) at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:238) 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:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:23) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:74) at org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:45) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:49) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:394) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406) at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406) at org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406) at org.springframework.security.ui.basicauth.BasicProcessingFilter.doFilterHttp(BasicProcessingFilter.java:174) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilte
Re: [Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data
On Thu, Nov 24, 2011 at 12:45 AM, Ryan Clark wrote: > I'm working on a database that has been generated as an ArcSDE database > on top of PostgreSQL and PostGIS. The database was built from a PostGIS > template and the featureclasses in the database use the PostGIS geometry > type. > > On the database end, everything seems to be working fine. Queries like > *SELECT ST_asText(shape) as WKT, geometrytype(shape) as TYPE from > sde.azwellheaders > *... work just fine. The public.geometry_columns table is populated > correctly, including records for the shape fields from all the > featureclasses. I did notice that the public.geometry_columns.type field > just says "GEOMETRY", instead giving a specific geometry type, but I think > that's valid, right? > It is. > > I tried building layers in Geoserver from a few of these featureclasses. > The UI correctly detects the SRID and can correctly compute the bounds from > the data. However, once the layer is published and I look at the Layer > Preview, click on GML for my new layer, I get the following WFS response: > > error:Translator error Translator error Error reading Features > org.geotools.data.DataSourceException: An exception occurred while parsing > WKB data An exception occurred while parsing WKB data Unknown WKB type 93 > > Haven't seen this one before, but it may be that the geometry is using some extended type that is not supported by JTS, and thus by GeoServer. For example, it would fail if the geometries were arcs (as opposed to be made of straight segments). Cheers Andrea -- --- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf --- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data
I'm working on a database that has been generated as an ArcSDE database on top of PostgreSQL and PostGIS. The database was built from a PostGIS template and the featureclasses in the database use the PostGIS geometry type. On the database end, everything seems to be working fine. Queries like /SELECT ST_asText(shape) as WKT, geometrytype(shape) as TYPE from sde.azwellheaders /... work just fine. The public.geometry_columns table is populated correctly, including records for the shape fields from all the featureclasses. I did notice that the public.geometry_columns.type field just says "GEOMETRY", instead giving a specific geometry type, but I think that's valid, right? I tried building layers in Geoserver from a few of these featureclasses. The UI correctly detects the SRID and can correctly compute the bounds from the data. However, once the layer is published and I look at the Layer Preview, click on GML for my new layer, I get the following WFS response: error:Translator error Translator error Error reading Features org.geotools.data.DataSourceException: An exception occurred while parsing WKB data An exception occurred while parsing WKB data Unknown WKB type 93 I'm using Geoserver 2.1.2 and PostgreSQL 8.3. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
