Respect the OnConvertFormatRegeneratePrimaryKey layer property when
making a temporary layer permanent.
This ensures that processing outputs which require primary key
regeneration will correctly get new primary keys when they are
initially run with a memory layer output, and then later that
memory layer is made permanent
Fixes#58942
In other cases we'll need a blocking hit test anyway, and we
run a risk of deadlocks if a non-preview render is then started
on the main thread.
Fixes#58496
Until now, coordinates of chunks of point clouds were using "world" coordinates,
i.e. they were relative to the 3D scene origin point. As a part of preparation
for large scene support (QEP #301), we need coordinates inside chunks to be
independent from the scene origin point. For each point cloud chunk, we pick
origin point as a corner of the chunk's 3D box, which should guarantee that
coordinates within chunk (floats) will have reasonable numerical precision.
I have also used the opportunity to simplify the code that handles point cloud
chunk coordinates: rather than having flipped coordinates (x,-z,y) inside chunks,
we are using map coordinates without flipping (x,y,z), only relative to the origin
point of the chunk. The flipping of axes is handled by QTransform attached
to each chunk. (Hopefully when all chunked entity implementations get updated,
we will be able to remove all the axis flipping everywhere by just removing
the rotation in associated QTransforms.)
There's also a fix for a crash, when point cloud uses coloring based on classification
and triangulation is enabled (the pointSize array was not getting populated for parent
nodes).
If point cloud rendering uses triangulation, the chunk loader
now may get cancelled before triangulation actually starts.
(So if e.g. user changes 3d renderer's properties, the refresh is faster)
There are 2 different parameters to check to define the output crs:
- the request parameter (`SRSNAME` from the request)
- the query crs parameter
For a `GET` request, if `SRSNAME` is set, both parameters are set and
equal.
For a `POST` request, only the query parameter is set if defined.
In `writeGetFeature()`, the `outputCrs` correctly takes into account
the query parameter. However, this is not the case for the output srs
name (`srsName`) which only takes into account the query CRS as an
auth id.
Therefore, the output srsName will always be defined as an authid
even if the parameter is an ogc urn.
This issue is fixed by first computing the output srs
name (`outputSrsName`) by taking
into account the query and the query parameters. Then, this name is
used to compute `outputCrs`.
The axis inversion needs to be checked on the output crs, not the
input one.
The existing test does not detect this issue because the requested
output crs is the same as the input one.
To cover this case, a new test with a output crs different from the
input one is added.
The `srsName` used in `QgsWfsGetFeature::startGetFeature` can be
defined with the `urn:ogc:def:crs:EPSG::X` syntax. In that case, the
destination crs is not valid because it is created with the default
`QgsCoordinateReferenceSystem` constructor which does not handle this
syntax.
Therefore, in that case, the requested transformation fails and the
envelope coordinates are always in the input crs (the layer one).
This issue is fixed by using
`QgsCoordinateReferenceSystem::setDestinationCrs` which handles the
ogc urn syntax.
The test suite already covers the `urn:ogc:def:crs:EPSG::X` syntax
case. However, this issue is not detected because the requested output
crs is the same as the input one.
