Bug report #4634

[PATCH] New labelling engine: wrong label placement with both "around centroid" and "over centroid"

Added by luca76 - almost 13 years ago. Updated over 10 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:14535

Description

Tested on Qgis 1.7.2 and nightly (12-12-2011):

Steps to reproduce:

1. Open the attachment in QGIS;
2. Zoom in (see jpeg attachment);
3. Click on new labelling engine, enable it on "num" field;
4. Select "over centroid"

many labels are misplaced. In the jpeg I've drawn some arrows, indicating the errors.

label-bug.jpeg - JPEG showing label errors (48.7 KB) luca76 -, 2011-12-12 04:36 AM

newlabel-bug.zip - example shapefile for the bug (17.1 KB) luca76 -, 2011-12-12 04:36 AM

test.jpeg - Tested with qgis master (as 2014-05-28) (49.6 KB) luca76 -, 2014-05-28 06:15 AM


Related issues

Related to QGIS Application - Bug report #5256: QGIS polygon Centroid (NewLabeling bug etc) Closed 2012-03-29

History

#1 Updated by Giovanni Manghi almost 13 years ago

  • Target version set to Version 1.7.4

#2 Updated by Giovanni Manghi almost 13 years ago

  • Subject changed from New labelling engine: wrong label placement (with example) to New labelling engine: wrong label placement with both "around centroid" and "over centroid"
  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

Confirmed, strange things happens with both "around centroid" and "over centroid".

#3 Updated by Alister Hood almost 13 years ago

I can't reproduce it with current trunk on Windows.

#4 Updated by luca76 - almost 13 years ago

Alister Hood wrote:

I can't reproduce it with current trunk on Windows.

Downloaded current osgeo trunk on windows.

The bug is still present. Try to zoom in:

Coordinates  662789.4,5106991.6
Scale 1:574

you can see the polygons with empty labels, i.e. label .1912 is 3 or 4 polygons higher than its correct position.

#5 Updated by michele zanolli over 12 years ago

Confirmed with my own data. The horizontal(slow) option places the labels in the correct position, but is too slow.
The "over centroid" and "around centroid" options have a "non sense" behaviour

#6 Updated by Alessandro Ciali over 12 years ago

I'd experiencede the same behaviour, It seems to be related with small polygons, the label is moved away from it's correct position.

#7 Updated by Martin Dobias over 12 years ago

Confirmed. The PAL library calculates centroids by itself (not using GEOS) and apparently that code is suspectible to numerical errors. GEOS calculates the centroid fine, therefore GEOS should be used instead.

#8 Updated by Alexander Bruy over 12 years ago

See also #5256

#9 Updated by Paolo Cavallini over 12 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#10 Updated by Paolo Cavallini about 12 years ago

  • Pull Request or Patch supplied changed from No to Yes

#11 Updated by luca76 - about 12 years ago

  • Subject changed from New labelling engine: wrong label placement with both "around centroid" and "over centroid" to [PATCH] New labelling engine: wrong label placement with both "around centroid" and "over centroid"

#12 Updated by Paolo Cavallini about 12 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#13 Updated by Larry Shaffer about 12 years ago

Should be fixed for 'over centroid' (now called 'Offset from centroid') with commit 61a50225

'Around centroid' was not adjusted; the calculation is still done in PAL. The noted pull request might fix that, however.

Please test.

#14 Updated by Paolo Cavallini about 12 years ago

  • Status changed from Open to Feedback

#15 Updated by michele zanolli about 12 years ago

My test says that the bug is fixed, thanks a lot!

But I have another comment...

If you try the attached test layer from trapanator, you can see that some labels are still completely outside their polygons. For example, take a look on the feature with attribute "num" = 2295.

The simple problem here is that the centroid is not ever inside the polygon (if the polygon is not a "simple square"), so the label placement is (imho) not correct.

In postgis there is the function ST_PointOnSurface that "Returns a POINT guaranteed to lie on the surface."
See the doc in http://postgis.refractions.net/documentation/manual-2.0/ST_PointOnSurface.html

I think that the best solution could be to put the label over centroid, but if the centroid is not inside the polygon, move the label inside the surface.

An automatic placement of a label outside its polygon for me has no sense and is confusing

#16 Updated by Giovanni Manghi about 12 years ago

But I have another comment...

If you try the attached test layer from trapanator, you can see that some labels are still completely outside their polygons. For example, take a look on the feature with attribute "num" = 2295.

The simple problem here is that the centroid is not ever inside the polygon (if the polygon is not a "simple square"), so the label placement is (imho) not correct.

