Vendor option "autoRotate" to automatically rotate labels that won't fit with horizonal orientation

Björn Harrtell added a comment - 03/Nov/10 4:15 PM If this is of any interest for official support I'd appriciate a review

Andrea Aime added a comment - 06/Nov/10 6:35 AM Hi Bjorn, the patch is simple and looks good. I was wondering if we could do better though. Especially with land parcerls or building it is easy to visually determine a sort of "right rotation" that the label should have to "align" with the polygon, and such angle is along the longest side of the minimum bounding rectangle (which does not normally have sides parallel to the axis). See here: http://softsurfer.com/Archive/algorithm_0107/algorithm_0107.htm#Minimal Rectangle There are known algorithms to compute such rectangle. What do you think? :-)

Björn Harrtell added a comment - 08/Nov/10 3:41 PM I've reimplemented using the JTS algorithm to calc MBR, attaching new diff. But perhaps both cases could be desirable? The MBR implementation is obviously more expensive and some users might prefer orthogonal labels only.

Andrea Aime added a comment - 09/Nov/10 1:54 AM Oh, I did not know JTS could do that! About only having orthogonal labels... humm.... we could have the auto rotate allow two possible values, "align" and "ortho" that would provide the two different behaviors. However I'm having a hard time trying to imagine a situation in which only orthogonal labels end up looking better than mbr aligned ones. Do you have one? :-)

Björn Harrtell added a comment - 09/Nov/10 9:42 AM Well, I'll agree that MBR aligned will probably be the most popular choice but typographic people might prefer orthogonal? :) I'm also wondering if "autoRotate" is a too generic name for this vendor param? I'm having a hard time figuring out a more specific though... but perhaps "polygonAlign" with options "axis" (default), "mbr" and "ortho" ?

Andrea Aime added a comment - 09/Nov/10 1:15 PM PolygonAlign... sounds good. mbr, ortho... the default case is actually to use the rotation manually specified by the label parameters. So maybe "manual" or "explicit"?

Björn Harrtell added a comment - 09/Nov/10 2:49 PM New implementation with vendor option renamed to "polygonAlign" using int value to choose method. Comment from code: Option to rotate labels for polygons in the following ways: 0 (default) - Place label aligned with x-axis 1 - Rotate label orthogonally with x-axis if the polygon is higher than wider 2 - Rotate label using the angle from the longest edge of the minimum bounding rectangle of the polygon. The angle will not be greater than 90 degrees and negative angle will be preferred when greater than 60 degrees.

Björn Harrtell added a comment - 09/Nov/10 2:55 PM Didn't think about the manual rotation. Updated patch, correcting the code comment: Option overriding manual rotation to align label rotation automatically for polygons in the following ways:   0 (default) - Disable any automatic rotation alignment 1 - Rotate label orthogonally with x-axis if the polygon is higher than wider 2 - Rotate label using the angle from the longest edge of the minimum bounding rectangle of the polygon. The angle will not be greater than 90 degrees and negative angle will be preferred when greater than 60 degrees.

Björn Harrtell added a comment - 09/Nov/10 3:02 PM BTW, I took the shortcut with int values to avoid string comparison or key/value logic or something to cache those comparions

Andrea Aime added a comment - 10/Nov/10 1:15 AM Getting better and better. A couple of comments: - I'd prefer to see strings being used instead of numbers. We can have an enumeration in the code to make that explicit - there should be no need to fiddle with the calculated angles, the label cache can determine if a label looks upside down and flip it automatically (have to try your patch for good, which I'll do Saturday I guess, but that's normally what happens) If you're generally satisfied with the patch I can do the last tweaks and commit it. Btw, where? I'd go only for trunk, or do you have a specific need for the change to be part of 2.6.x as well?

Björn Harrtell added a comment - 10/Nov/10 4:34 AM I'm generally happy with the results I'm getting. I'm ok with strings, and when thinking about it now it shouldn't require much code. If I didn't fiddle with the angle it would rotate freely as the code is now, but I'm guessing that might be fixable by moving the calculation to a more appropriate place in the execution? I need to backport to 2.6.x for the time being, but can manage that myself if it helps.

