[mapserver-dev] SYMBOLTRANFORM for special symbols rendering
Brent Fraser
bfraser at geoanalytic.com
Thu Nov 24 12:46:58 EST 2011
Alan,
I'm assuming this is mainly for Vector Field Rendering? (I get a broken
link for the graphic in the RFC)
Best Regards,
Brent Fraser
On 11/24/2011 9:25 AM, Alan Boudreault wrote:
> Hi devs,
>
> A while ago, it has been discussed about a new way to render a symbol,
> which in this case is an arrow. The need is to be able to draw the
> body arrow (a line) scaled depending of a value (ie, the magnitude in
> vector field) but to not scale the arrow head.
>
> Mike, Daniel and Thomas discussed this problem in Denver during FOSS4G
> and they came up with the concept of ARROWBODY and ARROWHEAD. Those
> concepts are essentially to determine what need to be scaled.
> Following a discussion this morning.. here's the approach we would
> like to use:
>
> * We define two symbols: the arrow body and the arrow head.
> * The arrow head symbol needs to have the ANCHORPOINT set to the head.
> * We define 2 styles: one for the body and the other for the head.
> * The two style would use a new option: SYMBOLTRANSFORM, which is to
> draw the symbol correctly (scalable of not).
>
> Mapfile example:
>
> SYMBOL
> NAME "arrowbody"
> TYPE vector
> FILLED true
> POINTS
> 0 0
> 1 0
> END
> END
>
> SYMBOL
> NAME "arrowhead"
> TYPE vector
> FILLED true
> ANCHORPOINT 0.25 0
> POINTS
> 0 0.25
> 0.25 0
> 0 -0.25
> END
> END
>
>
> # in the layer definition....
>
> STYLE
> SYMBOLTRANSFORM arrowbody
> WITDH 1
> SIZE [uv_length]
> ANGLE [uv_angle]
> END
> STYLE
> SYMBOLTRANSFORM arrowhead
> SYMBOL "arrowhead"
> ANGLE [uv_angle]
> OFFSET [uv_length] 0
> SIZE 4
> END
>
> In the arrowhead, we *NEED* to pass the length of the arrowbody (via
> OFFSET), since it will be used to determine where the arrow head
> should be positioned. the SYMBOLTRANSFORM arrowhead option would tell
> the symbol renderer TO NOT scaled the symbol in length. In this
> example, we use the terminology arrowbody/arrowhead.... but we are
> going to use generic terms to use that feature in other cases.
>
> I'm glad to hear your comments and suggestions about that approach!
>
> Regards,
> Alan
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
More information about the mapserver-dev
mailing list