[Qgis-user] Inconsistent label positioning

Sat Nov 20 20:39:57 PST 2021

Thanks again for the suggestions.

Unfortunately the alternate rendering engine did not address label
positioning inconsistency but I'm glad to learn of that option.

As for how change detection works: I appreciate the input but I'm confident
our current approach best reflects the needs of the project,
notwithstanding the labelling issue and its false positives. This project
exists primarily to create rendered layouts and therefore anything that
affects the appearance of a layout must be reviewed as part of a Pull
Request. This includes .qgs project file changes, data changes, icon
changes etc. All content is currently version-controlled, and whilst having
the ability to revert changes is obviously very useful it's much better to
avoid unwanted changes in the first place. Pushes / merges to the main
branch kick off our continuous deployment process, which publishes rendered
layouts to our website, so our reviewers need to see any modifications to
those layouts from all sources before they merge. Here is an example:
https://github.com/Bulkley-Valley-Cross-Country-Ski-Club/mapping/pull/45

Currently my best option seems to be generating the "before" and "after"
layouts multiple times. What I've observed is that not all label positions
are equal - positioning will often be identical for 75% of a layout's
exports and my false positives change detections occur when one of my
images is from that 25% where a label changes position. If I create - for
example - three exports of each layout and compare all images then a single
match tells me that any changes are actually false positives. If all
"before" and "after" images differ then there is a higher chance of a
genuine change. This will obviously increase processing times but should
reduce false positives while having no effect on true positives.

Of course, I would much prefer a way to guarantee consistent label
positioning decisions from QGIS. I can't imagine why this would be
non-deterministic, though I'm confident there is a good reason behind it.

Tom

On Fri, 19 Nov 2021 at 11:46, Hugh Kelley <hghklly at gmail.com> wrote:

> that's a good point about needing to dif the label settings. I may have
> misunderstood your use case a little.
>
> it's worth distinguishing between the need to see a diff of data changes,
> and a diff of rendering changes, i.e. changes to the qgis file itself vs a
> change to a file or db it's pulling data from.
>
> I thought based on *"Here is one example of a label move when no data has
> changed (see bottom-right)" *from the S/O question that you were mainly
> concerned with data changes.
>
> it sounds like you may be also or more concerned with changes to the QGIS
> file.
>
> it's possible that you'd be better off with a combination of Data
> versioning and applying version control to the QGIS file rather than trying
> to accomplish these two things simultaneously by diffing the image exports
> themselves.
>
> As far as data, whenever a row of data is changed, you can generally set
> up an automated way to record the username who made the change and the
> current timestamp. You can then review all changes made within a given
> time.
>
> As far as the qgis file, if you unzip the qgz with 7zip you'll get a qgs
> file which is just text xml, which can be diffed for changes. You may need
> to install this plugin to prevent reordering of xml elements.
> https://plugins.qgis.org/plugins/trackable_project_files/
>
> i think there's a lot of potential for git version control integration
> into QGIS but there's a substantial amount of work to be done on exactly
> how/when to trigger a commit so a good plugin is on my very long term todo
> list and probably a very long way off.
>
> On Fri, Nov 19, 2021 at 1:57 PM Tom Christian <thomaschristian at gmail.com>
> 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.
>>
>> 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
>>>
>>>
>
> --
> Hugh Kelley
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20211120/555068ad/attachment.html>