This exposes some basic temporal capabilities for vector layers:
- static time range for layer (to match raster layer possibilities), this
sets a single static time range which applies to the whole layer. ALL
features from the layer will be shown whenever the canvas time
overlaps the layer time range
- "Single field with datetime": Allows selection of a single date
or datetime field from the layer. Features will be shown whenever
this field value is within the canvas time range
- "Separate Fields for Start and End Date/Time": Allows selection
of start and end date/datetime fields from the layer. Features will
be shown whenever the time interval calculated from these fields
overlaps the canvas time range
Some known limitations/inefficiencies:
- currently only date/datetime fields can be used. This was done
to simplify the format handling and avoid the need to worry about
string fields with different datetime formats. In future we should
allow selection of string fields and allow users to enter a custom
datetime format string
- unlike the Time Manager plugin approach, the approach taken here
is to rely completely on QGIS expressions and feature requests to
do the filtering (Time Manager uses layer filter strings and attempts
to set a native SQL filter syntax so that filtering is done on the
backend). This is intentional, because it provides a unified filter
approach regardless of the provider used (i.e. we don't need to worry
about the different SQL syntaxes used natively by the different
providers). The beauty of feature request expression compilation
**should** mean that the QGIS expressions are magically turned into
native backend queries, BUUUUUUUUUUUT... because we lack QGIS expression
support for date time literals, we currently rely on the "to_datetime"
expression function and coerce everything through strings. None of
the expression compilers handle this function, so currently ALL
filtering is done on the QGIS side. We need to add functions for
optimised datetime literal creation, and then ensure that the different
compilers correctly map these literals across to the backend
filter syntax to allow all the filtering work to be done on the database
side...
So currently, performance is much worse with large layers compared
to Time Manager. But, the advantage is that we can use the native
temporal framework and have vector layers animated alongside mesh
and raster layers!
as distinct symbols vs the scalebar line symbol
Allows for styling division and subdivision symbols in a different
way compared with the horizontal line symbol in a tick scalebar
Sponsored by SLYR
This allows users to manually override the legend's default setting for "split layers"
on a layer-by-layer basis, by double clicking a layer in the layout legend panel
and choosing whether that layer:
- follows the default legend setting for splitting
- can ALWAYS be split over multiple columns (regardless of the legend's setting)
or
- can NEVER be split over multiple columns (regardless of the legend's setting)
Sponsored by SLYR
Adds the option when configuring a legend item to place a column
break before the item, causing it to be placed into a new column
This allows user control over the column content, for cases when
the automatic column generation doesn't result in the desired results
[API] [FEATURE] Add a method in API to snap on mesh elements (vertex, edge, face)
The method returns the position of the snapped point on the closest mesh element :
This allows users to (optionally!) customise the symbol appearance
for a legend node, e.g. to tweak the colors or symbol sizes to better
provide a "representative" patch symbol compared with how those
corresponding features actually appear on the map.
It's useful for exaggerating symbol widths, or for manually tweaking
the colors of semi-transparent symbols so that the colors represent
the actual appearance of the symbols when rendered on top of the map
content. Or to tweak the marker interval/offset in marker lines so that the
markers are nicely spaced in the legend patch.
Fixes#14077
polygons
Options are:
- 'yes': allow placing outside the polygon if needed
- 'no': don't allow outside placements
- 'force': only ever put this label outside the polygon
outside of polygon features when required
When a label can't be placed inside the polygon and this option is checked,
then it will be automatically placed at a nicely selected location
just outside of the polygon
Sponsored by QGIS Swiss user group!
