to a new project "capability"
This avoids the unwanted cost of initialising a blank style database
whenever QgsProject::clear is called and project styles are not
required (eg. for server)
This enhancement exposes any WMTS "time" dimensions for use in the
temporal framework, including allowing these layers to be animated
and controlled via the temporal controller.
There's some complexity involved here, because the WMTS specification
does NOT dictate how a time dimension should be exposed by services.
So different WMTS services are all handling this in different ways,
and we need to try to be as tolerant as possible.
Specifically, WMTS dimension values are just free-form strings, so
I've encountered a range of datetime formats -- e.g. "2021", "20210203",
"2021-02-03", "2021-02-03T12:13:14Z", and even WMS(T) style time
period designations ("2021-01-03T12:13:14/2021-01-05T12:15:11/P10M")!
These different formats all need special handling in order to correctly
interpret them as a date time value, and to be able to re-encode
an arbitrary datetime value back to the format string required
by the service. It's highly likely that we'll encounter additional
format strings when this feature is rolled out, and we'll need to
handle each individually.
When we do detect a time dimension on a WMTS layer, we no longer
expose this in the same way as other non-time dimensions. The browser
panel does not show the dimension values, and adding the layer
via Data Source Manager no longer prompts the user to pick from
the available time values. Instead, these layers are indicated with
a new "time capable raster layer" icon, and are added to a project
WITHOUT the user picking a specific time value.
Just like a WMS(T) layer, when a time-dimension enabled WMTS layer
is added to the project, it will default to the "automatic" temporal
mode, meaning that the layer will follow the temporal controller's
current time range by default. A user can then opt to show a specific
static time value for the layer through the layer's Temporal properties
page, by unchecking "Dynamic Temporal Control" and picking a specific
available time range from the "Predefined date" option. (Basically,
the user interaction and experience with a WMTS time enabled layer
is identical to with a WMS(T) layer).
Fixes#48364
- Move settings to be feature level, not layer level, and permit
data defined control of these settings
- Add additional option for overlap handling for "Always allow"
overlaps, which indicates that the user doesn't care at all
if the label overlaps other labels and that the ideal placement
should always be used for the label regardless of whether it
overlaps labels or not
To clarify further, the options are:
- Never Overlap : never ever place overlapping labels for the layer,
even if it means labels will be missing
- Allow Overls if Required: if the label can't otherwise be placed,
draw an overlapping label. This mode will cause the label to be moved
a less ideal placement if possible, e.g. moving the label further
from the center of a line or polygon, IF doing so will avoid overlapping
labels. But if there's no other positions possible, then draw the
label overlapping.
- Always Allow Overlaps": It doesn't matter at all if the label
overlaps other labels or obstacles, that's fine to do and the best
placement (e.g most central placement) should always be used even if an
alternate further placement is possible which avoids overlaps entirely.
two separate new options
This setting was ambiguous in meaning -- it could be interpreted
as either:
"I don't care about overlapping labels, use them when
you have no other choice"
OR
"I want to see labels for EVERYTHING in this layer, and I don't
care what you have to do to show me those"
This leads to situations like those discussed in #41043, where some
users interpret the setting as the first meaning and get confused
when eg. a curved label line layer starts showing horizontal placements
for some features which couldn't otherwise be labeled (eg short
lines).
So, split the setting into two new options (checkboxes) with explicit, clear
distinction:
- "Allow overlapping labels if unavoidable": This setting means labels
can be overlapping, if there's no other option. It does NOT gaurantee
that all features in the layer will have labels, because other
constraints (such as lines too short to fit a label's text) will still
be respected and may prevent labels for the feature.
- "Allow inferior fallback placements": This mode permits features
to fallback to worse placement options when there's no other choice,
e.g. when a line is too short to fit a curved label text then the
label may be placed horizontally just over the feature's center
point.
The combination of checking BOTH options WILL gaurantee that
all features in the layer are labelled, albeit with both overlapping
labels and the degraded placements!
Fixes#41043
transformations, such as those which happen across different
celestial bodies
If set, the flag indicates that no user-facing warnings should be
shown and instead the transform should be short circuited
Choices are "individual features" (the default behavior) or "continuous
surface". The new Continuous Surface option is designed for vector
layers which represent a continuous elevation surface, e.g contour
lines or surveyed elevation points. When selected, the elevation
chart will be rendered as a surface instead of separate features
by joining the sampled elevation results into a continuous line.
There's also the same option exposed as for raster and mesh layers
where the appearance can be toggled from a single line to a "fill
below" symbol.
Fixes#48341
using a fill symbol below the elevation surface
This can be easier to interpret in some cases, and helps match expected
symbology conventions in certain disciplines.
windows and docks between sessions"
If checked for a project, then any opened attribute tables will be
saved into the project and immediately restored when loading that
project.
Designed to improve workflows when a user has constructed a project
with a particular set of attribute table configurations for their
requirements, and re-setting up these attribute tables is a hassle.
"Remember editable layer status between sessions"
If checked, then any layers which are editable will be remembered
when saving that project and immediately made editable whenever
the project is restored.
This is an opt-in, per-project setting. The intended use case
is for users who are making complex, data-editing focused projects.
