work correctly with curved geometry types, and tweak some API naming
accordingly
There's no need to be restrictive and only require linear geometries
for these items!
[FEATURE] Introduces mesh virtual datasets
With the mesh calculator the user can choose to create those "virtual" dataset groups that will be added to the layer. Then, for these dataset groups, values are not stored in memory but each dataset is calculated when needed whit the formula entered in the mesh calculator.
Those virtual dataset groups are saved with the project.
If needed, the user can remove them or can persist them on files to make them persistent.
Co-authored-by: Étienne Trimaille <gustrimaille@yahoo.fr>
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!
Introduce a renderer for 1D mesh edges that can vary width over the line. The line can also have different color based on the actual dataset value on the line's point.
Co-authored-by: Peter Petrik <zilolv@gmail.com>
Initial work... Currently supporting output to a directory based on XYZ template, using Mapbox vector tiles encoding.
New classes:
- QgsVectorTileMVTEncoder - low-level class that operates on a single tile, converts vector features to raw tile byte array, for internal use
- QgsVectorTileWriter - higher level class that manages generation of multiple tiles, for use by clients
- QgsVectorTileMVTUtils - assorted helper functions for MVT encoding/decoding
This sink allows for transformation of incoming features to match the
requirements of storing in an existing destination layer, e.g. by reprojecting
the features to the destination's CRS, by coercing geometries to the
format required by the destination sink, and by mapping field values from
the source to the destination.
This new renderer draws contour lines that are calculated on the fly
from the source raster band. It is possible to set interval of contour
lines and symbol used for drawing.
In addition there is support for "index contours" - contour lines
with higher interval, typically drawn with a wider line symbol.
If we generate contour lines on input raster block with the same size as our
output raster block, the generated lines would contain too much detail.
This detail can be reduced by the "downscale" factor - this will request
lower resolution of the source raster.
This style represents decimal numbers as vulgar fractions, e.g.
"3/4" instead of 0.75.
Options include using Unicode superscript and subscript characters
for nicer typography, e.g. ¹⁷/₂₃ (this is the default mode, disabling
this option uses the "17/23" format). An option also exists for
using dedicated unicode characters for specific fractions (where
a unicode character exists), e.g. ½ or ¾
Ultimately this allows for creation of scalebars with fractional
representations of distances, e.g. 0 ----- ½ ----- 1 km
(instead of 0 ------ 0.5 ------ 1km)
Fixes#21289
Sponsored by SLYR
Designed to match the appearance and behavior of the ArcMap equivalent,
this was a scalebar format which was previously impossible to replicate
in QGIS.
Also fixes#26589
Sponsored by SLYR
