This is useful when an algorithm returns features in no particular order
and sorting features by attributes does not help because there may be
features with the same attributes, giving non-unique sorting orders.
This is useful with geometry algorithms when the order of the coordinates of produced
geometries does not need to be exactly the same every time, but the output is still
topologically equivalent.
Resolves all overlapping geometries just like GRASS or Arc do.
So now we have two variants of union:
- union(A) - does union within geometries of one layer
- union(A,B) - does union between geometries of two layers
For union(A,B) algorithm if there are overlaps among geometries of layer A or among geometries of layer B,
these are not resolved: one needs to do union(union(A,B)) to resolve all overlaps, i.e. run single layer
union(X) on the produced result X=union(A,B)
This should also address issues raised in #17131
The DisplayVersion value in Uninstallkey registry hive (Software\Microsoft\Windows\CurrentVersion\Uninstall) is mandatory for deployment software, it allows them to check quickly from standard registry path the currently installed version.
The VersionNumber value is already stored in Software\QGIS (version)\ hive but that's not a standard for deployment solutions.
Because users are still getting confused with the difference
between the cartesian areas and ellipsoidal areas, show both
in the identify results dock.
The reasoning here is:
- if a user understands this concept, they will know the correct
one to use, and its good for us to inform them of the difference
here. Plus, it means they immediately see if the ellipsoid
setting is correct and the difference it is making for the
area/length calculation.
- if a user has no idea what the difference is, then we should
make them aware that there's (at least!) two different possible
measurement values. They can then either research what these mean and make
the right choice (and become better informed GIS practitioners),
OR pick a random one - which really is no different then the
previous situation, because an uniformed user is just as likely
to be working in an unsuitable projection with a poor ellipsoid
choice.
In short, we don't try to guess the right choice for users
and instead give them all the information and let them make the
call which value to use.
Often the polygonZ/multipatch data do not have consistent ordering of vertices
(e.g. all clock-wise or counter clock-wise). Disabling culling helps to avoid
seemingly missing surfaces, but the shading is still not correct due to reversed
normals. This new option to add back faces fixes the problem: for each triangle
we create both front and back face with correct normals - at the expense of increased
number of vertex data.
