Merge connected lines and Line orentation dependant position error

[qgib]

Author Name: Phillip Shelton (Phillip Shelton)
Original Redmine Issue: 20809
Affected QGIS version: 3.4.2
Redmine category:labelling

---

Hi,

I model road traffic and I have found the Line orientation dependant position under Placement under labels, to be a very useful feature.
It allows me to present the direcitonal traffic volumes on the same side of the line object as they occur on the roads I am modelling.

I am also a fan of the Merge connected lines to avoid duplicate labels as it reduces the number of labels and can reduce "clutter" when producing maps.

However, when used together, they sometimes get it wrong. The Merge connected lines to avoid duplicate labels can cause the line orientation dependant position to get it wrong.

I am using a spatialite layer. it also happens for the mapinfo export of the same layer. It seems to get the same links wrong every time for a given QGIS version but possably a different link in different versions (V3.0.0, V3.2.3, V3.4.1 and V3.5.0)

The attribute I have used for the figures is ass_volume, but it happens for any of the attributes. Different attributes seem to have different chances of getting it wrong.

Thank you for looking into this.

---

• Flinders2.7z (Phillip Shelton)
• lineorientationdependantposition.PNG (Phillip Shelton)
• Mergedtoreduceduplicates.PNG (Phillip Shelton)

[nyalldawson]

I investigated this, but am having trouble seeing the issue. In my tests it all looks ok, and I can't reproduce using your dataset. Please retest on master.

[gioman]

Closing for lack of feedback.

[pjshelton]

Hi, sorry for being silent for so long.
labeltest.zip

attached is a smaller project that shows what I was trying to show you.

The problem is that the merge algorithm is too aggressive for my use case.

Features (fid in 3,8,20,22) all get labeled with the value 85 when the labeling value is (round(Ass_Volume/5, 0)*5). Then the merge connected algorithm merges all of them. And tends to put the 85 on feature with fid=8.

This still happens with 3.15.0_Master, Code revision 3af038f.

However, in my head, the feature with fid=8 is not part of the set, and should be labelled separately because it is for the other side of the road. even though it has the same value for its label as the other three features.

Is there anyway to add knowledge about which side of the line a label is expected to be placed (when the line dependent checkbox has also been ticked) to the merge connected algorithm?