By moving logic to abstract geometry subclasses so that they
can trivially retrieve the vertex number, instead of relying
on the inefficient coordinateSequence method.
Has flow on speed boosts to many geometry operations like
calculation of closest points in a geometry, which will
benefit snapping related operations.
Previously the method in QgsGeometryUtils was relying on
QgsAbstractGeometry::coordinateSequence, which is an absolute
performance killer.
Instead move to optimised methods in the various abstract
geometry subclasses which rely only on trivial calculations.
Previously the writer was only using transactions in some
cases (when calling the static writeAsVectorFormat method).
This changes the writer to always use a transaction when
possible.
Fixes the map renderer job test using gpkg from timing out after
taking forever to running twice the speed of the shapefile
version. Similar benefits across other parts of qgis,
which are writing files without using the static method, e.g.
processing.
and add new QgsGeometry::fromPolyline which uses QgsPoint
We want to encourage people not to use the QgsPointXY method, as it drops
Z/M values. So it's moved across to a different name to make way
for a new QgsGeometry::fromPolyline which uses a QgsPoint list
instead of QgsPointXY, thus keeping Z/M values intact.
Similarly, QgsPolyline now is a list of QgsPoint (keeping z/m values)
and the old 2d QgsPolyline type was renamed to QgsPolylineXY.
Making the QgsPoint method the "preferred" method and making linestrings
just as easy to create from z/m dimensioned points as 2d points is
important to push people to write code which does not discard
these important dimensions.
As a bonus, the QgsPoint methods are more efficient anyway, since
they don't require creation of a temporary list.
Currently each time you instanciate a QgsOgrProvider layer, a GDAL dataset is
created. In the case of GeoPackage, this means a SQLite connection and a file
handle. As GDAL enables Spatialite function on GeoPackage connections, we are
bound to Spatialite limits, and Spatialite has a hard limit on a maximum of
64 simultaneous connections. Thus we cannot open more than 64 layers of the
same GeoPackage.
This commits enables sharing of the same GDALDataset object among several
QgsOgrProvider object. Care is made to reuse a GDALDataset object only if the
QgsOgrProvider do not point to the same layer. Mutexes are also taken to
allow safe instanciation and use of QgsOgrProvider objects from multiple
threads (but a same QgsOgrProvider should not be used by more than one thread
at a time)
With this commit, it's posssible to handle a request from a QgsProject without writing it to the disk.
```python
server = QgsServer()
project = QgsProject()
vlayer = QgsVectorLayer("/path/to/shapefile/file.shp", "layer_name_you_like", "ogr")
project.addMapLayer(vlayer)
query_string = 'https://www.qgis.org/?SERVICE=WMS&VERSION=1.3&REQUEST=GetCapabilities'
request = QgsBufferServerRequest(query_string, QgsServerRequest.GetMethod, {}, data)
response = QgsBufferServerResponse()
server.handleRequest(request, response, project)
```
See description of QgsAuthCertUtils::pkcs8PrivateKey.
This fix may be needed on other platforms (untested at this point),
because Qt5 QSslkey class *still* does not directly support creation
using non-PKCS1 PEM- or DER-encoded data, though QCA, whose qca-ossl
plugin is linked to OpenSSL, does support PKCS1 and PKCS8.
Introducing:
1. STL-style iterator: QgsAbstractGeometry::vertex_iterator
2. Java-style iterator: QgsVertexIterator (built on top of STL-style)
The iterators are modeled after Qt's STL-style and Java-style iterators,
the idea is to replace nextVertex() method and later introduce iterators
for other bits (e.g. part_iterator, ring_iterator).
So it's more inline with the std::as_const implementation which
it fills in for, and allows us to 'polyfill' other c++>11
features into the qgis:: namespace.
