Symbol size calculation - change in behaviour in 5.4.0beta

[havatv]

There seems to have been a change in behaviour for symbol size calculation between 5.2 and 5.4.0beta3 (tested for GD and AGG).

In 5.4.0beta-3 symbol size calculation seems to be different from 5.2. In 5.2, when specifying symbols using "POINTS", y values could be any range. In 5.4.0beta only y values between 0 and 1 seem to have effect. Everything outside of this range is "truncated away" when drawing the symbol. In 5.2 (and earlier versions), size calculations used 0 as a fixed low value for y, while the maximum y value in the symbol definition was used as the high value for y. In 5.4beta this seems to have changed to using 0 and 1 as the low and high value for symbol size calculations.

Documentation has never been clear regarding how symbol size calculations are to be made, so this is perhaps not a bug as such, but all my map files with scalable symbols will have to be modified as a result of this change. I therefore hope that this is well thought through, and that it will be documented. I found the old way of calculating symbol sizes more convenient than the new one when using scalable symbols.

By the way, current documentation of symbol->points has a note that says: "If a class using this symbol doesn’t contain an explicit size, then the default symbol size will be based on the range of “y” values in the point coordinates. e.g. if the y coordinates of the points in the symbol range from 0 to 5, then the default size for this symbol will be assumed to be 5."

Example to illustrate the change in behaviour:

I have a scalable area fill with horizontal lines where there is a 1:2 ratio between line thickness (filled) and whitespace (space between the lines).

In 5.2, this code would give me the expected result:

SYMBOL
  NAME "myr"
  TYPE vector
  FILLED true
  POINTS
    0 0.2
    100 0.2
    100 0.3
    0 0.3
    0 0.2
  END  
END

In 5.4.0beta3, to get the same effect, I have to change to this:

SYMBOL
  NAME "myr"
  TYPE vector
  FILLED true
  POINTS
    0 0.6666666
    100 0.666666
    100 1
    0 1
    0 0.66666666
  END  
END

Håvard Tveite

[sdlime]

Ugh... I'm not sure what the source of the problem is from. There was a change to the default symbol size, changing from 0 to 1 to avoid division by zero errors in the PDF or SWF driver, but that shouldn't be causing this problem. CC'ing others for comment. I don't think we want to force changes like this in 5.4, 6.0 yes, but not now.

Steve

[tbonfort]

yeah, the change of the default size to 1.0 is affecting this, as the code for loading the points sets the size by doing a max(cursize, y), thus keeping 1 as the final size if no points have a y-value over 1.

I think the size calculation for symbols is very wrong right now, especially for vector symbols. I'd be very in favor of having the 6.0 version vector symbols be defined around (0,0), with (0,0) being the anchor point on the map. Not sure if this is a backwards incompatibility that we can afford though, so I'm open to suggestions if you have better ideas.

[sdlime]

Right now I'd just like to get 5.4 out the door. Perhaps we should revert to a default of 0 and fix the division by zero error in the one place it was occuring.

Håvard, if you set sizex & sizey to 0 in initSymbol() in mapsymbol.c do things behave as expected?

We can take 6.0 behavior as a new subject then.

Steve

[sdlime]

Looking at loadSymbol() in mapsymbol.c even if we do revert back to size=0 it still doesn't take into account x,y's in the point section that are less than zero. Perhaps we should change things to compute/assign sizex/sizey when the END is reached. That is, once loaded we loop through the points and compute sizex/sizey from that rather than trying to do it in one pass. I'll attach a new version of mapsymbol.c to try that does this (I think).

Steve

[sdlime]

Version that computes symbol size independently of the default size

[sdlime]

Ignore the attachment. That changes things to dramatically for 5.4. I can revert to 5.2 behavior by initializing a symbol's sizex and sizey values to zero if a POINTS element is encountered.

Steve

[sdlime]

I committed a fix in r8859 that seems to help, so beta4 needs to be tested. Moving to 6.0...

Steve

[havatv]

I have now testet beta4, and previous behaviour seems to have been restored. I have not tested "set sizex & sizey to 0 in initSymbol() in mapsymbol.c" (as requested by Steve) - I assumed that this was no longer necessary.

Regarding how to handle symbol scaling and precise positioning: Steve, Thomas and I have had some correspondence on this, and I have produced a document describing some of the issues concerned with consistent and convenient scaling and precise symbol placement. Some of it has been included in "MS RFC 49: Symbology, Labeling, and Cartography Improvements".

I have a test map that demonstrates some of the limitations of the current versions of mapserver when it comes to consisten scaling of "line patterns" and precise placement of symbol (particularly along lines): ​http://gis.umb.no/cgi-bin/mapserv?map=/home/havatv/mapserver/o-kart/okartinnhold.map&layer=o-kartpoint&layer=o-kartpolygon&layer=o-kartline

The test map is a special kind of map called an orienteering map (you can find the specification here: ​http://www.orienteering.org/i3/index.php?/iof2006/content/download/866/4026/file/International%20Specification%20for%20Orienteering%20Maps%202000.pdf). Orienteering maps has a number of advanced symbols, which makes it interesting for testing cartographic capabilities.

Håvard

[tbonfort]

Håvard,

is this still an issue ?

[havatv]

Size and "bounding box"/"reference point" calculations seem to be as they used to be before 5.4, so it looks like the issue has been resolved (as reported in comment number 7, above).