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.
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
Better to use QVector here, because the QgsLineString/QgsGeometry
methods all use QVector too, and we want to avoid unnecessary
list->vector conversions.
Adds a new interface QgsAbstractValidityCheck which defines
a single "check" which can be performed on a given QgsValidityCheckContext.
A new application-wide QgsValidityCheckRegistry registers
and manages instances of all known checks, and allows running
of all registered checks of a specific type at once.
Initially the framework is focused toward print layout validity
checks, but the interface has been designed to be generic enough
to allow alternative types of validity checks (e.g. project save
validity checks, processing model validity checks, etc.).
The API is designed to be used both by internal validity checks
and also to be extended by custom, organisation-specific
validity checks. E.g., for print layout validity checks we could have:
This new class, QgsBlockingNetworkRequest, is designed for
performing SAFE blocking requests. It is thread safe and
has full support for QGIS proxy and authentication settings.
This class should be used whenever a blocking network
request is required. Unlike implementations
which rely on QApplication::processEvents() or creation of a
QEventLoop, this class is completely
thread safe and can be used on either the main thread or
background threads without issue.
Redirects are automatically handled by the class.
After completion of a request, the reply content should be
retrieved by calling getReplyContent().
This method returns a QgsNetworkReplyContent container,
which is safe and cheap to copy and pass
between threads without issue.
The guts of this class have been copied from QgsWfsRequest (which
has been using the same approach since 3.2)
Encapsulates a network reply within a container which
is inexpensive to copy and safe to pass around between threads.
The default Qt QNetworkReply class is a QObject, which prevents
it from being copied and passed between threads. This class
grabs all the useful information from a QNetworkReply,
allowing the reply's content to be stored indefinetly without
concern for the lifetime of the QNetworkReply object itself.
This feature allows other layout items (such as scalebars,
north arrows, inset maps, etc) to be marked as a blockers for
the map labels in a map item. This prevents any map labels from
being placed under those items - causing the labeling engine
to either try alternative placement for these labels (or
discarding them altogether)
This allows for more cartographically pleasing maps -- placing
labels under other items can make them hard to read, yet without
this new setting it's non-trivial to get QGIS to avoid placing
the labels in these obscured areas.
The blocking items are set through a map item's properties, under
the label settings panel. The setting is per-map item, so you can have
a scalebar block the labels for one map in your layout and not others
(if you so desire!)
