This allows encapsulation of properties relating to the context
of a search, such as a target map extent. Locator filters could
use this to prioritise results close to the current canvas extent.
The project layer filter allows you to quickly select a layer
from the current project and highlight it in the layer tree.
It's useful for complex project with lots of groups, where
it's easy to "lose" layers somewhere in the tree...
The composition filter allows searching for and opening
compositions from the current project
This adds a new "locator" bar to the QGIS status bar. If you're not
familiar with QtCreator's locator, it's a quick search bar
(activated by Ctrl+K) which displays matching search results
from any number of registered search filters.
Search filters are subclassed from QgsLocatorFilter, and
added to the app's locator via iface.registerLocatorFilter(...)
Searching is handled using threads, so that results always
become available as quickly as possible, regardless of whether
any slow search filters may be installed. They also appear
as soon as each result is encountered by each filter, which means
that e.g. a file search filter will show results one by one
as the file tree is scanned. This ensures that the UI is always
responsive even if a very slow search filter is present (e.g.
one which uses an online service).
This framework is designed to be extended by plugins, such as
OSM nominatim searches, direct database searching (i.e. Discovery
plugin), layer catalog searches, etc...
This is a completely wrong use of an algorithm that is meant to be used with *integer* values,
e.g. when dealing with pixels on screen, but not for coordinates that are floating point numbers.
The algorithm has a fixed tolerance of 1 unit.
QgsPoint(5,0.9).onSegment(QgsPoint(0,0), QgsPoint(10,0)) would return 2 (i.e. point is on line segment)
See the original code: https://github.com/erich666/GraphicsGems/blob/master/gems/PntOnLine.c
This reverts commit e3d79a1fe940b5d813b5f79c51b43393d085bb16, reversing
changes made to 3f7f95ee262ea3646d61600c21faed0866bc70b0.
Reverting again, as Travis started failing after merging PR (with all
test passed) into master branch
This completes the API to eventually get rid of all
getEnv usage from python server plugins.
The request handler has now access to the request URL
and POST data without the need to query the env.
Historically the configuration used to be stored in layer's custom properties, but that does not scale
beyond simple rendering and so rule-based labeling introduced storage of configuration natively in XML elements.
That left us with two different ways of reading/writing labeling configurations. This work makes all configuration
to use native XML elements.
To keep compatibility of 2.x projects, reading of configuration from custom properties is preserved.
This commit also adds Python APIs for direct manipulation of labeling configuration through vector layer's
setLabeling() and labeling() calls.
Avoids unpredictable behavior when transforms are being
conducted in background threads, such as map renders.
Refs #11441
This commit:
1. Uses thread_local storage for projCtx objects, to ensure
that every thread correctly has its own projCtx context.
2. Refactors QgsCoordinateTransformPrivate so that the
projPJ source and destination objects are instead stored
in a map (by projCtx). This allows transforms to be
transparently performed using the correct projPJ objects
for the particular thread in which the transform is being
conducted. This approach avoids expensive detachment
of QgsCoordinateTransformPrivate, and allows a single
QgsCoordinateTransformPrivate to be safely utilised
by QgsCoordinateTransform objects in different threads.
