steve.lime at DNR.STATE.MN.US
Thu Dec 15 17:16:28 EST 2005
I'm not seeing all the same problems with outlines. I get the expected result as well with your
initial style. Now onto the other cases:
1) "But if I omit the COLOR statement (to get a thin antialiased red line around a hollow polygon) the red line is thicker; probably equal to a WIDTH 3 or something."
I get the thin red line. In my example image that is labeled as Ed's Polygon
2) "However, if the polygon is filled, the WIDTH is ignored - all outlines are the same thickness."
This I do see, with or without antialiasing on so this may have been a pre-existing problem. I'll try to fix.
3) "If the polygon is not filled, the line is thicker than I expect, but it does respect the WIDTH, and larger numbers produce wider lines."
My tests aren't showing this, but then again I'm only testing inline features. By chance are you doing any scaling of symbols? I could see, perhaps, where a line width could be inadvertanly scaled twice. In my result image the 2 red filled triangles are drawn using the same width but the bottom one as a LINE layer and the top as a POLYGON layer with an OUTLINECOLOR.
My sample mapfile and results are at:
>>> "Ed McNierney" <ed at topozone.com> 12/15/05 11:53 AM >>>
There's clearly something going on if you try to draw an antialiased
border around a polygon that is NOT filled. If I take my simple polygon
example and use this style:
COLOR 0 0 255
OUTLINECOLOR 255 0 0 0
then I get what I expect, a thin antialiased red line around blue
polygons. But if I omit the COLOR statement (to get a thin antialiased
red line around a hollow polygon) the red line is thicker; probably
equal to a WIDTH 3 or something. However, if the polygon is filled, the
WIDTH is ignored - all outlines are the same thickness. If the polygon
is not filled, the line is thicker than I expect, but it does respect
the WIDTH, and larger numbers produce wider lines.
On the bright side, the line is now drawn in the right color!
These are pretty simple test cases - let me know if you need output or
MAP snippets; it's the same example I sent you yesterday.
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV at LISTS.UMN.EDU]
On Behalf Of Steve Lime
Sent: Thursday, December 15, 2005 12:05 PM
To: MAPSERVER-DEV at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-DEV] Fuzzy brushes...
Thanks for the feedback. Yes, with last nights modifications the polygon
outlines work too. You can also define simple symbols for applying
STYLE 20 20 END
and those can use the new brushes. I still need hook into the ELLIPSE
As for new parameters, yes I could see some being added for fine tuning
brush creation: hardness, shape (circle, square, diamond) and so on. At
this point I thought it better not to add new keywords and just get the
I'm really curious about the performance hit...
>>> Yewondwossen Assefa <assefa at DMSOLUTIONS.CA> 12/15/05 10:27 AM >>>
I just tried the antialias on lines and It seems to work well. There
are a couple of quetions that were raised here reagrding this :
* would paremeters like hardness be available at some point for
I did not yer try it with polygone outlines but I am assuming that It
should work too. Is that correct ?
I will continue the testing in the next days with diffrent features and
report regularly. That for the addition.
Steve Lime wrote:
>In case anyone would like to test I have hooked up the fuzzy brush
generator in mapgd.c for the most trivial line drawing case (no symbol
defined). To use:
>1) define a 24-bit output format, IMAGETYPE 'png24' works nicely
>2) define a simple style definition for a line layer (or polygon
outline) like so:
> WIDTH 3
> COLOR 255 0 0
> ANTIALIAS TRUE
>3) set TRANSPARENCY ALPHA to enable alpha blending
> - brushes need to be odd sized. That requirement is enforced in the
brush builder which detects even sized requests and rounds up. Symbol
scaling should work just fine.
> - you'll notice that the line "fades" in at the start which is due to
the transparent nature of the brush. Adjusting the default "hardness"
may minimize that.
>That should do it. I will enable for circles layers and other instances
where it makes sense (circle symbols, simple symbols with dash patterns
and so on) ASAP. I also will enable image cache use in the most simple
case which may help performance a bit.
>Note, I hope to do away with 3) (there is a bug filed) but can't yet
because of a problem in the image merging code in mapgd.c (not mine old
code for a change).
Email: assefa at dmsolutions.ca
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
More information about the mapserver-dev