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"
