[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
There's many different formats of WKT strings, so instead play it safe
and always export in the exact specified format instead of using a cached
value which may be a different format.
Following discussion with GDAL maintainers, it's been agreed that the consistent logic
to use across projects should be:
1. Proj strings: export as bound CRS, and treat a boundcrs match to a known CRS as equivalent
to the underlying source CRS
2. WKT strings: export without change, not as bound CRS, and DON'T treat boundcrs matches
as equivalent to the underlying source CRS
CRSes
May result in some CRSes which were previously identified as known standard CRSes
now being shown as User CRSes, but they aren't the same to we can't equate them.
If previously identified CRSes are showing as User CRSes now, then we should
investigate these upstream in the proj or gdal libraries, and get all fixes
in place upstream rather then trying to do this in QGIS code (which is
inevitably going to end up with an unmaintainable mess)
Previously whenever an unknown CRS (i.e. something which couldn't
be matched a standard or user crs) was encountered then it would
automatically be saved to the user's custom CRS database.
This meant that over time, the custom CRS database would fill
with dozens of random entries. Even a clean QGIS install would
pollute the custom projection list with a bunch of automatically
created random CRS definitions!
Instead, never auto save CRSes to the custom projection database.
Only projections which users have manually created via the custom
projection dialog should ever be available as User CRSes.
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
