GRASS GIS, in addition to importing data in its native formats via
`r.in.gdal`/`v.in.ogr` (and likewise `r.import`/v.import`),
also supports `r.external`/`v.external` which only link the data into
the GRASS DB.
Nevertheless, both `r.external` and `v.external` occasionally have problems,
especially on windows. E.g.:
- https://trac.osgeo.org/grass/ticket/3927
GRASS 7 Processing Plugin already has a setting that controls whether
`v.external` is used (disabled by default).
With this commit the complementary setting for `r.external` gets added too.
Usage of `r.external` is disabled by default. This is changing the existing
behavior, which was to use r`r.external`. The downsides of this change
should be the somewhat lower import speed + higher disk usage. Nevertheless
this way we have the same default value as `v.external` + we circumvent the
`r.import/v.import` shortcomings.
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
When using `buildrpms.sh -u`, the script fails with:
```
Wrote: /builddir/build/SRPMS/qgis-*.src.rpm
Finish: rpmbuild -bs
Finish: buildsrpm
INFO: Done(qgis.spec) Config(default) 0 minutes 22 seconds
INFO: Results and/or logs in: result
INFO: Cleaning up build root ('cleanup_on_success=True')
Start: clean chroot
Finish: clean chroot
Finish: run
Source package created
Source package unavailable. Abort
```
The reason was because a wrong src.rpm file name was extracted by sed.
Instead of `qgis-*.src.rpm`, what was being extracted is
`qgis-*.src.rpm\r` which includes a carriage return. This change removes
any character at the end of the `.rpm` when extracting the file name.
Motivation :
Move the QgsRasterLayerProperties class to the GUI API.
So, this class could be used using the QGIS API, notably for standalone applications.
The instance of this class was dependent, since QGIS 3.8, from the QgisApp instance, when calling the askUserForDatumTransform(). As this method, defines a title and only call QgsDatumTransformDialog::run() method from the gui API, this PR purpose to :
Offers the following benefits over the GRASS/SAGA versions:
- Full support for z/m values and handling curved geometries without loss
of curves
- Works with all native data types, no need for format transformation
- Supports dynamic (data defined, per feature) translate/scale/rotate parameters
- Allows transformation and scaling of both Z and M values (if present)
- Supports in-place edit mode
Fixes#33550
Instead of just considering the "candidate furthest from the polygon
rings" as the best, also consider that candidates closer to the
overall polygon centroid are better than those further from the centroid.
I.e. if two candidates are similarish distances from a ring, pick the
one closer to the centroid instead of the one further from the centroid
(even if that further one is a tiny bit more distant from a ring)
Instead of basing the initial dx/dy for the grid-based polygon candidate
generation on the size of the label itself, instead use either the
engine setting for polygon label density OR try and infer this from the
maximum number of candidates to generate for the polygon.
This avoids numerous issues with the label-size based approach:
- small labels (e.g. 1-2 digit labels) would generate a HUGE number of candidates
because the initial dx/dy were very small
- large labels would generate very few candidates, giving few options for
placement within these polygons (due to initially large dx/dy)
- by generating much more candidates then desired for small labels,
all the candidates further from the polygon centers would be culled
at a later step, meaning that the only candidates available for the
labeling problem solving would be clustered around a very small area
of the polygon (instead of distributed over the whole polygon)
