Hi Justin:
I already did something similar to "reserver area" for map decorations (such as
scalebars) to keep the label system from drawing over top of them).
I cannot remember what method I used; but I can go check if you are interested.
--
Jody Garnett
On Saturday, 28 May 2011 at 1:02 AM, Justin Deoliveira wrote:
> Hi all,
>
> A while back we had a client who was interested in funding some labelling
> work to solve a problem they were having with labels being drawn over
> external graphics. As an example:
>
> https://skitch.com/jdeolive/fbiss/label-before
>
> Andrea had the idea of introducing the concept of labelling obstacles. More
> specifically marking a symbolizer as a "label obstacle" via a vendor option.
> And when present such symbolizers would be factored into the labelling
> routine. Basically it would mark the area taken by the symbolizer as "busy"
> so that no label would be drawn over top of it.
>
> I have taken a crack at implementing this. The initial results look promising:
>
> https://skitch.com/jdeolive/fbish/label-after
>
> The current patch can be found on this jira issue:
>
> http://jira.codehaus.org/browse/GEOT-3610
>
> The patch is still rough at this point, but I wanted to post it to supplement
> some of my questions:
>
> 1. I had to utilize the deprecated constructor on StyledShapePainter that
> accepts the LabelCache as a parameter, however that constructor has been
> deprecated. Is that because rendering is now multi threaded and that the
> painting actually goes on in a separate thread? So access to the label cache
> should be limited to the primary/data loading thread?
>
> I am trying to analyze the rendering code to figure out if actually any race
> conditions are introduced. And if I understand correctly I don't think there
> are but I could definitely be missing something. With the new code the only
> time the painting thread has to update the label cache is to put a new
> reserved rectangle into the cache... which simply updates the reserved list.
> And as far as I can tell this value is not accessed by the primary thread
> until after it has joined with the paint thread...
>
> Anyways, some guidance here on how best to proceed would be appreciated.
>
> 2. The patch adds support for marking a Line and Poly symbolizer as a label
> obstacle. Not sure if this is a great idea since the method is bounding box
> based hence we have to reserve the entire bounding box of lines and polygons.
> Which you can imagine can lead to (depending on the shape of a geometry)
> large spaces with no labels. So I am wondering if label obstacles should be
> limited to point symbolizers?
>
> That is about it for now... general feedback appreciated... but be gentle...
> this is my first rendering patch :)
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> (mailto:Geotools-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
