Andrea Aime wrote: > 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. > a.2) Need to pay attention to "flickering" labels as zoom levels increase (ie when labels are dense we need to throw out labels in a systematic, not random fashion, in order to make room). Dave did some work with setting priorities (ie rank cities by population), but more can be done to make this kind of thing stable.
My best answer is to: 1 queue tiles into lots of 3 by 3 2 share a label buffer when rendering the 9 tiles 3 set the label buffer size (say 10000 ) 4 label as normal, until ..the buffer size is reached then reduce according to one of the following strategies: - throw out every second one (wash rinse repeat); think this is what is currently done and is not stable during zoom - throw out based on hashcode mask, and with 1 to throw out half, on repeat mask with 3, then 7 etc... this is stable during zoom > 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). > Your meta-buffer sounds fine. > 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. > Sounds like a good rendering specific parameter, but an alternative would be to be smart. ie. when making the request for point locations take the symbol size into account (ie do the buffering based on the SLD so streaming renderer is always correct and no magic is needed). This would at least help udig. > 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. > I was under the impression that the queue of 3x3 was used, see above. One option you did not mention was making use of the data bounds (rather then the map context area). It may look strange at the edge of smaller datasets but would be the most broadly applicable. > I'd like to have feedback on this, what do you think? > Enjoy, and thanks for looking into this. Jody ------------------------------------------------------------------------- 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
