[Symbol] SIZE does not affect symbol STYLE

[jlacroix]

We can specify a STYLE in a symbol definition. This is used to draw praw pattern in lines (dashed lines). However, the STYLE does not scale depending on the size of the symbol. This cause the symbol's style to be un-useable when changing the symbol size.

Image this symbol definition:

SYMBOL
  NAME "test"
  TYPE Ellipse
  STYLE 1 5 END
  FILLED TRUE
  POINTS
  1 1
  END
END

With a size of 5 in the STYLE object this would render very nicely. But with a size of 10 or more the circle will overlap on each other. I'll attach an example.

Steve, I don't think this is hard to change. Instead of putting the one pixel of space between each symbol draw, we can put [SIZE] number of pixels.

We can either change the default behavior (I don't think this funcitonality is used to much) or use negative numbers. Or we can add a param in the symbols, but usually I think you try to prevent to add new parameters in the MapFile/Symbols definition :) .

What do you think? If you give me your opinion I can take care of this.

Julien

PS: Should I do a RFC for this?

[jlacroix]

symbol_style.png - Patterned lines, 2 different size

[sdlime]

You mean pattern size times symbol size correct? In the example below you'd put 
down a marker then skip 45 pixels (9x5) put down another one and so on. That'd 
work I think and would take care general scaling of patterns.

However, there is a downside to this modification. The current behaviour can be 
viewed as a feature. Perhaps someone wants overlapping circles or diamonds to 
achieve a particular effect. Perhaps that's not worth worrying about.

I'd actually like to move SYMBOL STYLES into CLASS STYLES as a parameter called 
PATTERN. That way a symbol would contain a primitive definition (a circle or 
diamond) and the CLASS STYLE would contain everything pertinent to it's being 
drawn.

Steve

[dmorissette]

This issue is coming up again as we start thinking about generating high-resolution maps for printing. The eventual map resolution RFC should take this ticket into account and propose to fix it.