wrong Color: using Style with Offset and Color from DB twice in one class section

[ralftrier]

I want to draw two parallel lines to baselines from a database. The parallel lines should be drawn with the color set in the db.

Part of my map file:

CLASS
  STYLE
    OFFSET 5 -99
    COLOR [color01]
    WIDTH 10
  END
  STYLE
    OFFSET -5 -99
    COLOR [color02]
    WIDTH 10
  END
END

Strange think happens. The first parallel line is drawn with the expected color. The second line (second style instruction) will be drawn in a random color seems to come from another line. The color (second line) will change depending form the scale.

I attach a map file, postgres data (table verkehrslage) and a HTML File which uses OpenLayers. In the HTML File you have to adjust the URL of the mapserver line 37

[sdlime]

This has to do with how lines with msDrawLayer()/msDrawShape() draw one style at a time. This is done to preserve intersections when drawing multiple styles (e.g. hollow/Google-style lines).

The binding process works fine in that the right values are being read from the data. Problem is that by time we make it to the second pass through the cached lines the subsequent styles are bound to the first (or last, not sure) features values.

Ugh... Not sure how to fix. I think we'd almost have to cache all styles for each feature, along with the feature, just in case there was binding. Another idea might be to define a processing flag to skip any line caching at the risk of ugly intersections. Thomas, thoughts?

Work around for the moment would be to use two layers.

Steve

[sdlime]

Could also search styles for the presence of multiple bindings beyond the first style and turn off caching. Auto-styling suffers the same problem.

Steve

[sdlime]

In trunk (r12060) I've added a check that disables the usual caching of lines when multiple styles are used and they define attribute binding. In this situation all styles are drawn for a single feature. Generally you'd want to avoid this because of how intersections would be handled. With this use case however it's probably not a big deal.

Ralftrier, any chance you can test against trunk?

Steve

BTW I've added ticket #3995 to track a more general fix.

[Rtr]

I've tested it against the trunk. Now it works as expected. Thanks a lot. Steve as you said, it's a fine solution for my use case.

Ralf

[sdlime]

Committed in branch-6-0 in r12502. Closing...

Steve