[Geoserver-devel] [Geoserver SLD rendering issues]

Anyone have any idea about this? Andrea?

The catalina files he talks about are at sigma.openplans.org/temp/catalina.zip (sourceforge won't seem to let you send zip files)

-------- Original Message --------
Subject: Geoserver SLD rendering issues
Date: Tue, 18 Sep 2007 10:19:12 -0700
From: Banks, Nathan <BanksN@anonymised.com>
To: Chris Holmes (E-mail) <cholmes@anonymised.com>, Tim Schaub (E-mail) <tschaub@anonymised.com>
CC: Scott Davis (E-mail) <scott@anonymised.com>

Hello Chris and Tim,

We have been having some ongoing problems with getting Geoserver to correctly and consistently render data via our SLDs. One problem is with the actual drawing of the data and the other deals more with labeling. Additionally we have been seeing problems with WFS requests where we are loading point data layers into the browser (via OpenLayers).

Occasionally in the past we would get a tile generated that would be missing all or part of a feature. For example, to create cased roads we lay down a dark line for the border and a lighter, narrower line for the fill. Sometimes the fill does not get drawn. This problem would generally manifest itself when generating tiles 'on demand' for requests coming via OpenLayers and TileCache. We almost never see this problem when generating tiles via the seed script. This had been rather intermittent until we upgraded to the latest nightly build yesterday which caused severe rendering problems (see attached BadRender.jpg and catalina.zip). We have since backed out to 1.6.0b1.

The labeling issue is also intermittent. In this case certain features are simply not labeled. The attached labels.jpg shows this. The boxes with numbers represent bus routes and is a point feature layer. The boxes are PNGs and the SLD controls which size is drawn based on the length of the route number. The feature is then labeled with the route number. As you can see this works great - most of the time. Sometimes the points don't get labeled even though there seems to be nothing in the way of other labels causing a conflict.

Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).

The only major changes recently have been the addition of solr for search request handling and the use of untiled requests to bring in the route highlights. Both of these seem to work quite well.

If you have any ideas let us know.

Regards,
Nathan

Nathan Banks
GIS Data Analyst
TriMet
4012 SE 17th Ave, GIS3
Portland, OR 97202
E-mail: banksn@anonymised.com
Tel: (503) 962-5646

!DSPAM:4005,46f008b8317541431913854!

(attachments)

labels.jpg
BadRender.jpg

Forgot to CC Nathan and Scott.

Nathan, what version of Java are you using?

If it's Java 6 you might try java 5, as there we've been getting hit in small places with the order of iterator processing changing a bit, there were some assumptions in the code about getting it one way. There's a slight chance this is why it's drawing the white and the brown in the wrong order.

Chris Holmes wrote:

Anyone have any idea about this? Andrea?

The catalina files he talks about are at sigma.openplans.org/temp/catalina.zip (sourceforge won't seem to let you send zip files)

-------- Original Message --------
Subject: Geoserver SLD rendering issues
Date: Tue, 18 Sep 2007 10:19:12 -0700
From: Banks, Nathan <BanksN@anonymised.com>
To: Chris Holmes (E-mail) <cholmes@anonymised.com>, Tim Schaub (E-mail) <tschaub@anonymised.com>
CC: Scott Davis (E-mail) <scott@anonymised.com>

Hello Chris and Tim,

We have been having some ongoing problems with getting Geoserver to correctly and consistently render data via our SLDs. One problem is with the actual drawing of the data and the other deals more with labeling. Additionally we have been seeing problems with WFS requests where we are loading point data layers into the browser (via OpenLayers).

Occasionally in the past we would get a tile generated that would be missing all or part of a feature. For example, to create cased roads we lay down a dark line for the border and a lighter, narrower line for the fill. Sometimes the fill does not get drawn. This problem would generally manifest itself when generating tiles 'on demand' for requests coming via OpenLayers and TileCache. We almost never see this problem when generating tiles via the seed script. This had been rather intermittent until we upgraded to the latest nightly build yesterday which caused severe rendering problems (see attached BadRender.jpg and catalina.zip). We have since backed out to 1.6.0b1.

The labeling issue is also intermittent. In this case certain features are simply not labeled. The attached labels.jpg shows this. The boxes with numbers represent bus routes and is a point feature layer. The boxes are PNGs and the SLD controls which size is drawn based on the length of the route number. The feature is then labeled with the route number. As you can see this works great - most of the time. Sometimes the points don't get labeled even though there seems to be nothing in the way of other labels causing a conflict.

Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).

