function during bulk index load from a feature iterator
Allows single-iteration of a source for dual purposes simultaneously,
e.g. doing other feature-based operations while still gaining the full
advantage of the bulk loaded spatial index without having to do multiple
feature iterations
settings and logic
The previous approach of a single fixed value which applied to ALL line and ALL polygon
features was... not ideal. It meant that all line features would be assigned the same
number of candidates, regardless of length. So a road of length 1 cm on the rendered
map would have an identical number of candidates as a 30cm road covering the length of the
whole map!! This resulted in both a lot of wasted calculations (generating a ridiculous
number of candidates for small lines at barely discernable distances from each other)
AND an insufficient number of candidates for lengthy features (resulting in worse label
placement for these features).
(The situation was similar, but even worse for polygons)
Now, the setting is reworked to "Number of line candidates per cm" and "number of
polygon candidates per cm2". This means that small features get much less candidates,
and large features get much more features! Both a win for map rendering speed in many
circumstances AND good cartography... now that's a nice Christmas gift for QGIS :)
Fix dependency inconsistency to project from QgsRelationManager
by forcing 'QgsRelation::createFromXml' to rely on project passed
to 'QgsRelationManager' instead of using 'QgisProject::instance()'
[FEATURE] [MESH] add new 3d stacked mesh averaging methods (top, bottom, sigma, depth, height, elevation)
see https://fvwiki.tuflow.com/index.php?title=Depth_Averaging_Results for description of the methods. method can be selected for 3d stacked mesh dataset in the new widget added for QGIS 3.12 in the mesh layer styling dialog
These should NOT be used, and auth:code or WKT definitions used instead.
Unfortunately some use of these methods are very heavily entangled around
other code, so we can't deprecate all of them until 4.0
Constructing CRS using Postgis srids is highly discouraged,
and instead CRSes should always be constructed using auth:id
codes or WKT strings.
QGIS 4.0: The logic should be isolated into the postgres
provider alone, and not exposed to stable API
[FEATURE] [mesh] Load reference time from MDAL when available
Also adds combo box to let the user set the provider time unit. This is particularly useful when MDAL incorrectly recognised the time units in the raw dat format (for example format does nof follow spec and it is not possible to determine if time interval is in hours or days)
fix#32186fix#33399fix#31933
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);
```
