Yeroc ha scritto:
Luca,
Another alternative is to use the Java OSCache library. It implements a
servlet filter which is fairly straightforward to configure. If you're a
Java shop you should be able figure out what you have to add to the
GeoServer web.xml (just add the oscache stuff as a servlet filter on /wms*)
in order to get it working...
Andre, my experience has been the opposite (regarding bandwidth being the
bottleneck). Maybe we're doing something wrong but we're finding that
implementing a basemap which extracts from multiple shape files is too slow
without caching. (This is with GeoServer v1.4.0... if v1.5 contains
tremendous performance improvements I'd like to hear about it.)
Not tremendous, just a little bit. Have a look at the Geoserver in production environemnt guide:
http://docs.codehaus.org/display/GEOSDOC/GeoServer+in+Production+Environment
One of the thing we state is to never use shapefiles for production, but
postgis, if you can. Oh, have you tried to use indexing?
Finally, just for shapefiles, there's a custom renderer we could use that's quite a lot faster (it's the one used by uDig) but not as well
tested as the one we're using now (and would speed up just shapefiles).
Can you elaborate on the rendering fixes (which I assume are implemented in
v1.5)? The biggest problem for me is the rendering of labels. Particularly
when rendering a label for a polygon (say State or Province labels). Once
you zoom in you end up the same label on multiple tiles on your display
which looks quite goofy. Do you know if this particular issue has been
fixed?
No, it hasn't. Once we have TMS (tiled map server) we'll be able to pre-render tiles on a cache, using meta-tiles for rendering which we then split up. A meta tile is a group of tiles, say 3x3, and this will
mitigate the effect you see since labels will repeat only in each meta-tile.
To avoid completely the effect we would have to choose a fixed labeling point per geometry instead of trying to adjust it to the current rendering area. Hmm.... in fact it's a rendering option we could add, provided you're not using group labeling at the same time.
The risk is, that if a label falls in between two tiles, it'll never be
rendered at all (rendering labels that fall on tile edges causes issues
with label conflict resolution and label grouping, as noted in the
research doc you're referring to).
The only real solution I can think of to have good consistent labeling is to preprocess the whole set of labelled layers in one go, and create a new data set that contains labels for the current resolution.
Then render that dataset without any extra magic, no conflict resolution
and the like. It'll be fast and good, the catch being that you'll need
one of such datasets per layer and per zoom level.
Is the information at
http://docs.codehaus.org/display/GEOS/Rendering+and+tiling+issues+research
up-to-date?
As far as I know, yes. Are you referring to something in particular?
Cheers
Andrea