> > 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.
My concern with using the MapContext is that in uDig we use a number of MapContexts, one for each layer but the entire MapBounds may be larger since the other layers would be in seperate MapContext objects. And same as Geotools we keep recreating the MapContext object. Jesse ------------------------------------------------------------------------- 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
