Good evening Nikolaos:
Thanks for the discussion, replying to clarifying about the "centroid
distance" idea only, not recommending any action unless you like the idea.
I was thinking about how to consider both fontShrinkSizeMin vs
maxDisplacement as a single metric, one that would provide some stability
when zooming in and out. I wish I could draw pictures to help here.
For a text label (against a polygon or point geometry) we end up:
- A position where the label is trying to draw, often the centroid of your
polygon - all things being equal the label bbox will draw with the bottom +
left corner and this location:
+---+
| |
O---+
- Displacement moves the label location away from the original location by
a set dx,dy offset to produce a requested label location.
+---+
dx | |
O->X---+
- Alignment (between 0 and 1) adjusts the position of the label bbox
relative to this requested label location. The amount move is a percentage
of the label bbox so 0 is left, 0.5 is centre, 1.0 is right etc... Here is
alignment of 0 cx and 0.5 cy
dx +---+
O->X |
+---+
This produces the request label bbox placed into the label cache.
aside: I have not checked if max displacement considers any displacement
already defined by the user, or if it only considers how far to move the
requested bbox in the label cache from its initial position.
So back to my idea, both the fontShrinkMin and maxDisplacement parameters
can be combined into a single "score" if we consider how far the centre of
the label bbox ends up moving from the requested label location.
a) Applying displacement moves the centre of the label bbox - which
increases or decreases the distance between the centre of the label bbox
from the requested label location:
dx +---+
O--->X |
+---+
b) Changing the min font size adjusts the width and height of the bbox,
which also changes centrer of the label bbox - which increases or decreases
the distance between the centre of the label bbox and the request location:
dx ____
O->X__|
So if you wanted to optimize these settings "together" it is possible to do
so.
--
Jody Garnett
On Mon, 23 Dec 2019 at 19:05, Nikolaos Pringouris <nprig...@gmail.com>
wrote:
> Hi Joddy,
>
> I think "prioritaziation" from what I have seen by examining this "beast"
> class LabelCacheImpl (to be honest it is difficult to fully undestand it)
> works by performing an initial ordering on the label items before paint
> process occurs. Therefore labels with higher priority will be checked
> first for appropriate positioning during the paint process that follows
> depending on textSymbolizer options like "maxDisplacement",
> "fontShrinkSizeMin" etc.
>
> Now about the stable labelling it is difficult to say. Note that
> "fontShrinkSizeMin" works only for polygonal features and besides these 2
> mentioned options there are numerous others that affect the paint behavior
> like "goodnessOfFit", "polygonAlign" and so on. Considering fixed values
> for all other options my perception is that during zoom out
> "fontShrinkSizeMin" will definetally be preferred if we want labels not to
> dissapear and just that. During zoom in it really depends on the case. For
> example if there are other big size label at or near the centroid position
> "maxDisplacement" seems preferable.
> But zoom in/out is part of the picture. There other numerous other
> situations. The idea behind the introductions of fontShrinkSizeMin was to
> handle special cases of small area polygons where at a fixed scale the
> default symbolizer font size caused the label not to be rendered.
> "maxDisplacement" option wouldn't help at all.
>
> About the idea you propose I did not fully undestand it. What do you mean
> by "by optimizing how far the centroid of the label is from its preferred
> location"? Do you suggest another vendor option that would control which
> algorithm will apply first or just to modify internal LabelCacheImpl
> implementation so that we check all possible combinations of label
> positioning and finally select the one closest to the centroid (this can be
> really complicated in terms of implementation)?
>
>
> Στις Δευ, 23 Δεκ 2019 στις 4:37 μ.μ., ο/η Jody Garnett <
> jody.garn...@gmail.com> έγραψε:
>
>> I have read this carefully, and any feedback I provided is basically a
>> judgement call on what makes sense to me. I am doing my best to respect the
>> person doing the work get's to make those judgement calls :)
>>
>> I understand the three approaches you presented, I wonder what would
>> cause the least change as a map zoom's in and out (the most stable
>> labeling)?
>>
>> Idea: There may be a way to prioritize "both" these terms together - by
>> optimizing how far the centroid of the label is from its preferred
>> location. Adjusting size can bring the centroid closer, adjusting
>> displacement can move the centroid further away.
>>
>> Question: I feel like I am missing "priority" from the above
>> conversation. I would assume that labels with a higher priority get their
>> full size / preferred location before this tradeoff
>> between fontShrinkSizeMin vs maxDisplacement occurs (between labels of the
>> same priority). But this is only assumption, are you considering priority
>> here?
>>
>> --
>> Jody Garnett
>>
>>
>> On Sat, 21 Dec 2019 at 23:09, Nikolaos Pringouris <nprig...@gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> With the introduction of the fontShrinkSizeMin vendor option the process
>>> of determining the labelling of the feature in case both fontShrinkSizeMin
>>> and maxDisplacement options are defined has as follows:
>>> First the fontShrinkSizeMin algorith is applied trying to shrink and
>>> place the label and if this does not succeed then maxDisplacement
>>> iterations take place using the initially defined font size of the label.
>>> I would like opinions whether do you consider this to be a good
>>> attitude. On the one hand it seems rational that when shrinking is enabled
>>> on a label we first check that trying to place the label and if no success
>>> then go for the solution of maxDisplacement.
>>> (still we must make it explicit in the user docs since there is no
>>> reference now)
>>>
>>> Alternatives would be to:
>>> 1. 'interleave" the two processes (that is for each shrink size to
>>> apply all possible displacements)
>>> 2. 'interleave" the two processes in the reverse order of what is
>>> mentioned above ( that is for each displacement step check all shrink sizes)
>>> 3 apply first maxDisplacement and after fontShrinkSizeMin (I am not so
>>> positive to that I must admit)
>>>
>>> IMHO there is no perfect choice since depending on the situation
>>> somebody may have different requirements during rendering (i.e. (a) I may
>>> want to place labels as near as possible to their anchor points witihin
>>> polygons but not with reduced size, or (b) I have a long polygon I want
>>> just to place its label somewhere labels so check with displacement first
>>> but if font size is too big then resort to shrinking after)
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