Andrea Aime added a comment - 13/Nov/10 2:43 PM Hi Bjorn, I give the patch a spin in my dev env. The ortho case works fine, the align case did not work so good when I first tried. See the "oddlabels.png" attachment. I modified the angle calculation logic to use the same math as the "labels along a line logic", then noticed the goodness of fit computation was not taking into account the label rotation and came up with the attached patch (still need to use strings instead of numbers, but I'll get there). With the attached patch I can get beautiful maps like the "alignBbox.png" one, but also quite ugly ones like statesaling.png. The latter just feels wrong, possibly because due to the shape it's hard to perceive the mbr and thus feel the label has the appropriate rotation. However I was thinking that in general it also looks bad because there's plenty of space to put a horizontal label instead. So I was thinking, what about changing the auto-rotation logic so that the label gets rotated only if the horizontal label does not fit the polygon (or try both orizontal and aligned and pick the one that fits the polygon best, as in, it's better contained in it)?

Andrea Aime added a comment - 13/Nov/10 2:54 PM Btw, here is also the building layer with the "ortho" labelling

Björn Harrtell added a comment - 15/Nov/10 3:00 AM Thanks for diving further into the patch/feature. I see your point about that MBR-alignment will only look good for certain data. Restricting rotation to only non-fitting horizontal labels seem to be a good idea in general (also for the ortho-alignment).

Andrea Aime added a comment - 21/Nov/10 2:58 PM Hi there. I've been beating my head a bit more on this one and here is the final result. The labelling looks quite a bit more pleasing with this "rotate only if needed" behavior. Also had to refactor the code quite a bit as the MBR computation takes quite a bit of time and if maxDisplacement is enabled it gets computed a number of times (so we need to cache it). Whew, quite late. I just have to change the options to use human readable labels and then I can commit it (next week, sorry, I'm wiped out enough for a Sunday already)

Björn Harrtell added a comment - 23/Nov/10 2:17 PM Nice work. I've implemented polygonAlign options using enumeration, hopefully it will save you some work. I'll try to get it backported too shortly.

Björn Harrtell added a comment - 23/Nov/10 2:29 PM Cleaned up old imports and comments

Björn Harrtell added a comment - 23/Nov/10 2:44 PM New class was missing in my last two patches

Björn Harrtell added a comment - 23/Nov/10 2:44 PM Backported to 2.6.x branch. Note that JTS 1.11 is required and updated with this patch.

Andrea Aime added a comment - 27/Nov/10 11:09 AM Hi Bjorn, I've committed the patch on trunk. Noticed that the patch on 2.6.x also upgrades jts to 1.11. When it was time to upgrade JTS we decided not to do that on the stable branch. Is there any actual need for JTS 1.11? If so it's something that has to be discussed on the devel list.

Andrea Aime added a comment - 27/Nov/10 11:15 AM Meh, yeah, I see the method for aligned labels has indeed been added at 1.11: http://lin-ear-th-inking.blogspot.com/2010/03/jts-version-111-released.html Bjorn, can you write on the ml and ask for the 2.6.x upgrade?

Björn Harrtell added a comment - 29/Nov/10 2:00 AM Done. I've tested your latest work on real parcel data. I think "rotate only if needed" is too aggressive. I'll try to produce some screenshot and example data ASAP.

Andrea Aime added a comment - 29/Nov/10 2:52 AM I guess that in order to get what you want you should also increase the GoodnessOfFit towards 0.9 or 1, that's what I did to get the results in the screenshots above

Andrea Aime added a comment - 29/Nov/10 2:52 AM I guess that in order to get what you want you should also increase the GoodnessOfFit towards 0.9 or 1, that's what I did to get the results in the screenshots above

Andrea Aime added a comment - 29/Nov/10 3:30 AM Btw, yesterday I wrote a quick blog about this that is now published: http://geo-solutions.blogspot.com/2010/11/geoserver-tips-tricks-auto-alignement.html

Björn Harrtell added a comment - 29/Nov/10 3:52 AM Ah yes I had GoodnessOfFit=0. Now using GoodnessOfFit=1 and getting really nice results.

Andrea Aime added a comment - 28/May/11 4:19 AM Mass closing all issues that have been in "resolved" state for more than one month without further comments