This enum was forcing an include of qgscoordinatetransform.h within the
widely used qgsabstractgeometry.h header, causing an absolute explosion
of includes of a bunch of very heavy header classes all across QGIS. By
removing the forced include we can avoid a ton of unwanted includes
and make wider use of forward declarations...
And use it from QgsVectorLayerFeatureIterator
References #472
The current implementation is really just a wrapper around distance()
but opens the door for future improvements
expressions instead of raw expressions
We can greatly simplify the code by doing so, as all the handling
of preparing and optimising QgsPropertys are done automatically
for symbol layers.
Instead we should ALWAYS use the provided points for rendering symbol
layers, or the symbol layer will be broken in various circumstances
(e.g. when used outside of a vector layer)
Fixes#45028
Usually a geometry generator expression must return a geometry
in the associated layer's CRS. But this doesn't work in situations
where a geometry generator symbol is NOT associated with a layer,
e.g. when used in a layout item.
So add a new option to allow users to specify which unit the expression
will return geometries in, with choices of map units (the default,
previous behavior), millimeters, pixels, inches and points.
When millimeters, points, inches or pixels is selected then
the @map_geometry variable will be available for the expression,
and contain the feature's geometry in the specified units (relative
to the map frame). (The $geometry variable remains available and
still in layer CRS, in case an expression needs to calculate the
original area, perimeter, etc in real-world units while returning
results in a different unit!)
A step toward fixing #39159
[mesh] UX fixes:
* move mesh elements click->move->click instead press-> drag->release
* allow to select by drawing a polygon and select an existing polygon in the same map tool like for vector layer)
