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);
```
`reloadData()` implementations are set to private on `reloadProviderData()`
All calls of `forceReload()` or `reloadData()` target `QgsDataProvider::reloadData()` what calls the implemented `reloadProviderData()` of the provider and `dataChanged()` signal is called allways. That this signal is called changes the behavior of the `dataReload()` calls of all providers.
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)
be shown to users when using that provider
This can be used to return a translated warning message which should be
shown to users of this provider. It's intended for use in cases such as
a provider which relies on a 3rd-party backend, where the version of the
backend software is not officially supported, or for alerting users to
providers in a "beta" or "untrustworthy" state.
- For project : check visible state for embedded layers inside an unchecked group, instead of putting all layers in embedded-invisible-layers
- For theme : Add an 'checked-group-node' to save group visible state independently to layers in it.
Fixes#33097
Stacked 3D meshes store values on the volumes that are regularly stacked over base 2d mesh. User can select various 3d to 2d averaging/interpolation method to convert values on volumes (3d) to values on faces (2d) that can be shown in mesh layer. This is achieved by new tab in the mesh layer properties dialog.
