(PATCH) Add support for pre-clip labeling

[project10]

Based on discussions on IRC and -dev, I have implemented pre-clipping labeling support. I will attach a patch which will attempt to determine the labeling points prior to clipping for POLYGON and LINE layers, and polygon/line shapes within ANNOTATION layers.

This behavior is enabled by the use of the LABEL_NO_CLIP processing directive, which can be set to any value.

Steve suggested that a shape copy be avoided in implementing this feature - I was not able to get it working in that manner. The shape needs to be transformed prior to determining the label point. However, clipping a transformed shape often mangles it (the normal method is clip, then transform). I was not able to see a way around this other than copying the shape.

[project10]

Some renders showing the behavior change: ​http://project10.net/ms/normal.png - current behavior

​http://project10.net/ms/normal-myissue.png - Why I didn't like the current behavior. My labels get 'dragged around'.

​http://project10.net/ms/annoclip-inview.png - Labeling of a polygon with my change

​http://project10.net/ms/annoclip-demo.png - If the map is panned, the annotation point stays fixed, even though part of the shape it annotates is now clipped.

​http://project10.net/ms/annoclip-partials.png - It also plays nice with partials.

[project10]

Enhanced patch which does not copy shape for POLYGON shape types/layers, but still does so for LINE layers/shapes.

[sdlime]

Is there a reason the copy is still done for line layers or is that forthcoming?

Steve

[sdlime]

Replying to sdlime:

Is there a reason the copy is still done for line layers or is that forthcoming?

Steve

Nevermind, I saw your follow up email about the label point generators for LINEs requiring pixel coordinates.

Steve

[sdlime]

I've applied this patch in the trunk. SVN was hanging for me but it seemed to go fine. There is a compile warning:

mapdraw.c:1266: warning: `annocallret' might be used uninitialized in this function

I didn't check it out though. Figured you'd know off the top of your head what it should be initialized to, I bet MS_FAILURE. Anyway, if you could try the trunk with your test cases then we can close this out.

Great addition, thanks!

Steve

[project10]

Thanks Steve for catching the uninitialized warning. The variable should be initialized to MS_FAILURE.

I have already been running this patch in my development environment for some time - once the warning is fixed it can be closed.

Thanks for deeming this worthy of trunk ;D

[sdlime]

Fixed, closing.