[mapserver-dev] Labeling enhancements not related to justification

[Steve Lime]

You'd store the actual label point as an attribute and reference using POINT (or
AUXPOINT). The line would go from that to the computed label point but would 
be symbolized by the styleObj so you you could draw whatever.

Steve

>>> Stephen Woodbridge <woodbri at swoodbridge.com> 05/06/08 11:14 PM >>>
Yes, this was not related to Thomas' proposal and post 5.2 was my 
thinking, it was more triggered by Daniel's comment on other labeling 
enhancements.

I guess I'm not clear on how the CALLOUT renderer would work, but you 
would need to pass it the feature point, ie: what the callout points at, 
and you label point, ie: where the callout originates.

If you think about the use case of labeling the states like google does, 
then most states will be labeled at there default label position which 
would need to be calcuated always anyway so you have the feature point, 
but a few of the label will have callout positions. My proposed solution 
is targeted at being able to support this without the need to split the 
data in the shapefile or postgis table into two separate data sets. The 
idea being that if the callout or auxpoint or whatever, is NULL or 0,0 
then you get the default behavior otherwise you get the callout. This 
makes it easy to adjust a few problem labels by just adding a couple of 
attribute columns and only populating the problem items with the callout 
points.

The CALLOUT seems like a good general approach that would be useful and 
reusable in a lot of potential scenarios. I look forward to a RFC on 
that in the future.

-Steve W

Steve Lime wrote:
> I'd say callouts are out of scope for Thomas' proposal. Thomas and I
> exchanged notes awhile back on possibly using special styleObj TYPES
> as a way to do stuff like this. We were talking about arrow heads but
> the thought was that other custom renderers could be supported. One
> could be a bbox renderer that draws the mbr around a polygon or
> polyline. I'm wondering if a callout renderer could also be 
> supported. I like the idea of AUXPOINT but would just go with POINT
> in the label object as a way to override the computed point (that
> could be done now, with binding). The arrow, marker or other styling
> would come from the STYLE object with TYPE CALLOUT or something like
> that. Post 5.2 work I fear...
> 
> Steve
> 
>>>> Stephen Woodbridge <woodbri at swoodbridge.com> 05/06/08 1:53 PM
>>>> >>>
> Thomas,
> 
> The one request I get a lot from users is for an arrow label based on
> an axillary label placement point. This would be like how google
> labels the small states on the US Eastern seaboard with the label in
> the ocean and an arrow pointing to where the object label point is.
> 
> I would propose a syntax like this into implement this, but something
>  else might be better if anyone has any ideas.
> 
> LABEL .... AUXPOINT [label_x] [label_y] .... END
> 
> Where the [label_x], [label_y] are column references and this point 
> would be used to place the label text and then an arrow would be 
> constructed back to the objects label point from this AUXPOINT. If 
> [label_x],[label_y] is equal to 0,0 then default labeling behavior
> would apply and the AUXPOINT would be ignored.
> 
> One could also set up FILTERs to select label_x != 0 to separate 
> AUXPOINT labels from standard labels if they wanted to.
> 
> 
> You could also add an optional arrowhead style and size fields, like:
>  [ah_style] and [ah_size]:
> 
> AUXPOINT [label_x] [label_y] [ah_style] [ah_size]
> 
> which could be used to determine what style of arrow to use. Like:
> 
> [ah_style]: plain - simple line arrow - line with arrowhead dot   -
> line with dot instead of arrowhead
> 
> [ah_size] controls the size of the arrowhead or dot
> 
> 
> [label_x] [label_y] [ah_style] [ah_size] can be constants or column 
> substitutions.
> 
> LabelCache processing would look at the bbox for the label text, not
> the arrow, or if looking at the arrow also would only look at the
> arrow path not the arrow's bbox. Maybe some more thought needs to go
> into this part of the proposal.
> 
> -Steve W. _______________________________________________ 
> mapserver-dev mailing list mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>