Hello list,
I noticed slowdowns when geoserver is rendering only a (very) small part of a polygon, rapidly degrading as the piece gets smaller. I’m talking perhaps 1/1000th (or perhaps a bit less) of a polygon when the issue starts to be really noticable. Rendering the whole polygon can be many times faster than rendering just a part.
I could try to get more data on this, but wanted to get this info out and want to know if this is a known/expected behaviour? Can it be optimised?
The datastore I’m using is PostGIS, but from what I can see from monitoring the system it’s geoserver that has to work alot harder not postgresql.
/Björn
Björn Harrtell ha scritto:
Hello list,
I noticed slowdowns when geoserver is rendering only a (very) small part of a polygon, rapidly degrading as the piece gets smaller. I'm talking perhaps 1/1000th (or perhaps a bit less) of a polygon when the issue starts to be really noticable. Rendering the whole polygon can be many times faster than rendering just a part.
I could try to get more data on this, but wanted to get this info out and want to know if this is a known/expected behaviour? Can it be optimised?
Hmm, it's odd, but it makes _some_ sense. When you zoom in the level
of on the fly generalization goes down, so the java2d pipeline gets
feed with more and more points. We don't do a preventive clip of the
geometry because that's extremely expensive to do in JTS, and hope
that java2d is smart enough to perform an efficient clipping by itself,
but apparently it's not, at least in the case of polygons?
Anyways, that's just a guess. If you could drop me a sample of your
data and styles I can try and double check.
Cheers
Andrea
Thanks, it’s interesting to know about how the generalization process works. I couldn’t at first reproduce the issue with another install and isolated data, but I think I’m pretty sure I’ve pinpointed what is going on.
With just simple styling, like a solid line and fill there is no noticable slowdown… So when investigating the issue I noticed that the featureType where I discovered the problem used dash-stroke styling like this:
#000000
2.0
10.0 5 5 5 5
The style used has no fill, but I think it’s pretty safe to assume that the issue is directly related to the stroke styling.
I’ve tried this on a separate installation of geoserver 1.6.4 and with a shapefile I made just consisting of a few polygons. Number of vertices on the polygons seem to have no direct importance. If you need it I can mail you the shapefile.
The slowdown seem exponential or something when zooming into the polygon, and at full scale it renders about as fast as with simple styling. I start noticing the slowdowns when viewing about 1:10 of the polygon and from there it rapidly degrades.
/Björn
On Tue, Aug 26, 2008 at 8:49 AM, Andrea Aime <aaime@…1671…> wrote:
Björn Harrtell ha scritto:
Hello list,
I noticed slowdowns when geoserver is rendering only a (very) small part of a polygon, rapidly degrading as the piece gets smaller. I’m talking perhaps 1/1000th (or perhaps a bit less) of a polygon when the issue starts to be really noticable. Rendering the whole polygon can be many times faster than rendering just a part.
I could try to get more data on this, but wanted to get this info out and want to know if this is a known/expected behaviour? Can it be optimised?
Hmm, it’s odd, but it makes some sense. When you zoom in the level
of on the fly generalization goes down, so the java2d pipeline gets
feed with more and more points. We don’t do a preventive clip of the
geometry because that’s extremely expensive to do in JTS, and hope
that java2d is smart enough to perform an efficient clipping by itself,
but apparently it’s not, at least in the case of polygons?
Anyways, that’s just a guess. If you could drop me a sample of your
data and styles I can try and double check.
Cheers
Andrea
Björn Harrtell ha scritto:
Thanks, it's interesting to know about how the generalization process works. I couldn't at first reproduce the issue with another install and isolated data, but I think I'm pretty sure I've pinpointed what is going on.
With just simple styling, like a solid line and fill there is no noticable slowdown... So when investigating the issue I noticed that the featureType where I discovered the problem used dash-stroke styling like this:
<PolygonSymbolizer>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">2.0</CssParameter>
<CssParameter name="stroke-dasharray">10.0 5 5 5 5</CssParameter>
</Stroke>
</PolygonSymbolizer>
The style used has no fill, but I think it's pretty safe to assume that the issue is directly related to the stroke styling.
I've tried this on a separate installation of geoserver 1.6.4 and with a shapefile I made just consisting of a few polygons. Number of vertices on the polygons seem to have no direct importance. If you need it I can mail you the shapefile.
The slowdown seem exponential or something when zooming into the polygon, and at full scale it renders about as fast as with simple styling. I start noticing the slowdowns when viewing about 1:10 of the polygon and from there it rapidly degrades.
Yes, if you could provide me, by private mail, with the shapefile and
the SLD, that would be most appreciated.
Cheers
Andrea
Andrea Aime ha scritto:
Björn Harrtell ha scritto:
Thanks, it's interesting to know about how the generalization process works. I couldn't at first reproduce the issue with another install and isolated data, but I think I'm pretty sure I've pinpointed what is going on.
With just simple styling, like a solid line and fill there is no noticable slowdown... So when investigating the issue I noticed that the featureType where I discovered the problem used dash-stroke styling like this:
<PolygonSymbolizer>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">2.0</CssParameter>
<CssParameter name="stroke-dasharray">10.0 5 5 5 5</CssParameter>
</Stroke>
</PolygonSymbolizer>
The style used has no fill, but I think it's pretty safe to assume that the issue is directly related to the stroke styling.
I've tried this on a separate installation of geoserver 1.6.4 and with a shapefile I made just consisting of a few polygons. Number of vertices on the polygons seem to have no direct importance. If you need it I can mail you the shapefile.
The slowdown seem exponential or something when zooming into the polygon, and at full scale it renders about as fast as with simple styling. I start noticing the slowdowns when viewing about 1:10 of the polygon and from there it rapidly degrades.
Yes, if you could provide me, by private mail, with the shapefile and
the SLD, that would be most appreciated.
Björn,
thanks for the sample data. I managed to reproduce the problem and tracked it down, unfortunately, to a JVM issue that Sun considers
"low priority":
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6574155
I'll see if I can provide a work around.
Cheers
Andrea