Adds some text layout modes where the line heights are based
on cap heights or font ascent alone
These are required in order to port additional parts of QGIS
text rendering to the QgsTextRenderer class
Shows the text bounds of the label in red and baselines in blue.
Designed for debugging purposes only.
Also move label engine enums to Qgis, promote to enum class
to GPS options tab in QGIS settings
This is a more of a "set once and forget" setting, vs something
which needs to be frequently changed and always right in the user's
face.
In most cases of use of QGIS Server, it is not necessary to access the layers in write mode.
The read-only mode is sufficient.
We would like to introduce a new flag Qgis::ProjectReadFlag::ForceLayerReadOnly to
open layers in a read-only mode.
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
