Pre-RFC, pulling rendering/labeling parameters from attributes...

[Jerry Pisk]

How about doing something similar to format strings? For example:

SIZE "{sizeattribute}"
ANGLE "{angleattribute}"
LABEL
  TEXT "Label: {labelattribute}."
END

You would need a way to disntiguish between an attribute name and an
actual value anyway. And ity would be nice to support substitutions in
all values when we're at it, even things like COLOR, OFFSET and so on.

Jerry Pisk

On 6/6/06, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
> Hi all: Before running off and doing an RFC I wanted to gather some feedback. Currently we do
> support pulling things like angle or size from an attribute. Works fine but is clunky in many ways
> since you see things like angleitem and angleitemindex in the structures. Adding more support
> for will just add more needless complexity (I could see folks wanting to set colors, start angles
> and other stuff).
>
> Anyway what might be nice would be to write fragments like:
>
>  STYLE
>    SIZE 'sizeitem'
>    ANGLE 'angleitem'
>    COLOR 0 0 255
>  END
>
> We could then use an hashTableObj called items to track the various values to pull from attributes.
> At parse time the hash would contain the item names. msWhichItems could turn those into array
> indicies (can the hashTableObj handle arbitrary types?) for speed. Then the rendering code could
> do a quick lookup to decide whether to pull from an attribute or not.
>
> It would be very easy to add support for new parameters then, just tweak the high-level rendering
> code (before handoff to native drivers). In MapScript we'd need a method to set a style or label
> items (e.g. $style->setItem('angle', 'myAngleItem');) or just use the hashTableObj interface.
>
> The bad? Syntax change (I'd leave labelitem and classitem alone) so this would be a good 5.0 feature.
> There might be a perforance hit with the high number of hash lookups.
>
> Worth thinking about?
>
> Steve
>