about line joins and their z-order

[Rodrigo Martín LÓPEZ GREGORIO]

I assume that both (yellows and whites) roads are in the same layer and
different classes. If this is the case you have no control about the drawing
order with the class elements. Mapserver renders all layer elements in the
order it gets from source (shp, postgis).

I think there can be two alternatives. The first is separate the roads in
two layers using a FILTER at LAYER level so all the white roads gets drawed
first and then all the yellow ones.

The other alternative (the one I have used sometime) is order the elements
in the source (shp, postgis) so all white elements are procesed first by
mapserver. If your layer DATA is on a PostgreSQL table then you can make a
second table with the same structure of your original table and insert all
the roads in the right order like:

INSERT INTO newtable SELECT * FROM oldtable ORDER BY criteria

I'm sure there must be a better way to sort the elements without creating a
second table but this is the way I get it work.

If your layer DATA is on a shp file I don't know how to do that but the idea
is the same so if you find the way to do the same on shp file it must work
also.

Rodrigo.

On 6/15/07, Jackey Cheung <cheung.jackey at gmail.com> wrote:
>
>  I've rendered a map image like this:
> http://www3.mapasia.com/jackout/rj.png
>
> there are a few problems here:
>
> 1. they are joined correctly
> 2. although they are joined, but the yellow one should "covers" the white
> ones
> 3. the white one should be drawn beneath the lower segment of the
> yellow one
>
> As trying to fix this kind of problems, I've noticed that it's impossible
> to control the z-order of how roads are drawn. Say, in may cities, one very
> long road may elevated somewhere, and dive beneath other roads somewhere
> else. Is there any way to present this kind of thing with MapServer?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20070616/1c5503b6/attachment.htm>