has been linked to a project color
Instead of only showing linked color status in the accompanying
data defined button, we now also show it inside the color button
itself. So now the button color is a live reflection of the
project color it is linked to.
Additionally, when the color is linked, the button only allows
users the choice of "unlinking" the color from the linked
project color. The usual color button options allowing users
to directly change the color are not present. (As linked
colors must be edited in the project colors section from
the project properties dialog)
This allows optional creation of geodesic lines, which represent the
shortest distance between the points based on the ellipsoid.
When geodesic mode is used, it is possible to split the created lines
at the antimeridian (±180 degrees longitude), which can improve
rendering of the lines. Additionally, the distance between vertices
can be specified. A smaller distance results in a denser, more accurate
line.
Similarly to raster calculator, mesh calculator can take dataset groups from current mesh layer and
combine them with various aritmentic/logical operators to new dataset group.
Ports the similar algorithm from the shape tools plugin to c++, and utilises
built in QgsDistanceArea ellipsoidal calculations to split the lines.
This algorithm splits a line into multiple geodesic segments, whenever the
line crosses the antimeridian (±180 degrees longitude)
Splitting at the antimeridian helps the visual display of the lines in some
projections. The returned geometry will always be a multi-part geometry.
Whenever line segments in the input geometry cross the antimeridian,
they will be split into two segments, with the latitude of the breakpoint
being determined using a geodesic line connecting the points either side
of this segment. The current project ellipsoid setting will be used when
calculating this breakpoint.
If the input geometry contains M or Z values, these will be linearly
interpolated for the new vertices created at the antimeridian.
Supports in-place edit mode also.
at the antimeridian
Whenever line segments in the input geometry cross the antimeridian, they
will be split into two segments, with the latitude of the breakpoint being
determined using a geodesic line connecting the points either side of this
segment.
If the geometry contains M or Z values, these will be linearly interpolated
for the new vertices created at the antimeridian.
This adds a new "Project Colors" section in data defined buttons
which are linked to a color value. The color menu contains all
colors defined as part of the current project's Project Color
Scheme (which is defined through project properties).
When a project color is selected from the button, the property
becomes linked to that color. It will automatically follow any
future changes to the color when made through project properties.
This allows users to define common colors for a project once,
and then "bind" symbol, label, layout, etc colors to these
preset colors. The link is live, so you change it once, and
the change is reflected EVERYWHERE. Sure beats updating a color
100 times when it's use has been scattered throughout a project's
symbols, labels, etc...
(Basically, this is just adding a shortcut to setting a data
defined expression "project_color(...)" for the property. The
project_color function has been around a LOOONG time, but it's
only really been usable by power users before this change)
and asMultiPolygon()
- raise ValueError when these methods are called with null geometries
- raise TypeError when these methods are called with incompatible
geometry types, instead of silently returning empty lists
This allows nice and simple, elegant construction of checks for
Python.
To use, Python based checks should use the decorator syntax:
from qgis.core import check
@check.register(type=QgsAbstractValidityCheck.TypeLayoutCheck)
def my_layout_check(context, feedback):
results = ...
return results
Or, a more complete example. This one throws a warning when attempting
to export a layout with a map item set to the Web Mercator projection:
@check.register(type=QgsAbstractValidityCheck.TypeLayoutCheck)
def layout_map_crs_choice_check(context, feedback):
layout = context.layout
results = []
for i in layout.items():
if isinstance(i, QgsLayoutItemMap) and i.crs().authid() == 'EPSG:3857':
res = QgsValidityCheckResult()
res.type = QgsValidityCheckResult.Warning
res.title='Map projection is misleading'
res.detailedDescription='The projection for the map item {} is set to <i>Web Mercator (EPSG:3857)</i> which misrepresents areas and shapes. Consider using an appropriate local projection instead.'.format(i.displayName())
results.append(res)
return results
The URL exposed in the XML documents generated
by the server was wrong because instead of
using the original URL (from REQUEST_URI)
the rewritten query string (from QUERY_STRING)
was applied to the internal mUrl variable.
This patch also adds some tests for the
FCGI request, that handle most common
scenarios with bot rewritten and not
rewritten URLs.
QgsFcgiServerRequest is now exposed to
Python mainly for testability purposes.
Better to use QVector here, because the QgsLineString/QgsGeometry
methods all use QVector too, and we want to avoid unnecessary
list->vector conversions.
