QGIS » QGIS Application

Giovanni, a silent unexplained failure is not a good UX in any kind of way :)

I think there could be great benefit in QGIS indicating, either in the labelling dialogue itself or elsewhere, that a layer contains intersecting geometry that will prevent some labels from showing up. That way, your not leaving the user with a "huh, label now showing, black voodoo" but instead a useful hint that leads said user into fixing issue.

Btw Giovanni, thanks for the efforts your putting into keeping the hub's issues refreshed.

nirvn - wrote:

Giovanni, a silent unexplained failure is not a good UX in any kind of way :)

of course, I was just joking :) cheers!

Hi,

see also #2949
It seems to be fixed?

Gerhard

gespiel - wrote:

Hi,

see also #2949
It seems to be fixed?

Gerhard

no, it works for lines, but it fails for polygons.

I have implemented the ST_MakeValid function for QgsGeometry class to fix the related issues #9861 and #9777. The code is a fork from the original code in postgis implementation with slight changes:

https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/lwgeom_geos_clean.c

Also, the user can configure automatic validation of the fetched geometries of a layer and convert them to valid when needed.

https://github.com/qgis/QGIS/pull/1241

Best regards
Alvaro

Hi, I would like to propose an idea in order to avoid these problems derivated from on-the-fly-simplification.

Now, the geometries are simplified just when the data provider fetchs the geometry (https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrfeatureiterator.cpp#L322). These simplified geometries can be invalid and there are some problems with it in labeling engine, or expression evaluations that use its geometric attributes, and so on.

For all that, as I said, I would like to propose move the simplification to just where the geometry is converted to be drawed (https://github.com/qgis/QGIS/blob/master/src/core/symbology-ng/qgsrendererv2.cpp#L317). I think this is slower but safer than current status.

What do you think?

Best regards
Alvaro

Sorry, I forgot to say that the simplification executed in provider side remains unchanged. For postgis it executes "ST_snapToGrid" or "st_removerepeatedpoints" functions.

Alvaro Huarte wrote:

Hi, I would like to propose an idea in order to avoid these problems derivated from on-the-fly-simplification.

Now, the geometries are simplified just when the data provider fetchs the geometry (https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrfeatureiterator.cpp#L286). These simplified geometries can be invalid and there are some problems with it in labeling engine, or expression evaluations that use its geometric attributes, and so on.

For all that, as I said, I would like to propose move the simplification to just where the geometry is converted to be drawed (https://github.com/qgis/QGIS/blob/master/src/core/symbology-ng/qgsrendererv2.cpp#L317). I think this is slower but safer than current status.

What do you think?

Best regards
Alvaro

Hi, that sounds reasonable. Nyall, Martin, opinions?

For all that, as I said, I would like to propose move the simplification to just where the geometry is converted to be drawed

I'm not a fan of this approach. I think it's great how simplification also aids labelling at the moment. For instance, without simplification the "free" and "horizontal" label placements are so slow as to be nearly unusable. With simplification, they are fast enough to be used interactively.

I'd rather see the approach where liblwgeom is used to repair broken geometries explored.

Nyall Dawson wrote:

I'm not a fan of this approach. I think it's great how simplification also aids labelling at the moment. For instance, without simplification the "free" and "horizontal" label placements are so slow as to be nearly unusable. With simplification, they are fast enough to be used interactively.

Hi, another alternative could be to add the "SnapToGrid" algorithm (See liblwgeom: https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/ptarray.c#L1798) and check results. It is pretty simple and feasible integrate it in https://github.com/qgis/QGIS/blob/master/src/core/qgsmaptopixelgeometrysimplifier.cpp#L254 defining a new "algorithm" enum (possibly configurable).

That sounds like a better approach. I also think snap to grid simplification could be useful for composer exports... Eg, geometries could be simplied to a grid which is twice dpi, to remove redunant points from the resultant svg/PDF files.

I think I might try adding this new algorithm to test results (I will try to get time). It is complementary to the ST_makeValid implementation commented in other dedates.

Hi, I have created a new pull https://github.com/qgis/QGIS/pull/2483 to test results using the "SnapToGrid" algorithm by default.

It is a try to resolve the issue.

Alvaro