QGIS/doc/porting_processing.dox

- 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.

    - ParameterField has been replaced with QgsProcessingParameterField.
      - When constructing, QgsProcessingParameterField uses QgsProcessingParameterField.DataType to specify valid data types. The parent layer for the field should be indicated by passing the parent layer parameter name as the parentLayerParameterName argument in the constructor.
      - Retrieving field parameter values should be done with self.parameterAsString( parameters, PARAM_NAME, context) for single field values or self.parameterAsFields(parameters, PARAM_NAME, context) if allowMultiple was set to True when the parameter was constructed. parameterAsFields will return a list of all selected field names, or an empty list if no fields were selected.
    
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