[mapserver-dev] SYMBOLTRANFORM for special symbols rendering

[Brent Fraser]

Alan,

    My imagining of how Vector field Rendering would work is that as the 
user zooms in and out the symbols would remain more or less the same 
size (except for any change due to a resampling of the grid values).  It 
would behave like GIS symbology (e.g. size in pixels), not CAD symbology 
(size in meters), although I guess if SYMBOLSCALEDENOM were used you 
could get symbol size based on scale.

   So my question is why the need for SYMBOLTRANSFORM?  In your case, 
you want the length of the line to vary with the grid value, but not the 
width (I might want the width of the arrowhead to vary as well; I hadn't 
thought about it):

STYLE
    SYMBOL "arrowbody"    # the symbol name (a short line segment)
    WIDTH 1               # constant "thickness" (according to doc)
    SIZE [uv_length]      # "height" of symbol; line length for this symbol
    ANGLE [uv_angle]      # angle of the arrowbody
END

and only the position (not the width or the length) of the arrowhead 
changes to match the length of the arrowbody symbol:

STYLE
    SYMBOLTRANSFORM arrowhead  # why is this required?
    SYMBOL "arrowhead"         # a ">" symbol
    ANGLE [uv_angle]           # same angle as arrowbody
    OFFSET [uv_length] 0       # ">" point is at the end of the arrowbody
    SIZE 4                     # constant height (width?) of ">"
END

What am I missing?

And I ran across 
http://matplotlib.github.com/basemap/users/examples.html  Have a look 
near the bottom of the page for sample graphics of wind vectors and barbs.

Best Regards,
Brent Fraser


On 11/24/2011 11:57 AM, Alan Boudreault wrote:
> Mainly yes, but might be apply to any other cases. hmm.. I see the 
> graphic properly in the rfc...
>
> http://mapserver.org/trunk/development/rfc/ms-rfc-78.html
>
> Alan
>
> On 11-11-24 12:46 PM, Brent Fraser wrote:
>> 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
>>>
>>
>
>