mirror of
https://github.com/qgis/QGIS.git
synced 2025-02-23 00:02:38 -05:00
73 lines
4.2 KiB
Plaintext
73 lines
4.2 KiB
Plaintext
|
- Derive your algorithms from the new base class QgsProcessingAlgorithm (or a subclass of QgsProcessingAlgorithm), not GeoAlgorithm
|
|||
|
|
|
|||
|
|
- Ensure that your algorithm (or algorithm's parent class) implements the new pure virtual createInstance(self, config) call to return a new instance of the algorithm class. Note that this should not return a copy of the algorithm, but instead a newly constructed instance of the class. If you use a base class in your plugin for all algorithms, you can usually shortcut the createInstance implementation by placing:
|
|||
|
|
|
|||
|
|
def createInstance(self, config={}):
|
|||
|
|
return type(self)()
|
|||
|
|
|
|||
|
|
inside your algorithm base class.
|
|||
|
|
|
|||
|
|
- Input parameters and available outputs must be declared in an implementation of the new pure virtual method initAlgorithm(self, config={})
|
|||
|
|
|
|||
|
|
- The input parameters and outputs classes have been replaced with new c++ versions, which must be used when calling addParameter and addOuput.
|
|||
|
|
Map parameters from old classes to new classes
|
|||
|
|
- ParameterNumber -> QgsProcessingParameterNumber
|
|||
|
|
- constructor arguments in different order
|
|||
|
|
- type specified explicitly, not via min/max/default type
|
|||
|
|
- ParameterBoolean -> QgsProcessingParameterBoolean
|
|||
|
|
- ParameterCrs -> QgsProcessingParameterCrs
|
|||
|
|
|
|||
|
|
- Use featuresources and sinks wherever possible
|
|||
|
|
|
|||
|
|
Update outputs
|
|||
|
|
|
|||
|
|
- OutputVector ->
|
|||
|
|
|
|||
|
|
- processAlgorithm has a new signature....
|
|||
|
|
|
|||
|
|
Update retrieval of parameters
|
|||
|
|
|
|||
|
|
- Extent parameters now returned as QgsRectangle. In 2.x extent parameters were returned as a delimited string, leaving the algorithm
|
|||
|
|
responsible for parsing the string and validating it. In 3.0 this is automatically handled and a QgsRectangle returned, ready for use.
|
|||
|
|
|
|||
|
|
- Crs parameters now returned as QgsCoordinateReferenceSystem objects. In 2.x crs parameters were returned as a string, leaving the algorithm
|
|||
|
|
responsible for interpreting this string and working out how to convert it to a suitable CRS object. In 3.0 this is automatically handled
|
|||
|
|
and a QgsCoordinateReferenceSystem object is returned, ready for use. If you require a string version of the CRS, use the
|
|||
|
|
QgsCoordinateReferenceSystem methods like authid() to obtain a string representation of the CRS in the desired format.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Use parameterAsSink instead of getOutputFromName
|
|||
|
|
|
|||
|
|
- Since processing algorithms can now be run in the background, it's important to implement support for cancelation in your
|
|||
|
|
algorithms. Whenever looping (or before/after calling lengthy operations) listen out for user cancelation via the provided
|
|||
|
|
feedback object. E.g.
|
|||
|
|
|
|||
|
|
if feedback.isCanceled():
|
|||
|
|
break
|
|||
|
|
|
|||
|
|
- Give feedback via the feedback object, not directly to QgsMessageLog. E.g.
|
|||
|
|
|
|||
|
|
feedback.pushInfo('Feature {} was missing geometry, skipping'.format(f.id())
|
|||
|
|
feedback.reportError('Input layer CRS is not valid, cannot reproject')
|
|||
|
|
|
|||
|
|
- Use geoprocessingexception only for FATAL errors which force a model to terminate. Algorithms should handle common cases
|
|||
|
|
such as having no features in an input layer without throwing exceptions (instead, an empty layer should be output). This
|
|||
|
|
allows more flexibility for users creating models. They may have created models which "route" features to different algorithms
|
|||
|
|
based on some criteria, and it can be a valid case that no features satisfy this criteria. If your algorithm throws an
|
|||
|
|
exception upon encountering an empty layer, it prevents it being used in these flexible models. Instead, use the feedback
|
|||
|
|
object to pushInfo or reportError so that the lack of features is brought to user's attention (and logged) without breaking
|
|||
|
|
the model execution.
|
|||
|
|
|
|||
|
|
- Outputs are good! Declare as many outputs as useful from your algorithm. E.g. most algorithms should have at least a
|
|||
|
|
FEATURE_COUNT number output which records the number of features processed by the algorithm. Other algorithms might want
|
|||
|
|
to create numeric outputs for values like INTERSECTING_FEATURE_COUNT, NON_INTERSECTING_FEATURE_COUNT, etc. The more
|
|||
|
|
outputs like this available from an algorithm aids in user debugging (they are recorded in the log, so users can get
|
|||
|
|
a clear picture of what's happening at each step in their models), and also adds more power to models (as these outputs
|
|||
|
|
can be used in expressions or custom python code in later steps in a model.
|
|||
|
|
|
|||
|
|
Return a dict with output values
|
|||
|
|
|
|||
|
|
Dont’ use tablewriter - use a sink instead
|
|||
|
|
|
|||
|
|
|