CRS validation, regardless of the user's settings
This avoids hacks put in place in other parts of QGIS code or in plugins
to temporarily deactivate the CRS validation prompt, providing a supported,
stable method to indicate that when loading a particular layer no CRS
validation is required.
a layer is loaded which has no CRS
This is the new default behavior. It effectively defers the choice of CRS
from layer loading time to a later time which is convenient for users. E.g.
it no longer asks for CRS choice 100x when loading 100 files into QGIS at once.
(Effectively an application crash/hang... no one will sit through these 100 dialogs!)
The new behavior means there's no prompt (by default!) when loading these layers,
and instead the layers will be shown in the layer tree with an "unknown CRS"
indicator icon. They'll also be un-referenced, with coordinates from the layer
treated as purely numerically, non-earth values. I.e. the same behavior
as all layers get when a project is set to have no CRS.
The user can then resolve these in their own time, and by using convenient
shortcuts like highlighting multiple layers at once and then setting the CRS
for all these in a single action.
Fixes#19762, #27634, #24815 (and probably others)
Because:
1. There's very little chance this is the correct choice for the layer
2. WGS84 use MUST be discouraged moving forward and the spatial community
needs to move away from this CRS (see https://www.opengeospatial.org/blog/3045
for justification)
3. It's better to fallback to an unknown CRS and correctly reflect
this ambiguity in the GUI for users
This is a follow-up of https://github.com/qgis/QGIS/pull/31772
Driver de-registration is now defered after application restart to avoid
any risk of potential crashes if a dataset using a disabled driver was
already in use.
Likely also fixes other bugs relating to use of non-EPSG authorities,
by making QgsCoordinateReferenceSystem::createFromString correctly
handle other authorities and avoid forced conversion of the identifier
to a number.
Some OAPIF/WFS3 datasets uses UUID as the layer name, so this is highly
impractical for the user. However they publish a user friendly name in
the TITLE metadata, so use that.
OAPIF/WFS3 datasets can be very slow, up to the point where this freeze QGIS
for hours, when they have a lot of collections (i.e. layers), because:
- the feature count is absent from collection metadata, so it
would require a full scan of the collection
See https://github.com/opengeospatial/ogcapi-features/issues/261
- the layer geometry type is absent from collection metadata.
See https://github.com/opengeospatial/ogcapi-features/issues/262
OGR curretly does one /items request to get the first features and guess
the geometry type for it, but this approach is still too slow with datasets
with a huge number of collections.
- the layer extent is generally present in the metadata, but some servers
do not offer it, so if OLCFastGetExtent reports FALSE, return a world bbox
instead of iterating over the whole collection
This is best used together with the latest enhancements & fixes of the
OAPIF driver of GDAL master (503585c5abe8c3f8fde428af8b3f511d4fa3359f)
or with their backport to GDAL 3.0 branch (https://github.com/OSGeo/gdal/pull/1910)
Since 144e9a2e457d48ca7680d6bbc7a0c74b59a6b2ad, we no longer use
':' as the separator for the OGR sublayer informations. Consequently
we no longer need the hack that was needed to merged back Windows
paths like "C" : "\foo"
