https://issues.qgis.org/https://issues.qgis.org/favicon.ico2012-10-01T04:56:12ZQGIS Issue TrackingQGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=354402012-10-01T04:56:12ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Assignee</strong> set to <i>Larry Shaffer</i></li></ul> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=363952012-10-10T00:41:09ZLarry Shaffer
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>Hi Vincent,</p>
<p>You are seeing three issues:</p>
<p><strong>Label becomes horizontal</strong> happens when you either have data defined x/y but not rotation, or have also defined rotation but have the 'preserve existing rotation values' option checked. Once the x/y are set on label move, with no available rotation column or value defined, the rotation defaults to 0.</p>
<p>The option to preserve existing rotation values is on by default because otherwise data loss could accidentally occur. See issue <a class="issue tracker-1 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/4317" title="New labeling: rotation for polygons is only applied after moving the label + the "issue" of needi... (Closed)">#4317</a>.</p>
<p><strong>Label no longer follows line</strong> happens when you pin the label. An initial move of a label is a pinning operation, where its x/y and optionally rotation values are written to the attribute table. Once a label becomes pinned, it is no longer treated like other labels for the same layer. It is essentially a point feature label plus any rotation. For example, any line vector type 'distance' setting (layer- or data-defined) no longer applies.</p>
<p>If you data define x/y and rotation, and uncheck the 'preserve existing rotation values' option, then move the label a rotation value will be written to the attribute table, <strong>BUT only for the first letter of a curved label</strong>, which is the third issue. (However, it should work fine with parallel-to-line placement.)</p>
<p>Curved labels are chopped up into their individual characters, each of which is essentially a separate label. The label position class apparently only stores the rotation value that belongs to the first character, which is the only rotation value written to the attribute table when the label is pinned. If the curved label geometry were to be retained, but offset (like in a move operation), a different approach would be to data define x/y offsets (which are already planned). The label and buffer could be drawn, then offset accordingly. This means a different tool (Offset Label?) or add another feature to the current move tool. It might also mean wasted label creation, if the subsequent offset takes the label out of the extent, but the original label was in it (i.e. label is created and offset but not shown).</p> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=363982012-10-10T02:04:52ZVincent Picavetvincent.ml@oslandia.com
<ul></ul><p>Hi,</p>
<p>Skipping the rotation part, which behaviour is ok as it works now.</p>
<blockquote>
<p><strong>Label no longer follows line</strong> happens when you pin the label. An initial move of a label is a pinning operation, where its x/y and optionally rotation values are written to the attribute table. Once a label becomes pinned, it is no longer treated like other labels for the same layer. It is essentially a point feature label plus any rotation. For example, any line vector type 'distance' setting (layer- or data-defined) no longer applies.</p>
</blockquote>
<p>Why is it working like that ? I would expect the label to keep attached to the original geometry, but with some parameters forced. Distance setting is not a problem, since it is naturally overridden by forced x,y coordinates (manually defined).</p>
<blockquote>
<p>If you data define x/y and rotation, and uncheck the 'preserve existing rotation values' option, then move the label a rotation value will be written to the attribute table, <strong>BUT only for the first letter of a curved label</strong>, which is the third issue. (However, it should work fine with parallel-to-line placement.)</p>
</blockquote>
<p>From a user point of view, «rotation» option and «following curve» option are really different thing. They should not interfere, even if behind the scene it's treated with the same mechanism.</p>
<blockquote>
<p>Curved labels are chopped up into their individual characters, each of which is essentially a separate label. The label position class apparently only stores the rotation value that belongs to the first character, which is the only rotation value written to the attribute table when the label is pinned. If the curved label geometry were to be retained, but offset (like in a move operation), a different approach would be to data define x/y offsets (which are already planned). The label and buffer could be drawn, then offset accordingly. This means a different tool (Offset Label?) or add another feature to the current move tool. It might also mean wasted label creation, if the subsequent offset takes the label out of the extent, but the original label was in it (i.e. label is created and offset but not shown).</p>
</blockquote>
I do not really understand the point here... For curved label to be displayed you need to know :
<ul>
<li>the coordinates of the first character (here manually pinned to a specific x,y)</li>
<li>the original geometry to follow</li>
</ul>
<p>And that's all, if you have that, you can recompute everything and display the label. <br />If internally each character is a different label, then each time the label is pinned, then all the single character labels positions and rotations should be recomputed to adapt to the curve to follow at that place. <br />No need for a new tool, just internal modifications.<br />Or I do not get it ?</p> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=364272012-10-10T08:19:51ZLarry Shaffer
<ul><li><strong>File</strong> <a href="/attachments/download/4953/one-candidate_a.png">one-candidate_a.png</a> added</li><li><strong>File</strong> <a href="/attachments/download/4954/one-candidate_b.png">one-candidate_b.png</a> added</li></ul><p>Vincent Picavet wrote:</p>
<blockquote>
<p>Hi,</p>
<p>Skipping the rotation part, which behaviour is ok as it works now.</p>
<blockquote>
<p><strong>Label no longer follows line</strong> happens when you pin the label. An initial move of a label is a pinning operation, where its x/y and optionally rotation values are written to the attribute table. Once a label becomes pinned, it is no longer treated like other labels for the same layer. It is essentially a point feature label plus any rotation. For example, any line vector type 'distance' setting (layer- or data-defined) no longer applies.</p>
</blockquote>
<p>Why is it working like that ? I would expect the label to keep attached to the original geometry, but with some parameters forced. Distance setting is not a problem, since it is naturally overridden by forced x,y coordinates (manually defined).</p>
</blockquote>
<p>See below about how varied candidates make this difficult to make it work as expected. Basically, once the x/y is data defined, the feature's geometry is ignored by PAL and just the mapped attributes are used. Although, some data defined attributes augment an existing label's calculation (e.g. distance). Newer additions (x/y-independent data defined rotation) to make pinned labels work as expected are patches to PAL and its wrapper class, rather than turning on/off any functionality in the PAL library itself. In other words, it's how PAL works, for now.</p>
<blockquote><blockquote>
<p>If you data define x/y and rotation, and uncheck the 'preserve existing rotation values' option, then move the label a rotation value will be written to the attribute table, <strong>BUT only for the first letter of a curved label</strong>, which is the third issue. (However, it should work fine with parallel-to-line placement.)</p>
</blockquote>
<p>From a user point of view, «rotation» option and «following curve» option are really different thing. They should not interfere, even if behind the scene it's treated with the same mechanism.</p>
</blockquote>
<p>I agree this is not the expected behavior one would expect when pinning a curved label. It is definitely a bug. Since PAL currently only has data defined x/y and rotation as its core data defined placement, it basically turns it into what appears to be a parallel-to-line label with a rotation that almost never makes any sense.</p>
<blockquote><blockquote>
<p>Curved labels are chopped up into their individual characters, each of which is essentially a separate label. The label position class apparently only stores the rotation value that belongs to the first character, which is the only rotation value written to the attribute table when the label is pinned. If the curved label geometry were to be retained, but offset (like in a move operation), a different approach would be to data define x/y offsets (which are already planned). The label and buffer could be drawn, then offset accordingly. This means a different tool (Offset Label?) or add another feature to the current move tool. It might also mean wasted label creation, if the subsequent offset takes the label out of the extent, but the original label was in it (i.e. label is created and offset but not shown).</p>
</blockquote>
I do not really understand the point here... For curved label to be displayed you need to know :
<ul>
<li>the coordinates of the first character (here manually pinned to a specific x,y)</li>
<li>the original geometry to follow</li>
</ul>
<p>And that's all, if you have that, you can recompute everything and display the label. <br />If internally each character is a different label, then each time the label is pinned, then all the single character labels positions and rotations should be recomputed to adapt to the curve to follow at that place. <br />No need for a new tool, just internal modifications.<br />Or I do not get it ?</p>
</blockquote>
<p>I wish that were all that's needed. :^) PAL doesn't receive the entire feature for its label candidates calculation (noted exception is when calculating the centroid for the whole feature). The QgsPalLabeling class clips a duplicate of the feature to the canvas extent prior to sending it into PAL, to speed-up overall label production. This means that for different panned extents or zoom levels the same feature is sent into PAL differently, thereby creating <em>very different</em> candidate solutions.</p>
<p>Since the candidates vary greatly, it would be would be difficult for PAL to 'know' which candidate your data defined x/y refers to. If it referred to <em>any</em>, the label would drastically change appearance as the user panned/zoomed. For example, as a test I set candidates for line layers to '1', turned on showing candidates and created a comparison of what a very small pan of the map produces (see attachments). You can see how different a solution PAL produces even for one candidate. My suggestion for label offsets would also fall prey to such a problem.</p>
<p>Ultimately, <strong>a solution that would solve this issue (and others) would be if a simplified polyline or bezier curve geometry were generated and storable for a given curved label</strong>. See old issue <a class="issue tracker-2 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/1780" title="Labels: Data defined position from geometry column (Closed)">#1780</a> for a similar suggestion. This could be added as an extension of the current PAL solution, where instead of a number of candidates for each character being returned, their base resultant polyline is returned and Qt is used to place the text on that path. In such a scenario, letter-/word-spacing, multi-line options (and others) would then be readily possible. In addition, when pinning the label (and there is a data defined geometry storage location) the simplified path and x/y coords could be saved. Once saved, general geometry manipulation tools could be used to change it, independent of its related feature geometry.</p>
<p>Such a solution would greatly enhance curved labels and fix most of the issues (including this one) with its PAL-based implementation.</p> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=528522014-06-21T12:28:24ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Open</i></li></ul> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=537492014-06-28T05:42:32ZJürgen Fischerjef@norbit.de
<ul><li><strong>Target version</strong> changed from <i>Version 2.0.0</i> to <i>Future Release - Lower Priority</i></li></ul> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=786292017-04-30T23:09:39ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Easy fix?</strong> set to <i>No</i></li><li><strong>Regression?</strong> set to <i>No</i></li></ul> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=875892018-02-25T10:25:15ZRegis Haubourgregis.haubourg@oslandia.com
<ul><li><strong>Description</strong> updated (<a href="/journals/diff/87589?detail_id=76342" title="View differences">diff</a>)</li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=876222018-02-25T16:52:01ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Assignee</strong> deleted (<del><i>Larry Shaffer</i></del>)</li></ul><p>Hi Regis, why lowering the priority for this? isn't this a quite important labeling issue?</p> QGIS Application - Bug report #6439: Curve label becomes horizontal when x,y are manually sethttps://issues.qgis.org/issues/6439?journal_id=1023162019-03-09T15:04:24ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li><li><strong>Resolution</strong> set to <i>end of life</i></li></ul><p><strong>End of life notice: QGIS 2.18 LTR</strong>
<strong><br />Source:</strong><br /><a class="external" href="http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/">http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/</a></p>