The only major changes recently have been the addition of solr for search request handling and the use of untiled requests to bring in the route highlights. Both of these seem to work quite well.

If you have any ideas let us know.

Regards,
Nathan

Nathan Banks
GIS Data Analyst
TriMet
4012 SE 17th Ave, GIS3
Portland, OR 97202
E-mail: banksn@anonymised.com
Tel: (503) 962-5646

!DSPAM:4005,46f13e3b41525210051143!

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4005,46f13e3b41525210051143!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,46f13e3b41525210051143!

We are, indeed, using Java6. Have been since day one. Interesting that it was working correctly and fails with a more recent nightly build.

Thanks for the tip,
s

Scott Davis
scott@anonymised.com

On Sep 19, 2007, at 9:28 AM, Chris Holmes wrote:

Forgot to CC Nathan and Scott.

Nathan, what version of Java are you using?

If it's Java 6 you might try java 5, as there we've been getting hit in small places with the order of iterator processing changing a bit, there were some assumptions in the code about getting it one way. There's a slight chance this is why it's drawing the white and the brown in the wrong order.

Chris Holmes wrote:

Anyone have any idea about this? Andrea?
The catalina files he talks about are at sigma.openplans.org/temp/catalina.zip (sourceforge won't seem to let you send zip files)
-------- Original Message --------
Subject: Geoserver SLD rendering issues
Date: Tue, 18 Sep 2007 10:19:12 -0700
From: Banks, Nathan <BanksN@anonymised.com>
To: Chris Holmes (E-mail) <cholmes@anonymised.com>, Tim Schaub (E-mail) <tschaub@anonymised.com>
CC: Scott Davis (E-mail) <scott@anonymised.com>
Hello Chris and Tim,
We have been having some ongoing problems with getting Geoserver to correctly and consistently render data via our SLDs. One problem is with the actual drawing of the data and the other deals more with labeling. Additionally we have been seeing problems with WFS requests where we are loading point data layers into the browser (via OpenLayers).
Occasionally in the past we would get a tile generated that would be missing all or part of a feature. For example, to create cased roads we lay down a dark line for the border and a lighter, narrower line for the fill. Sometimes the fill does not get drawn. This problem would generally manifest itself when generating tiles 'on demand' for requests coming via OpenLayers and TileCache. We almost never see this problem when generating tiles via the seed script. This had been rather intermittent until we upgraded to the latest nightly build yesterday which caused severe rendering problems (see attached BadRender.jpg and catalina.zip). We have since backed out to 1.6.0b1.
The labeling issue is also intermittent. In this case certain features are simply not labeled. The attached labels.jpg shows this. The boxes with numbers represent bus routes and is a point feature layer. The boxes are PNGs and the SLD controls which size is drawn based on the length of the route number. The feature is then labeled with the route number. As you can see this works great - most of the time. Sometimes the points don't get labeled even though there seems to be nothing in the way of other labels causing a conflict.
Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).
The only major changes recently have been the addition of solr for search request handling and the use of untiled requests to bring in the route highlights. Both of these seem to work quite well.
If you have any ideas let us know.
Regards,
Nathan
Nathan Banks
GIS Data Analyst
TriMet
4012 SE 17th Ave, GIS3
Portland, OR 97202
E-mail: banksn@anonymised.com
Tel: (503) 962-5646
!DSPAM:4005,46f13e3b41525210051143!
------------------------------------------------------------------------
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
!DSPAM:4005,46f13e3b41525210051143!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,46f13e3b41525210051143!
<cholmes.vcf>