In postgis there is the function ST_PointOnSurface that "Returns a POINT guaranteed to lie on the surface."
See the doc in http://postgis.refractions.net/documentation/manual-2.0/ST_PointOnSurface.html

I think that the best solution could be to put the label over centroid, but if the centroid is not inside the polygon, move the label inside the surface.

An automatic placement of a label outside its polygon for me has no sense and is confusing

I guess anyway that this should be closed and this request added in a new ticket(?)

#17 Updated by Larry Shaffer about 12 years ago

michele zanolli wrote:

...
If you try the attached test layer from trapanator, you can see that some labels are still completely outside their polygons. For example, take a look on the feature with attribute "num" = 2295.

The simple problem here is that the centroid is not ever inside the polygon (if the polygon is not a "simple square"), so the label placement is (imho) not correct.

That is the calculated centroid location (as per the labeling option), so the label location is correct.

In postgis there is the function ST_PointOnSurface that "Returns a POINT guaranteed to lie on the surface."
See the doc in http://postgis.refractions.net/documentation/manual-2.0/ST_PointOnSurface.html

I think that the best solution could be to put the label over centroid, but if the centroid is not inside the polygon, move the label inside the surface.

An automatic placement of a label outside its polygon for me has no sense and is confusing

I agree there should be an option for moving any outlying centroid point to inside its polygon. There are several solutions. GEOS contains a PointOnSurface, though I could not find a public API call for it, it appears to be available via OGR. But the question is where would the on surface point end up?

One way to know where a surface point is going to be located is to translate due left or right from the calculated outlying centroid point and place a label in the center of the first found line or polygon that fully intersects the centroid's polygon. While not be a perfect solution, it may look reasonable in most situations. There are other solutions like finding the closest vertex or segment of the polygon (or other ray-casting techniques), then placing the point inside the polygon from there. See:

Algorithm for finding irrregular polygon centroid (label point)
http://gis.stackexchange.com/questions/2128

There also needs to be a more robust fixing of invalid GEOS geometries (bow ties, etc.) prior to finding the centroid. GEOS can fix some geometries, but there is some new research and GPL-compatible libraries available for this that may give better results, like pprepair:

https://github.com/tudelft-gist/prepair#readme

That is really a feature request and should be a new ticket, as Giovanni suggested.

#######################################

I may be able to re-work commit 61a50225 solution to also include support for centroids to be created via GOES for 'around centroid' labeling options. Until someone does something like that, or applies/tests the pull request, I think this issue should remain open.

#18 Updated by Giovanni Manghi about 12 years ago

  • Resolution set to fixed
  • Status changed from Feedback to Closed

With the latest changes in the labelling code, this seems fixed.

#19 Updated by Larry Shaffer about 12 years ago

  • Status changed from Closed to Reopened

Hi,

I have reopened this issue because the method used is no longer the GEOS centroid calculation that previously fixed the issue. The current fix uses the adjusted centroid calculation provided by Serge Dikiy:

https://github.com/qgis/Quantum-GIS/pull/201/files

5c294139ddc368f74d5d7dc6668d72d2a8633499

This allows the fix to be utilized in more places with the PAL engine. Please retest using this fix. If it does not cover all the issues, it is possible to replace it (in PAL) with a similar GEOS method, as before.

#20 Updated by Giovanni Manghi almost 12 years ago

  • Priority changed from High to Normal

#21 Updated by luca76 - over 10 years ago

  • File test.jpeg added
  • Resolution deleted (fixed)

Tested with qgis master (2014-05-28).

The problem is mainly fixed, except for some features. See the new attachment named "test.jpeg"

#22 Updated by Giovanni Manghi over 10 years ago

  • Status changed from Reopened to Feedback
  • Target version deleted (Version 2.0.0)

andrea76 - wrote:

Tested with qgis master (2014-05-28).

The problem is mainly fixed, except for some features. See the new attachment named "test.jpeg"

it doesn't seems the same case as the ones that originated this ticket... the label seems to be where the centroid of the feature is (whole feature or visible part). Please leave feedback.

#23 Updated by Giovanni Manghi over 10 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed/implemented

Giovanni Manghi wrote:

andrea76 - wrote:

Tested with qgis master (2014-05-28).

The problem is mainly fixed, except for some features. See the new attachment named "test.jpeg"

it doesn't seems the same case as the ones that originated this ticket... the label seems to be where the centroid of the feature is (whole feature or visible part). Please leave feedback.

closing for lack of feedback.

Also available in: Atom PDF