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

[Steve Lime]

Couple of comments:

  - TEXT expressions are already supported (e.g. TEXT "[address] [st] [dir]). I have thought about extending those to allow text operations like commify, substr, toupper, tolower and so on. That would require a second parser (bison grammar) I believe, but is doable.

  - one way global sustitution could be accomplished by slurping a mapfile into a big string buffer and doing substitution there, then tokenize the buffer. I had that working several years ago but never really pursued it.

  - I don't see much value in expressions for angles and that's about the only place it makes sense so why bother. (my 2 cents anyway)

I guess it makes sense to craft an RFC to hold these ideas...

Steve

>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 06/06/06 8:55 PM >>>
Frank Warmerdam wrote:
> Stephen Woodbridge wrote:
>> Ok, glad I read this one before posting the exact same thing! only I 
>> would have done my example like:
>>
>>  SIZE [sizeattribute]
>>  ANGLE ([angleattribute] - 90.0)
>>  LABEL
>>   TEXT ("Label: " . [labelattribute] . ".")
>>  END
>>
>> This would require a lot of changes, but could be fully backwards 
>> compatible.
> 
> SteveW,
> 
> I assume part of the benefit here is that we can use the same substitution
> engine used for expressions?  (and I guess actually evaluating in the
> expressions in the ANGLE case above).
> 
> I certainly like this degree of generality, though internally I would like
> to see a fixed value and possibly a simple variable substitution handled
> via some sort of short cut to reduce the amount of expression processing 
> for
> each feature.  I would hate to have ANGLE 0 result in a full expression 
> parse
> and evaluation for each feature.
> 
> Best regards,

Frank,

I like the generalization, but I agree in the need for not using the 
expression evaluation if you don't need to. For example:

ANGLE 0
ANGLE [angleattribute]

Would not need expression evaluation, but any clause starting with "(" 
would be assumed to be an expression. I could live without the 
expressions but I think they are handy for a lot of simple or low volume 
sites.

I guess what I would like to see is a generalized attribute substitution 
for any single value that can be placed in a layer definition. This 
would imply that you would need three columns for COLOR [R] [G] [B], 
although it might be made smart enough to recognize COLOR 
[colorattribute] as a string and parse it.

Steve have you given any thought into URL parameter substitution and how 
it might or might not play with this. For example:

ANGLE %angle%
ANGLE [%angleattribute%]

So all values can be either:

constant
%parameter%
[attribute]
[%parameter%]
(expression)

where expression may/may not contain any of the items above. OK, this is 
getting into the grand unification theory of variable substitution :)

-Steve