Jody Garnett ha scritto: > 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
Hum, interesting. In fact I still haven't had a look at how labeling is performed besides the label moving due to bbox considerations. Is there any open issue against this? If not, can you open one with your suggested solution included? Mover, I don't have a mandate to due tile caching, just to make answers to tiled request look right. So the tiling 3by3 is not something I can really do, it's something I'd like to do when I'll have a mandate to implement TMS thought. >> 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. That was my first thougth as well, but simbol size (and line width, font size, whatever) is something that may be associated to a complex expression using attributes, making this approach unworkable in the general case. That's why I'm suggesting the user to provide information I cannot look up. >> 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. How does 3x3 help? You're just making quirks less common, but they would appear anyways on the 3x3 group borders? It's just a bigger tile. > 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. Sorry, aren't map context bounds equal to the data bounds? Anyways, I was thinking to data bounds, but computing them on each request may be really expensive (I have postgis datasets where a bounds calculation request takes seconds even on my PC with RAID 0 disks...). In geoserver I can always use the bbox the user provided (hey, did not think about that :-) ) but that would be something I have to pass down the renderer as an extra parameter, so rendering subsystem wise, it would still be a hint. uDig could use MapContext.getBounds() instead, since the MapContext is long lived (provided the data store allow for bounds computation, not all do...). Hmm... it seems to me we could use a LABELING_MODE hint with the following values: * SEAMLESS: assume map has no bounds (this should be the default); * MAP_BOUNDS: use MapContext.getBounds() (or the full data layer bounds anyways) unless a second hint (LABELING_BOUNDS) with a user provided bbox is available; * RENDERING_BOUNDS: use the map bbox as labeling optimization bounds (current behaviour, ok for priting). Add the META_BUFFER hint and I think we're set for the moment. Cheers Andrea Chers 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
