<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2021-11-19 1:57 p.m., Tom Christian
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAG4HUneaa0xrZR4z4SeDBPnLjZvoVqDOX=GPLPUWmJZ=m6Hiww@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hugh, Nicolas, thanks for your input.
<div><br>
</div>
<div><b>Hugh</b>: I'm interested in trying your suggestion to
change the labelling engine but from your description, the
cropped image, and a little searching I cannot figure out
where this setting might be found. Can you please elaborate?</div>
<div><br>
</div>
<div>I've considered something similar to your "hacky" fix - I
was going to force "strict" label positioning during
comparison but still permit "preferred" label
positioning during final export, however the problem in both
cases is that then my visual diff will miss any changes made
to map label configuration. If one of the map maintainers
changes the way labels work in the final product I don't want
to override that during change detection and lose the ability
to review that change.<br>
<div><br>
</div>
<div><b>Nicolas</b>: label coordinates is not a good solution
for my use-case. Forcing labels to a certain location might
produce a satisfactory output at a given scale and viewport,
but it will not accommodate changes to scale and viewport
very well as in some scenarios the chosen label position
will not be in view even though part of the line is in view.
I have several layouts covering different parts of the same
trail network so I need to use QGIS's ability to place
labels in a context-sensitive way.</div>
</div>
</div>
</blockquote>
<p>You could also use a transparent buffer file for the labels
instead of a point layer (point -> buffer). You could then
specify that the label must be within this buffer. Perhaps that
could help QGIS place the labels.</p>
<p>Cheers!<br>
</p>
<blockquote type="cite"
cite="mid:CAG4HUneaa0xrZR4z4SeDBPnLjZvoVqDOX=GPLPUWmJZ=m6Hiww@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Tom</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 19 Nov 2021 at 07:26,
Nicolas Cadieux <<a
href="mailto:njacadieux.gitlab@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">njacadieux.gitlab@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">Hi,
<div><br>
<div>Just wondering if you are having the same problem
when using a x and y field for the label coordinates to
move the labels? In my experience, If you don’t want a
label to move, you lock is down with new x and y label
fields. I believe you can now save those coordinates in
the project file so you now longer need real fields in
the table.<br>
<br>
<div dir="ltr">Nicolas Cadieux
<div><a href="https://gitlab.com/njacadieux"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://gitlab.com/njacadieux</a></div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">Le 19 nov. 2021 à 09:57, Hugh
Kelley <<a href="mailto:hghklly@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">hghklly@gmail.com</a>>
a écrit :<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>Hi Tom, <br>
</div>
<div><br>
</div>
<div>I don't have a great solution for you but I'm
following with some interest as I routinely
struggle with fine tuning labels . <br>
</div>
<div><br>
</div>
<div>A couple things I can offer: <br>
</div>
<div><br>
</div>
<div>this feature request for the ability to lock
labels once they're generated [0]. There are a
number of issues, mostly closed, complaining
about unexpected label movement that are
consistent with what you're talking about. <br>
</div>
<div><br>
</div>
<div>overall, reading the github content, I don't
think there's currently a solution because the
labeling engine is not quite deterministic. I
don't imagine that's a small fix. I think in
ESRI world, the way they handle this is by
allowing the user to convert labels to an image
overlaid on the map, which has its own set of
major disadvantages. <br>
</div>
<div><br>
</div>
<div>For what it's worth, there are two labelling
engines in QGIS currently. You may have better
luck with one or the other. I have switched
entirely to the newer engine but it may be less
consistent so you might try switching. You can
switch in the settings label properties'
automated placement settings. (Yellow gear icon
in the image below)<br>
</div>
<div><br>
</div>
<div>In terms of "hacky" fixes for your problem.
Could it be helpful to have a version of the
outputs without labels at all, check the diff
for those and then review the labeled exports as
necessary based on the non-labelled diff? All it
would take would be a common naming convention.
Git picks up a change in
"no-labeled_export_4.png" which means you check
"labled_export_4.png" for problems. I think that
would reduce false positives caused by moving
labels. Not a super elegant solution obviously.<br>
</div>
<div><br>
</div>
<div>best of luck, maybe this email will bring the
thread back to the top of someone's inbox on a
friday morning when they're in the mood to work
on something that's not work. (as is the case
for me currently.) <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a
href="https://github.com/qgis/QGIS/issues/28386"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/qgis/QGIS/issues/28386</a></div>
<div><br>
</div>
<div>
<div><image.png></div>
<br>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Nov 18,
2021 at 3:24 PM Tom Christian <<a
href="mailto:thomaschristian@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">thomaschristian@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I'd like to know if there's
anything I can change (e.g. a well-buried
advanced setting or environment variable) to
remove pseudo-randomness within QGIS's label
positioning.
<div><br>
</div>
<div>I have a QGIS project version-controlled
within Git and a process to export layout
PNGs from the base (before) commit and the
head (after) commit when a change is made.
These images are compared and any variation
flagged to a reviewer so that they can
verify each change is intended and expected
before merging to the main (release) branch.</div>
<div><br>
</div>
<div>I have line label positioning configured
as "Preferred Placement Hint" rather than
"Strict" positioning as the result is
significantly better when I allow QGIS to
make placement decisions on my behalf.
However, in this configuration there is some
pseudo-randomness where QGIS sometimes makes
minor changes to label positions even though
neither the data, the layout, nor the export
configuration have changed. This leads to
false-positives during change analysis.</div>
<div><br>
</div>
<div>Here is a GIF showing 5 sequential
exports in which two line labels move
slightly. Each of the 5 frames shows for 0.5
seconds: <a
href="https://www.dropbox.com/s/x3y4vfr20s9inqw/print-map-label-movements.gif?dl=0"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.dropbox.com/s/x3y4vfr20s9inqw/print-map-label-movements.gif?dl=0</a>.
One change is at "West Connector" near the
centre of the image and the other is at "The
Dip" near the centre of the inset map.</div>
<div><br>
</div>
<div>I previously posted this question on
gis.stackexchange but so far no traction, so
any input would be very much appreciated (<a
href="https://gis.stackexchange.com/questions/416430/qgis-inconsistent-label-positions-in-png-pdf-layout-exports"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://gis.stackexchange.com/questions/416430/qgis-inconsistent-label-positions-in-png-pdf-layout-exports</a>).</div>
<div><br>
</div>
<div>Thanks</div>
</div>
_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Qgis-user@lists.osgeo.org</a><br>
List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-user"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
Unsubscribe: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-user"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
</blockquote>
</div>
<br clear="all">
<br>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">Hugh Kelley <br>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<span>_______________________________________________</span><br>
<span>Qgis-user mailing list</span><br>
<span><a href="mailto:Qgis-user@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Qgis-user@lists.osgeo.org</a></span><br>
<span>List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-user"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/qgis-user</a></span><br>
<span>Unsubscribe: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-user"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/qgis-user</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Nicolas Cadieux
<a class="moz-txt-link-freetext" href="https://gitlab.com/njacadieux">https://gitlab.com/njacadieux</a></pre>
</body>
</html>