It may not be that at all, but it's worth a shot. I do agree it would be odd if it fails with a more recent nightly build, so it may just be due to other rendering changes, of which there have been quite a few. Sorry the bleeding edge is biting you guys, we'll do our best to get things fixed up and thanks for the report.

Chris

Scott Davis wrote:

We are, indeed, using Java6. Have been since day one. Interesting that it was working correctly and fails with a more recent nightly build.

Thanks for the tip,
s

Scott Davis
scott@anonymised.com

On Sep 19, 2007, at 9:28 AM, Chris Holmes wrote:

Forgot to CC Nathan and Scott.

Nathan, what version of Java are you using?

If it's Java 6 you might try java 5, as there we've been getting hit in small places with the order of iterator processing changing a bit, there were some assumptions in the code about getting it one way. There's a slight chance this is why it's drawing the white and the brown in the wrong order.

Chris Holmes wrote:

Anyone have any idea about this? Andrea?
The catalina files he talks about are at sigma.openplans.org/temp/catalina.zip (sourceforge won't seem to let you send zip files)
-------- Original Message --------
Subject: Geoserver SLD rendering issues
Date: Tue, 18 Sep 2007 10:19:12 -0700
From: Banks, Nathan <BanksN@anonymised.com>
To: Chris Holmes (E-mail) <cholmes@anonymised.com>, Tim Schaub (E-mail) <tschaub@anonymised.com>
CC: Scott Davis (E-mail) <scott@anonymised.com>
Hello Chris and Tim,
We have been having some ongoing problems with getting Geoserver to correctly and consistently render data via our SLDs. One problem is with the actual drawing of the data and the other deals more with labeling. Additionally we have been seeing problems with WFS requests where we are loading point data layers into the browser (via OpenLayers).
Occasionally in the past we would get a tile generated that would be missing all or part of a feature. For example, to create cased roads we lay down a dark line for the border and a lighter, narrower line for the fill. Sometimes the fill does not get drawn. This problem would generally manifest itself when generating tiles 'on demand' for requests coming via OpenLayers and TileCache. We almost never see this problem when generating tiles via the seed script. This had been rather intermittent until we upgraded to the latest nightly build yesterday which caused severe rendering problems (see attached BadRender.jpg and catalina.zip). We have since backed out to 1.6.0b1.
The labeling issue is also intermittent. In this case certain features are simply not labeled. The attached labels.jpg shows this. The boxes with numbers represent bus routes and is a point feature layer. The boxes are PNGs and the SLD controls which size is drawn based on the length of the route number. The feature is then labeled with the route number. As you can see this works great - most of the time. Sometimes the points don't get labeled even though there seems to be nothing in the way of other labels causing a conflict.
Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).
The only major changes recently have been the addition of solr for search request handling and the use of untiled requests to bring in the route highlights. Both of these seem to work quite well.
If you have any ideas let us know.
Regards,
Nathan
Nathan Banks
GIS Data Analyst
TriMet
4012 SE 17th Ave, GIS3
Portland, OR 97202
E-mail: banksn@anonymised.com
Tel: (503) 962-5646

------------------------------------------------------------------------
-------------------------------------------------------------------------

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
!DSPAM:4005,46f13e3b41525210051143!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,46f13e3b41525210051143!
<cholmes.vcf>

!DSPAM:4005,46f14d0169111804284693!

Chris Holmes ha scritto:

Anyone have any idea about this? Andrea?

