by QgsCoordinateTransformContext.calculateCoordinateOperation corresponds
to the reverse of what's actually required.
Gross API, but it's the best we can do until proj has a method to
invert a coordinate operation so that we can return the proper
inverse operation proj string from calculateCoordinateOperation
(without resorting to fragile proj string parsing/mangling)
from the proj string via the transform context
This isn't possible -- only proj coordinate operations constructed
from a src/dest CRS pair can be normalized, not those constructed
from a proj string.
It was redundant in any case, since we always normalize the available
operations before giving users a choice of them.
So just add some big bold warnings to the dox in case anyone is
manually manipulating and adding custom operations, that these
also MUST be pre-normalized
Refs #33121, conversation in https://github.com/OSGeo/PROJ/issues/1794
I'm not sure which of QT 5.9.0 or gcc 5.5.0 is not happy, but with both
of them, I get:
```
/opt/qt59/include/QtCore/qflags.h: In instantiation of ‘QFlags<T>& QFlags<T>::setFlag(Enum, bool) [with Enum = QgsDxfExport::DxfPolylineFlag]’:
/home/even/qgis/QGIS/src/core/dxf/qgsdxfexport.cpp:1102:68: required from here
/opt/qt59/include/QtCore/qflags.h:153:46: error: no match for ‘operator~’ (operand type is ‘QgsDxfExport::DxfPolylineFlag’)
return on ? (*this |= f) : (*this &= ~f);
```
of labels, min size for labels) to a new class QgsLabelThinningSettings
This new class is designed to contain settings related to how the label
engine removes candidate label positions and reduces the number of
displayed labels.
So that these files are all grouped together, making it easier to locate
all the components of the labeling engine and hopefully making things
easier to navigate
* [feature] support datasets with data defined on faces in mesh calculator, fix#30219, fix#30170
added "driver" and "group name" to the calculator interface.
MDAL now supports 3 drivers for storing results, so user must be able to choose appropriate driver and dataset group name (some drivers store multiple groups to 1 file)
instead of using only one ThreadPoolExecutor for all MetaTiles, its now handled in a loop and new ThreadPools for the next zoom level will be started when all work for the previous one is already done. i guess, this will fix the issues and interferences described in #32471 and shouldn't be much slower.
