From: Debasish S. <Deb...@rm...> - 2004-06-30 10:53:50
|
Many Thanks Andrea for the userful tip. Here is sample image of Polygo= n labelling it is much worse that point and line labelling . I would request you to kindly improve the same . Can you pl= ease guide me if i am missing something and the other thing is LiteRenderer doen't seem to preserve the aspect rati= o resuting in strecthed output image. (See attached file: test.png) Thanks and Warm Regards, Debasish Sahu Technical Specailist RMSI Engineering and Spatial Group Dial: 00-91-120-2511102 = =20 Andrea Aime = =20 <and...@al...> To: geot= ool...@li... =20 Sent by: cc: "Deb= asish Sahu" <Deb...@rm...> =20 geo...@li...urc Subject: = Re: [Geotools-devel] LiteRenderer Overlapping Labels =20 eforge.net = =20 = =20 = =20 06/29/2004 11:50 PM = =20 = =20 = =20 Alle 16:08, marted=EC 29 giugno 2004, Debasish Sahu ha scritto: > Hi Andrea, > Thanks for the response. I am in the process of implementing Label Manager > to manage overlap labels. > Could you please tell me how can i get the string bounds in lite rend= er so > that i can check the intersection with the other labels > and where exactly should i put the following code in lite renderer > > Rectangle2D r2d =3D < code to find the string bounds> > if (labelManager.isIntersects(square)) { > return; > } > > Sample code is as follows Debasish, I'm not sure, but I guess the best place is at line 1231, wit= h gv.getOutline(x,y).getBounds(), with the hope that it's not too expensi= ve. Now, two considerations: * as you can see in renderText() and renderString() we play with transformations. This is because we have to render text unscaled, we already have an height expressed in pixels and we don't want to be scaled as th= e rest of coordinates. Keep this in mind when doing collision detection. * lite renderer is stream based, which means, you cannot have all the labels at once in memory. I guess you are forced to some variation like: * loading twice the labels, once for getting all the bounds and decid= ing the positions, and again to really render. Consider also that SLD can a= sk you to render a sequence of polygon1, label1, polygon2, label2, ... ins= tead of polygon1, polygon2,... and then label1, label2,... This basically means that you can't store all of the labels in memo= ry to render them later (and anyway that would defeat one of the lite-renderer features, low memory consuption) * another way is to have a "streaming" label collision mechanism, tha= t only keeps in memory the bounds of what has been already drawn and tries to reduce the number of collision when drawing a new label. T= his is of course suboptimal, but allows to use less memory, in particular = if you care to store bounds as 4 integers and in big arrays where you know= that the first four elements are the first bound definition, the ne= xt four the second, and so on. You can allocate arrays of, say, 400 element= s, and allocate new ones when needed, so you end up with a List of tho= se arrays. This should help both performance, since those big arrays scanned in sequential order are both memory and locality friendly. A more performant but also more memory hungry way would be to use the JTS quadtree index to fastly retrieve conflicting bounds. This seems to be something that needs to be realized as a CollisionDetector interface and two implementations, one fast but memory hungry, the other slowe= r but less memory hungry (and of course you can choose to implement j= ust one of them and leave the other for people that need it) Ah, and of course you need to find out a less dumb way to position a la= bel relative to its point/line/polygon... Well, it seems challenging enough= to be fun :-) If you need more assistance, just ask, happy to provide it. Best regards Andrea Aime ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Geotools-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geotools-devel = |