Add ANCHORPOINT support when drawing marker symbols

[tbonfort]

This ticket is to track the anchorpoint addition to symbol objects, proposed in rfc 45.

[tbonfort]

code committed in r12718 and tests in r12719

succinct documentation:

SYMBOL now has an ANCHORPOINT property that takes two floating point numbers between 0 and 1.

the numbers are the proportion of the symbol width/height where the symbol should be anchored, and defaults to 0.5 0.5 (i.e. the center of the symbol, which is the previous behavior).

• ANCHORPOINT 0 0 : anchors the symbol on its top left corner
• ANCHORPOINT 1 0 : anchors the symbol on its top right corner
• ANCHORPOINT 1 1 : anchors the symbol on its bottom right corner

I have only tested this with truetype and ellipse symbols. Use of vector symbols will probably fail due to the way vector symbol sizes are calculated.

Havard, can you update the ticket once you get the time to try this out to confirm that this works as expected?

[havatv]

I am very glad to see this. I will test and document.

However, I think that for vector symbols, the position of ANCHORPOINT has to be specified using the same "coordinate system" as used for defining the symbol (in POINTS). Since ellipse symbols are also specified using POINTS, it would be natural that ellipse symbols are handled the same way as vector symbols.

For all other symbol types, a [0,1]x[0,1] coordinate system is a good choice.

[tbonfort]

Havard,

I am not inclined to modify the anchorpoint syntax to accomodate for vector symbols:

• the [0,1] notation has the advantage that it behaves identically across all symbol types, and you can be assured that 0,0 is top left, 0.5,0.5 is centered, etc...
• the vector symbol definition is ill-defined, and you basically cannot use them for precise symbol placement unless you ensure that their (minx,miny) is exactly (0,0). This is not enforced by the parser, and there are many symbol definitions that take advantage of this quirk to offset the symbol in undocumented ways. My point being that in most cases, vector symbols will not be placed correctly on their anchorpoint anyways.

Steve:

This should probably be another bug, but I wonder if we couldn't translate (and maybe scale) the vector points at parse time so that we can enforce that it's minx,miny is always 0,0 (and thus ensure that we calculate the size of the symbol correctly)

[havatv]

OK. I will test, and document. This is a great new feature anyway!

With the suggested ANCHORPOINT syntax, users should be encouraged to specify symbols with boundingboxes that have their top and left edge at 0. We should also let them know that if the bottom and right edge is at 1, the ANCHORPOINT can be specified using the vector symbol coordinate system.

But how do we handle symbols that are wider than they are high? Mapserver "scales" the symbols according to their height, so the resulting "base" symbols will always be one unit high. That means that symbols that are wider than they are high will have a "scaled" width that is greater than an one unit. I think this means that in order to let users specify the anchorpoint anywhere in the symbol, we must allow ANCHORPOINT x values to have any value ((-infinity,infinity)).

The possibility to use numbers greater than 1 to specify vector symbols is a great feature, as that avoids having to scale symbol definitions to [0,1]x[0,1]. In most specifications symbols, dimensions and symbol coordinates are in some metric unit (often millimeters).

When we have a fully functional ANCHORPOINT mechanism, I think we will avoid all the strange tricks that have been applied to achieve shifting effects, as there is no longer a need.

[havatv]

Testing, testing...

First: When testing, I realised that the ANCHORPOINT x value is scaled, so that 0 is at the left edge and 1 is at the right edge of the symbol. This voids the concerns that I raised in my previous comment.

Trying to use a negative x-value results in an error message, as expected.

I have tested symbol placement (ANCHORPOINT) combined with symbol scaling (SIZE), symbol rotation (ANGLE) and symbol shifting (OFFSET).

Pixmap symbols:
When no size is given, things seem to work as expected. I have tested 0,0 and 1,1 - both work perfectly. When a size is given, the anchorpoint is shifted to 0.5 in the x direction.

Truetype symbols:
Work as expected. Size can be used.

Ellipse symbols (minimum values 0 in x and y direction):
Work as expected. Size can be used.

Vector symbols:
Work as expected. Size can be used.

Hatch:
Does not seem to have any effect (as expected).

Summary:
The only bug I found was the one for pixmap symbols. Excellent work!!!

Håvard

[havatv]

The symbol document in trunk was updated to include ANCHORPOINT in r12721. I close the ticket. Thomas, should I add a new ticket for the pixmap problem?

[havatv]

I tested some more, and found that ANCHORPOINT has no effect when placing symbols on lines (I tested pixmap, truetype and vector symbols) using GAP. It would have been very useful if the symbol ANCHORPOINT was used also when rendering decorated lines. Asymmetrical (decorated) line symbols are not uncommon.

I have reopened the ticket and moved it back to the rendering api. Thomas, if you prefer to have new tickets, please let me know.

[havatv]

The trunk symbol construction document has been updated (r12724).

[havatv]

Never mind, I opened a new ticket (#4071). Closing this one.

[rouault]

Thomas, I've commited a few fixes in r12731 to fix compilation with MSVC. Usual tricks (variables declared after statements in .c files), but I've also replaced sincos() by sin() and cos(). sincos() is a GNU C extension (I guess you could reenable it with some #ifdef test)