You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reporter: havatv Date: 2011/03/18 - 09:56 Trac URL:http://trac.osgeo.org/mapserver/ticket/3752
In order to enable scalable decorated lines,
LAYER-> CLASS-> STYLE-> PATTERN and LAYER-> CLASS-> STYLE-> GAP
must both be scalable (and their units compatible).
PATTERN seems to scale in 6.0.0beta1, while GAP does not seem
scale (gaps seem to be constant over scales).
For scalable symbols, it is important that the units of
LAYER-> CLASS-> STYLE-> PATTERN and LAYER-> CLASS-> STYLE-> GAP
are compatible with WIDTH/SIZE.
This means that when I specify "WIDTH 5", and "PATTERN 5 5"
(and LINECAP BUTT), I expect to see a line that is 5 units wide,
in dashes of 5 units with a spacing of 5 units. Currently, there
seems to be a scale difference between the PATTERN units and the
WIDTH units, but the scale seems to depend on the value of WIDTH...?
GAP has to use the same units as SIZE, WIDTH and PATTERN in order to allow scalable decorated patterned lines, for example:
---#--- ---#--- ---#--- ---#---
The numbers for SIZE, WIDTH, PATTERN and GAP must refer
to the same units.[[BR]]
When the map scale is SYMBOLSCALEDENOM,
SIZE should specify the final height of a symbol on the map (before rotation).
WIDTH should specify the final width of a line on the map.
GAP should specify the final gap between symbols on the map.
PATTERN should specify the final dash lengths and spacing
between dashes on the map.
The numbers could refer to pixels for images, or some length
unit for vector graphics (possibly with a scaling factor).
The text was updated successfully, but these errors were encountered:
GAP now works perfectly. SIZE and GAP use the same units, and things seem to scale.
However, PATTERN behaves a bit different than I thought was logical. To get a line that is 5 units wide, in dashes of 5 units with a spacing of 5 units, in 6beta2 I must specify:
WIDTH 5
LINECAP BUTT
PATTERN 1 1
PATTERN seems to use the WIDTH as units.
I would have thought that the following would be more intuitive:
WIDTH 5
LINECAP BUTT
PATTERN 5 5
I don't know if this is a bug or intended behaviour, so I have not reopened the ticket.
What do you think?
Author: havatv Date: 2011/05/11 - 11:19
For the record:
PATTERN has been fixed according to my suggestion, so the dash length and gaps no longer depends on the line width.
Reporter: havatv
Date: 2011/03/18 - 09:56
Trac URL: http://trac.osgeo.org/mapserver/ticket/3752
In order to enable scalable decorated lines,
LAYER-> CLASS-> STYLE-> PATTERN and LAYER-> CLASS-> STYLE-> GAP
must both be scalable (and their units compatible).
PATTERN seems to scale in 6.0.0beta1, while GAP does not seem
scale (gaps seem to be constant over scales).
For scalable symbols, it is important that the units of
LAYER-> CLASS-> STYLE-> PATTERN and LAYER-> CLASS-> STYLE-> GAP
are compatible with WIDTH/SIZE.
This means that when I specify "WIDTH 5", and "PATTERN 5 5"
(and LINECAP BUTT), I expect to see a line that is 5 units wide,
in dashes of 5 units with a spacing of 5 units. Currently, there
seems to be a scale difference between the PATTERN units and the
WIDTH units, but the scale seems to depend on the value of WIDTH...?
GAP has to use the same units as SIZE, WIDTH and PATTERN in order to allow scalable decorated patterned lines, for example:
---#--- ---#--- ---#--- ---#---
The numbers for SIZE, WIDTH, PATTERN and GAP must refer
to the same units.[[BR]]
When the map scale is SYMBOLSCALEDENOM,
SIZE should specify the final height of a symbol on the map (before rotation).
WIDTH should specify the final width of a line on the map.
GAP should specify the final gap between symbols on the map.
PATTERN should specify the final dash lengths and spacing
between dashes on the map.
The numbers could refer to pixels for images, or some length
unit for vector graphics (possibly with a scaling factor).
The text was updated successfully, but these errors were encountered: