Enable rotation of ellipse symbols

Reason? GD does't support it so the only way to achieve would be to render to a pixmap and then rotate the pixmap. However, those results would be lousy so why bother. Plus, nobody has ever asked.

Not sure about AGG support for this.

Steve

This shouldn't be a problem on the AGG side.

There is one question if you want to use this as a fill for polygon shapes: in case of rotation the size of the tile used as a pattern will have to be adjusted to account for the rotation (i.e. the boundingbox of a rotated ellipse will contain no neighbouring ellipses), is that really what you want?

->Thomas, I see your point about polygon fills, but for the ellipses, I was thinking more about point symbols. I found a use for it in my orienteering map test case, where one symbol is, in fact, an ellipse that should be oriented according to the orientation of the terrain feature it represents.

Coming to think about it, rotation of polygon fills could be done in two ways: Create the pattern using non-rotated symbols and then rotate the pattern, or create the pattern using rotated symbols. The last way seems to be the current Mapserver way. Thomas has now also added styles to hatches - is the next step to have symbols with hatches? That could be a way to implement the first way of polygon fill rotation... (but this would need to be considered carefully and then be properly documented)

->Steve, that explains why rotation of ellipses has not been an option.

The workaround is of course to implement a rotateable ellipse using a vector symbol.

My reason for suggesting that ellipses should be rotateable was that it seems counter intuitive to have rotateable vector symbols but not rotateable ellipses. But this is definitely not a big issue.

Replying to havatv:

Coming to think about it, rotation of polygon fills could be done in two ways: Create the pattern using non-rotated symbols and then rotate the pattern, or create the pattern using rotated symbols. The last way seems to be the current Mapserver way.

that's because you can specify a backgroundcolor for the symbol, so you can't just rotate the tile as you'd get gaps around the tiles.

is the next step to have symbols with hatches? That could be a way to implement the first way of polygon fill rotation...

do you mean having for example a polygon filled with hatched circles? If so I guess this would be getting a little too complex, both on the implementation side and on the syntax that would be needed to define this (size and width refer to the size of the symbol but also to the width and spacing of the hatches, etc...)

The workaround is of course to implement a rotateable ellipse using a vector symbol.

I'll add ellipse rotation in AGG for point symbols, as that isn't a big deal. There might be small glitches with the label cache code, as the space occupied by the marker is computed for unrotated symbols, but this isn't ellipse-specific, as rotation isn't accounted for with other symbols either (Steve, can you confirm this? http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapsymbol.c#L753 )

AGG ellipse rotation for marker symbols commited in r7597

Replying to tbonfort:

Replying to havatv:

Coming to think about it, rotation of polygon fills could be done in two ways: Create the pattern using non-rotated symbols and then rotate the pattern, or create the pattern using rotated symbols. The last way seems to be the current Mapserver way.

that's because you can specify a backgroundcolor for the symbol, so you can't just rotate the tile as you'd get gaps around the tiles.

I was thinking conceptually. The two approaches will give different results. The first approach would have to be implemented by making tiles that could represent the rotated pattern of symbols (would have to contain parts of the symbols at the edges of the tiles) - probably not trivial.

is the next step to have symbols with hatches? That could be a way to implement the first way of polygon fill rotation...

do you mean having for example a polygon filled with hatched circles? If so I guess this would be getting a little too complex, both on the implementation side and on the syntax that would be needed to define this (size and width refer to the size of the symbol but also to the width and spacing of the hatches, etc...)

I was not thinking about filling the symbols with hatches, but to orient the pattern of symbols, as explained earlier, for instance a pattern of circles of a specified size with a specified spacing - probably quite complex. This would require a change in the STYLE syntax, as both hatch and the symbol is specified using SYMBOL...

Anyway, it was just a thought - further increasing the versatility of the hatch mechanism.

In Mapserver 5.2 beta 3, rotation of ellipses is implemented for AGG (not for GD), but the direction of rotation is counter clockwise. The direction should be clockwise (the rotation is clockwise for vector symbols and truetype symbols using both GD and AGG). I therefore re-open this bug instead of opening a new one.

actually, I've been testing, and it seems only the vector symbols are rotated clockwise. all the others (pixmap, truetype, and now ellipse for agg) are rotated anti-clockwise.

Steve, I don't think that changing the vector rotation direction is a good idea so close to the release, or at least this should be clearly documented. any thoughts ?

we should probably open up another bug for this after all

You are right about truetype symbols - I did test that, but I must have made some kind of mistake when testing... When testing now, I see that truetype symbols are rotated counter clockwise.

It is not good that rotation direction is not consistent[[BR]] I think this is another very good indication that the symbology documentation is lacking, since the direction of rotation is not mentioned in the documentation. I hope we can continue the work on improving the mapserver symbology documentation, behaviour and consistency. We should probably not file these kinds of symbology "bugs" before intended behaviour is determined through an accepted RFC.

No, changing vector rotation now is a bad idea. Add rotation direction to the list of rendering improvements for 5.4. Should ellipses follow vectors for now (clockwise)?

Steve

Replying to sdlime:

Should ellipses follow vectors for now (clockwise)?

I'd leave it as it is, imho only the vector rotation should be reversed to be consistent with the other symbol types.

closing this bug, I'll open a new one for the vector case for the 5.4 milestone

I must say that I disagree regarding what rotation direction should be the default. I guess both clockwise and counter clockwise have their merits, but one big advantage of using clockwise is that, for point symbols, clockwise would translate directly to the traditional "compass" directions:

0 degrees = north
90 degrees = east
180 degrees = south
270 degrees = west

This should be discussed further in the symbology RFC, in my opinion.