Rudimentary support of rendering of vector data (e.g. velocity) on mesh map layers.
Rendering can be adjusted by QgsMeshRenderer*Settings. Only in Python
API, no GUI widgets for styling present.
- nodes() return the list of all nodes
- findNodes<T> returns a list of the nodes matching the class
Also drops the regexp for finding form attrs in the value-relation
expressions.
Other minor fixes as suggested in the PR review.
The value relation widget filter expression can now use two
new functions/variables that have access to the current
values and geometry of the form being edited.
This allows for dynamic filtering (drill-down) as explained
in the crowdfunding page:
https://north-road.com/drill-down-cascading-forms/
The new functions/variables are:
Function:
get_current_form_field_value( 'FIELD_NAME' )
Variable:
@current_form_geometry
there is a small redundancy in code, but it makes it much nicer to read the calls:
flagValue( key, default) instead of enumValue( key, default, NoSection, false )
Bad geo-referencing bug fix
Using VRT with large coordinate system (like RGF93/CCxx) and high
resolution raster, highest resolution tiles were shifted regardingi
original raster.
It seemed that when creating the VRT file, georeferencing is
truncated while converted to text, leading to loss of precision.
Allows the full range of formatting options exposed through
text renderer - e.g. scalebar text with buffers, shadows,
background shapes, letter spacing, etc.
Say goodbye to unreadable scale bar text!
Because users are still getting confused with the difference
between the cartesian areas and ellipsoidal areas, show both
in the identify results dock.
The reasoning here is:
- if a user understands this concept, they will know the correct
one to use, and its good for us to inform them of the difference
here. Plus, it means they immediately see if the ellipsoid
setting is correct and the difference it is making for the
area/length calculation.
- if a user has no idea what the difference is, then we should
make them aware that there's (at least!) two different possible
measurement values. They can then either research what these mean and make
the right choice (and become better informed GIS practitioners),
OR pick a random one - which really is no different then the
previous situation, because an uniformed user is just as likely
to be working in an unsuitable projection with a poor ellipsoid
choice.
In short, we don't try to guess the right choice for users
and instead give them all the information and let them make the
call which value to use.
Often the polygonZ/multipatch data do not have consistent ordering of vertices
(e.g. all clock-wise or counter clock-wise). Disabling culling helps to avoid
seemingly missing surfaces, but the shading is still not correct due to reversed
normals. This new option to add back faces fixes the problem: for each triangle
we create both front and back face with correct normals - at the expense of increased
number of vertex data.
