[mapserver-users] Map File for Open Street Map symbology

[thomas bonfort]

Hi Steve,

On Tue, Jan 13, 2009 at 20:12, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> thomas bonfort wrote:
>>
>> http://code.google.com/p/mapserver-utils/source/browse/trunk/
>>
>> you'll need the code from the mapserver graphics sandbox (rev 8254 is
>> preferred as it doesn't have the cairo code in it yet)
>
> Hi Thomas,
>
> I have been looking over your osm mapfile and have a few questions.
>
> 1) As you mentioned in your original post, I should grab some code from a
> sandbox, what does this have in it over say todays svn?
I haven't had time to wrap up the comments on rfc49 and call for vote
on it. The graphics sandbox is a placeholder for that code until that
is done.

>
> 2) I noticed you have both:
>
>    LABELITEM "name"
> and
>        TEXT ([ref])
>
> Does the TEXT override the LABELITEM for the given class it is in? and then
> default to the LABELITEM if it is not present? I guess this seems logical,
> but I never thought about it before.
I didn't think about it when doing it either. haven't looked at the
code, but the behavior you show correspond to the results of that
mapfile.

>
> 3) This looks a little strange. It looks like you are drawing the outline
> first without the body of the road, then drawing the body of the road
> afterwards.
>
>        STYLE
>            WIDTH _motorway_width
>            OUTLINEWIDTH 1
>            OUTLINECOLOR _motorway_ol_clr
>            MINWIDTH _motorway_minwidth
>            MAXWIDTH _motorway_maxwidth
>        END
>        STYLE
>            WIDTH _motorway_width
>            COLOR _motorway_clr
>            MINWIDTH _motorway_minwidth
>            MAXWIDTH _motorway_maxwidth
>        END
>
> Why not draw it like in a single pass? are there quality issues with this?
the mapfile is a bit complex with the taking into account of bridges
and tunnels. Doing things how I have done ensure the outlines for
normal roads are drawn simultaneoulsy with those of the other roads,
and likewise for the fill. without this the joining between normal
streets and bridges or tunnels was less satisfying.


>
>        STYLE
>            WIDTH _motorway_width
>            COLOR _motorway_clr
>            OUTLINEWIDTH 1
>            OUTLINECOLOR _motorway_ol_clr
>            MINWIDTH _motorway_minwidth
>            MAXWIDTH _motorway_maxwidth
>        END
>
> Or draw it like where (_motorway_width + 2) is a value not an expression:
>
>        STYLE
>            WIDTH _motorway_width + 2
>            COLOR _motorway_ol_clr
>            MINWIDTH _motorway_minwidth
>            MAXWIDTH _motorway_maxwidth
>        END
>        STYLE
>            WIDTH _motorway_width
>            COLOR _motorway_clr
>            MINWIDTH _motorway_minwidth
>            MAXWIDTH _motorway_maxwidth
>        END
>
> I assume this is slower because you have to draw all the pixels between the
> outlines.
the outline keyword is just a shorthand for not having to define 2
style blocks. internally, mapserver splits a block with an
outlinecolor into 2 blocks with the corresponfing widths ( more
importantly, using the outlinewidth keyword is the only way of
defining a fixed width outline when using scaledependant rendering )

>
> 4) I have not seen MINWIDTH and MAXWIDTH before. What do these do? Isn't the
> width fixed? Or is this controlling the how wide the antialiasing is allowed
> to propagate?
this is the reason why the outlinecolor becomes so useful: as you see,
there's only one mapserver class for each road class, they haven't
been split up with scale-dependant widths (well, except for when they
thin down to a single color line). at the beginning of the layer
you'll see "sizeunits meters", which means all roads will be drawn to
scale with their ground width. the min/max widths place pixel limits
on this scaling, e.g. draw a 30(width) meter wide road, but don't let
it get thinner than 1(minwidth) pixel, or wider than 12(maxwidth)
pixels. This dramatically reduces mapfile size and eases maintainance,
although it is of course a bit less flexible than defining a mapfile
class for each scale.

>
> Wow! After 10 years of working with mapfile files there is still a lot of
> new interesting stuff to learn!

and I'm sure there's still lots more!

cheers,
thomas