The catalina files he talks about are at sigma.openplans.org/temp/catalina.zip (sourceforge won't seem to let you send zip files)

-------- Original Message --------
Subject: Geoserver SLD rendering issues
Date: Tue, 18 Sep 2007 10:19:12 -0700
From: Banks, Nathan <BanksN@anonymised.com>
To: Chris Holmes (E-mail) <cholmes@anonymised.com>, Tim Schaub (E-mail) <tschaub@anonymised.com>
CC: Scott Davis (E-mail) <scott@anonymised.com>

Hello Chris and Tim,

We have been having some ongoing problems with getting Geoserver to correctly and consistently render data via our SLDs. One problem is with the actual drawing of the data and the other deals more with labeling. Additionally we have been seeing problems with WFS requests where we are loading point data layers into the browser (via OpenLayers).

Hum, yeah, a user reported something similar, but it seemed the client
was closing the connection before the server could read the whole
request... strange. I have no way to reproduce it... but then again, we
still haven't upgraded to OpenLayers 2.5, so it may be related...

Occasionally in the past we would get a tile generated that would be missing all or part of a feature. For example, to create cased roads we lay down a dark line for the border and a lighter, narrower line for the fill. Sometimes the fill does not get drawn. This problem would generally manifest itself when generating tiles 'on demand' for requests coming via OpenLayers and TileCache. We almost never see this problem when generating tiles via the seed script. This had been rather intermittent until we upgraded to the latest nightly build yesterday which caused severe rendering problems (see attached BadRender.jpg and catalina.zip). We have since backed out to 1.6.0b1.

The problem you're experiencing looks like http://jira.codehaus.org/browse/GEOS-1338
Are you using the meta tiler?

The labeling issue is also intermittent. In this case certain features are simply not labeled. The attached labels.jpg shows this. The boxes with numbers represent bus routes and is a point feature layer. The boxes are PNGs and the SLD controls which size is drawn based on the length of the route number. The feature is then labeled with the route number. As you can see this works great - most of the time. Sometimes the points don't get labeled even though there seems to be nothing in the way of other labels causing a conflict.

This is new to me, I don't really know what to say... I need some
way to consistently reproduce it. Can you isolate a subset of your
data that produces the issue and give it to me along with styles
and requests?

Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).

I did not get any attachment besides the two images, can you resend, eventually by private mail?
Cheers
Andrea

Chris Holmes ha scritto:

Finally we have been seeing an increased number of problems with WFS requests. We utilize these to bring in data about things like bus stops, rail stations, etc. in order to populate popup windows. These only get called at close-in zoom levels to minimize the actual numbers of features requested. Initially this seemed to work reasonably well but now we are seeing, upon the initial zoom to the level where the WFS request is made, error messages popping up in the browser saying "Unhandled request return Internal Server Error". This is accompanied by 503 errors in catalina.out (attached).

Most of the stack traces I can see have messages like:
* Caused by: java.net.SocketException: Connection reset
* ClientAbortException: java.net.SocketException: Broken pipe
These are the client closing the connection before GeoServer had
an occasion to write back to it (WMS requests). We should avoid
dumping the full stack trace at the WARN level thought...

The there is this one which looks scary:
java.lang.NoClassDefFoundError: Could not initialize class net.opengis.wfs.WfsPackage$Literals
  at net.opengis.wfs.impl.GetFeatureTypeImpl.eStaticClass(GetFeatureTypeImpl.java:193)
  at org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)
  at org.geotools.xml.EMFUtils.feature(EMFUtils.java:111)
  at org.geotools.xml.EMFUtils.has(EMFUtils.java:30)
  at org.geoserver.wfs.kvp.WFSKvpRequestReader.read(WFSKvpRequestReader.java:80)
  at org.geoserver.wfs.kvp.GetFeatureKvpRequestReader.read(GetFeatureKvpRequestReader.java:54)

Eek... it seems one jar is missing or incomplete? Justin?

Then I see this one repeated various time, and it looks very scary:

17 Sep 14:35:08 WARN [geoserver.ows] -
java.lang.OutOfMemoryError: PermGen space

This one triggers in Eclipse too due to the permanent generation not being big enough to host all of the classes GeoServer is using.
Some workarounds for this one here:
http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror
The usual one is to add -XX:MaxPermSize=128m to the JVM options,
never tried the others.

The error you mentions is even more strange... look here:

