[Qgis-user] Inconsistent label positioning
Nicolas Cadieux
njacadieux.gitlab at gmail.com
Fri Nov 19 13:21:27 PST 2021
On 2021-11-19 1:57 p.m., Tom Christian wrote:
> 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.
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.
Cheers!
>
> 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
>
--
Nicolas Cadieux
https://gitlab.com/njacadieux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20211119/d6de69e9/attachment.html>
More information about the Qgis-user
mailing list