Flags can be used to control how features are added to the sink.
For now, there's only a single flag available - FastInsert.
When FastInsert is set, faster inserts will be use at the cost
of updating the passed features to reflect changes made at the
provider.
This includes skipping the update of the passed feature IDs
to match the resulting feature IDs for the feature within
the data provider.
Individual sink subclasses may or may not choose to respect
this flag, depending on whether or not skipping this update
represents a significant speed boost for the operation.
QgsVectorLayer always ignores the flag - feature ids are
required for the featureAdded signal to be correctly emitted,
and it's expected that performance critical applications will
add features directly to a data provider instead of
via QgsVectorLayer's edit buffer.
In python, the wkb type of a QgsPoint will by default be determined from
the provided parameters, where Z and M will be added as required if the
wkbType is Undefined.
QgsPoint(x, y, z=nan, m=nan, wkbType=QgsWkbTypes.Undefined)
Thanks to the python API support of named parameters, it's also
straightforward to specify z, m and wkbType in any desired combination.
On the other hand, on C++ side it's often preferable to use
QgsPoint(QgsWkbTypes::WkbType wkbType, double x, double y, double z, double m);
due to the lack of named parameters which make it harder to specify a
specific type and the advantage of typesafety that makes it possible to
verload the first constructor with this one.
require all input layers to be in the same CRS
The default behaviour is to assume that algorithms are well behaved
and can handle multi-CRS inputs, but algs have the option to
flag that they do not allow this and require the input CRS check.
Those algs should document that they require all inputs to have
matching CRS - processing 3.0 behaviour is to assume that algs
can handle this.
Geometries are passed as const reference and returned by value.
This make using the API easier and reduces the risk of ownership
problems.
The overhead is minimal due to implicit sharing.
Fix https://github.com/qgis/qgis3.0_api/issues/68
If set, all geometries will be reprojected from their original
coordinate reference system to the destination CRS while
iterating over features.
If a CRS has been set as the destination CRS, then the filterRect
parameter should be specified in the same CRS as this destination
CRS.
Additionally, a callback function can be specified on the request
to be called if a transform exception is encountered while
iterating over features.
This is designed to make it easier for scripts and plugins to
correctly reproject layers in an efficient and robust way, instead
of having to implement lots of repeated code themselves and
potentially missing some of the important considerations which
come with reprojecting geometries & bounding boxes.
Now, if a script wants the features from a layer in a specific
CRS, they can call:
crs = QgsCoordinateReferenceSystem('epsg:4326')
request = QgsFeatureRequest().setDestinationCrs(crs)
for f in layer.getFeatures(reqeuest):
print('geometry in 4326 is {}.format(f.geometry().exportToWkt()))