java.io.IOException: Server returned HTTP response code: 503 for URL: http://localhost/geoserver/wfs?typename=trimet%3Az_parkride&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A2913&BBOX=7671031%2C699234%2C7679343%2C703618
org.codehaus.groovy.runtime.InvokerInvocationException: java.io.IOException: Server returned HTTP response code: 503 for URL: http://localhost/geoserver/wfs?typename=trimet%3Az_parkride&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A2913&BBOX=7671031%2C699234%2C7679343%2C703618
  at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:77)
  at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:694)
  at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:616)
  at org.codehaus.groovy.grails.commons.metaclass.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:742)
  at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:506)
  at groovy.lang.Closure.call(Closure.java:209)
  at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleAction(SimpleGrailsControllerHelper.java:474)
  at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:288)
  at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:156)
  at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:88)
  at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:45)
  at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:241)
  at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:736)
  at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396)
  at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
  at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469)
  at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
  at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
  at org.codehaus.groovy.grails.web.mapping.filter.UrlMappingsFilter.doFilterInternal(UrlMappingsFilter.java:96)
  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119)
  at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterInternal(GrailsWebRequestFilter.java:54)
  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:78)
  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
  at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)

I guess you have a web frontend done in grails running in that tomcat?
Anyways, not GeoServer related, but may explain permgen exhaustion, you should be able to get around it by increasing the permgen size.

Going forward, I see this one:

Caused by: org.geotools.data.DataSourceException: An exception occurred while parsing WKB data
  at org.geotools.data.postgis.attributeio.PgWKBAttributeIO.WKB2Geometry(PgWKBAttributeIO.java:113)
  at org.geotools.data.postgis.attributeio.PgWKBAttributeIO.read(PgWKBAttributeIO.java:184)
  at org.geotools.data.jdbc.QueryData.read(QueryData.java:212)
  at org.geotools.data.jdbc.JDBCFeatureReader.readFeature(JDBCFeatureReader.java:107)
  at org.geotools.data.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:88)
  at org.geotools.data.store.FeatureReaderIterator.next(FeatureReaderIterator.java:64)
  ... 54 more
Caused by: java.lang.IllegalArgumentException: points must form a closed linestring
  at com.vividsolutions.jts.geom.LinearRing.validateConstruction(LinearRing.java:95)
  at com.vividsolutions.jts.geom.LinearRing.<init>(LinearRing.java:90)
  at com.vividsolutions.jts.geom.GeometryFactory.createLinearRing(GeometryFactory.java:324)
  at com.vividsolutions.jts.io.WKBReader.readLinearRing(WKBReader.java:217)
  at com.vividsolutions.jts.io.WKBReader.readPolygon(WKBReader.java:227)
  at com.vividsolutions.jts.io.WKBReader.readGeometry(WKBReader.java:173)
  at com.vividsolutions.jts.io.WKBReader.readMultiPolygon(WKBReader.java:265)
  at com.vividsolutions.jts.io.WKBReader.readGeometry(WKBReader.java:179)
  at com.vividsolutions.jts.io.WKBReader.read(WKBReader.java:137)
  at com.vividsolutions.jts.io.WKBReader.read(WKBReader.java:118)
  at org.geotools.data.postgis.attributeio.PgWKBAttributeIO.WKB2Geometry(PgWKBAttributeIO.java:111)
  ... 59 more

Ah, here we have an invalid polygon in your db, this may explain some
rendering issue (this polygon won't be rendered).

Going forward, we have this one:

Caused by: java.lang.IllegalArgumentException: The specified dimensional parameter is non-positive.
  at javax.media.jai.ImageLayout.setHeight(ImageLayout.java:447)
  at com.sun.media.jai.opimage.FilteredSubsampleOpImage.layoutHelper(FilteredSubsampleOpImage.java:424)
  at com.sun.media.jai.opimage.FilteredSubsampleOpImage.<init>(FilteredSubsampleOpImage.java:459)
  at com.sun.media.jai.opimage.FilteredSubsampleRIF.create(FilteredSubsampleRIF.java:74)

This is a request to render a raster... hum, can we have a look at it?

That's all folks :slight_smile:
Cheers
Andrea