New symbology fails to render "problematic" lines at high zoom levels

[qgib]

Author Name: Sandro Santilli (@strk)
Original Redmine Issue: 4514
Affected QGIS version: master
Redmine category:symbology

---

The following WKT has a few rendering problems.
It is a V shaped figure. One element is the full V, the other two are the two wings.
The bottom node is cohincident for the two wings, but it's moved on the left for the full V.

Beside other rendering problems, for which I'll file another bug, this one is about a different threatment between old symbology and new symbology. To reproduce:
Applying old symbology and zooming on the right wing until you see two lines.
Then switch to new symbology and apply it. The lines will disappear.

This is with a recent build from master, and specifically commit be9bdeb

MULTILINESTRING(
(
832709.937 816560.25,
832705.813 816470.25,
832661.937 816561.875
),
(
832705.812 816470.25,
832709.937 816560.25
),
(
832661.938 816561.875,
832705.813 816470.25
))

---

• topotest.png (Sandro Santilli)
• QgsRubberBand.PNG (Serge Dikiy)

[qgib]

Author Name: Sandro Santilli (@strk)

---

I was wrong about the actual shape.
Now made a drawing to represent it.

---

• 3542 was configured as topotest.png

---

• topotest.png (Sandro Santilli)

[qgib]

Author Name: Sandro Santilli (@strk)

---

!topotest.png!

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• category_id was configured as Symbology

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• fixed_version_id was configured as Version 1.7.4

[qgib]

Author Name: Sandro Santilli (@strk)

---

Well, since I was wrong about the shape this ticket is invalid.

---

• version was configured as master
• status_id was changed from Open to Closed
• resolution was changed from to invalid
• crashes_corrupts_data was configured as 0

[qgib]

Author Name: Sandro Santilli (@strk)

---

Actually, since old and new symbology behave differently this is likely still a valid bug.
I was looking for this ticket because I had another similar occurrence of it.
Lines disappearing on zoom in.

I'm not sure, but it could have to do with lines clipping done in 17e864b
which I think addressed #14071 in addition to the reported #14066.

---

• status_id was changed from Closed to Reopened
• resolution was changed from invalid to

[qgib]

Author Name: Sandro Santilli (@strk)

---

Here's another input showing the problem:

LINESTRING(556267.657697 144886.732981, 556267.657697 144886.732981, 556267.517494 144888.366260)
LINESTRING(556235.246910 144885.298021, 556235.246910 144885.298021, 556254.670000 144886.620000, 556267.657697 144886.732981)
LINESTRING(556267.657697 144886.732981, 556310.040000 144888.170000, 556317.280000 144888.990000, 556328.490000 144888.800000, 556329.964330 144889.104630, 556336.040000 144890.360000, 556354.074605 144896.287433, 556362.830000 144899.280000)

I hit another bug while trying to reproduce (#14879) because the problem can't be reproduced with old symbology (or maybe w/out labels, not sure yet).

[qgib]

Author Name: Sandro Santilli (@strk)

---

Ok, with #14879 fixed the input in previous commit is enough to reproduce this bug. Doesn't need labels, just switching to the new symbology. Zoom on the intersection of the 3 lines to see them moving.

[qgib]

Author Name: Sandro Santilli (@strk)

---

Note: it renders fine up to scale 1:10, fails at 1:5 and higher

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was changed from Version 1.7.4 to Version 1.8.0

[qgib]

Author Name: Serge Dikiy (Serge Dikiy)

---

Hi, @strk

https://github.com/qgis/Quantum-GIS/blob/master/src/core/symbology-ng/qgsrendererv2.cpp#L79

New symbology use "Line clipping":http://en.wikipedia.org/wiki/Line_clipping only if ( nPoints > 100 )

I use a very simple patch to fix the problem :-)
https://github.com/qgis/Quantum-GIS/pull/179/files

[qgib]

Author Name: Marco Hugentobler (@mhugent)

---

The fix is applied, thank you Serge.
The symbology-ng line clipping has been made to overcome performance issues with large lines (the Qt clipping itself is too slow). If you say that it also fixes precision problems with shorter lines, that's fine.

---

• status_id was changed from Reopened to Closed

[qgib]

Author Name: Sandro Santilli (@strk)

---

I'd like to have a chance to actually test this.
My impression was the "clipping" was the cause of the bug, not the cure.
That's based on the fact that "old" symbology (surely not clipping) doesn't suffer from the bug.

---

• status_id was changed from Closed to Reopened

[qgib]

Author Name: Marco Hugentobler (@mhugent)

---

Thanks for your availability to do more tests, that will be helpful.
Btw. the old symbology clips linestrings too, but with a different algorithm (see function QgsVectorLayer::drawLineString)

[qgib]

Author Name: Serge Dikiy (Serge Dikiy)

---

I think this is a bug Qt.
This bug appears when the ratio of the line segment to its thickness exceeds a certain value.
Bug is not reproduced for the line width greater than 0,3. (I use dataset from original post)
Bug is not reproduced for the dotted line style.

"clipping" reduces the length of the line before rendering.

[qgib]

Author Name: Sandro Santilli (@strk)

---

Ok, tested. 5b09b96 looks fine to me. Thanks a lot.
Would be great to have this case under regression testing.

---

• resolution was changed from to fixed
• status_id was changed from Reopened to Closed
• done_ratio was changed from 0 to 50

[qgib]

Author Name: Serge Dikiy (Serge Dikiy)

---

...but QgsRubberBand have same issue.
!QgsRubberBand.PNG!

---

• 4592 was configured as QgsRubberBand.PNG

---

• QgsRubberBand.PNG (Serge Dikiy)

[qgib]

Author Name: Sandro Santilli (@strk)

---

do you mean there are still differences between old and new symbology ? That's my main concern, hoping to see one fully replacing the other asap (so to all focus on a single implementation).

[qgib]

Author Name: Sandro Santilli (@strk)

---

For the record: it was sorted out in IRC that the RubberBand thing has nothing to do with this ticket and that it will eventually need a separate ticket to handle.