Hi, as you may know, Geoserver has issues dealing properly with tiled requests, in that labels and other symbols may be cut, moved or replicated from tile to tile. I'm cc'ing gt2-devel because uDiggers may be interested in this discussion, since it would hit their rendering subsystem as well.
There are two issues here ar work: a) labelling manager tries to fit all labels in the currently rendered bbox, which generates the "jumping labels" issue. b) some symbols are not rendered because their geometry falls out of the current bbox, this is an issue because its rendering may be bigger than the geomtry (think points rendered as big circles). b) can be handled by extending the area that gets really rendered using the so called (in ka-map and tile-cache) meta-buffer. The users specifies a buffer distance used to enlarge the current rendering area, in order to catch the extra geometries. The buffer is specified in pixels, which makes sense since rendering elements widths are pixels too. So, to handle this, we can simply add a custom parameter to WMS requests. We keep on returning the same image, but we use a larger area than the rendered one to look for geometries to be rendered (a larger bbox filter). The StreamingRender should be extended to get a meta-buffer hint as well. a) is probably the wrong default behavior to start with. I mean, bbox fitting is ok during printing, but both uDig and Geoserver do render images that are parts of a bigger map. One way would be to simply have the labels ignore bbox limits unless an "optimize for printing" flag is set (as an extra parameter, useful when rendering to PDF for example). This is easy, but may have a glitch a the actual map borders, because labels may well go beyond the total MapContext area... so another way could be to keep on adjusting label position, but against the MapContext bbox instead of using the current rendering bbox. This should be ok for uDig, less so for Geoserver, since MapContext gets re-created (we cannot cache the bbox as a result), and usually we don't see the real map extent, clients such as OpenLayer make separate request for separate layers. So, the overall bbox may well become a custom parameter as well, so that we can use a global bbox on the web as well, and avoid having to recompute bounds at each request. I'd like to have feedback on this, what do you think? Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
