[Qgis-user] Inconsistent label positioning

[Tom Christian]

Hugh, Nicolas, thanks for your input.

*Hugh*: 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?

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.

*Nicolas*: 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.

Tom

On Fri, 19 Nov 2021 at 07:26, Nicolas Cadieux <njacadieux.gitlab at gmail.com>
wrote:

> Hi,
>
> 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.
>
> Nicolas Cadieux
> https://gitlab.com/njacadieux
>
> Le 19 nov. 2021 à 09:57, Hugh Kelley <hghklly at gmail.com> a écrit :
>
> 
> Hi Tom,
>
> I don't have a great solution for you but I'm following with some interest
> as I routinely struggle with fine tuning labels .
>
> A couple things I can offer:
>
> 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.
>
> 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.
>
> 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)
>
> 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.
>
> 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.)
>
>
> [0] https://github.com/qgis/QGIS/issues/28386
>
> <image.png>
>
>
>
> On Thu, Nov 18, 2021 at 3:24 PM Tom Christian <thomaschristian at gmail.com>
> wrote:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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:
>> https://www.dropbox.com/s/x3y4vfr20s9inqw/print-map-label-movements.gif?dl=0.
>> 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.
>>
>> I previously posted this question on gis.stackexchange but so far no
>> traction, so any input would be very much appreciated (
>> https://gis.stackexchange.com/questions/416430/qgis-inconsistent-label-positions-in-png-pdf-layout-exports
>> ).
>>
>> Thanks
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>
>
> --
> Hugh Kelley
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20211119/0a4bdeba/attachment-0001.html>