sharpetronics/QGIS
1
0
Fork 0
mirror of https://github.com/qgis/QGIS.git synced 2025-03-03 00:02:25 -05:00
Code Issues Packages Projects Releases Wiki Activity
QGIS/python/core/processing/qgsprocessingoutputs.sip.in

379 lines
9.1 KiB
Plaintext
Raw Normal View History

Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
/************************************************************************
* This file has been generated automatically from *
* *
* src/core/processing/qgsprocessingoutputs.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/
class QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Base class for the definition of processing outputs.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
run sipify
2017-12-15 10:36:55 -04:00
Output definitions encapsulate the properties regarding the outputs from algorithms, such
as generated layers or calculated values.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
Partially port wrappers to QgsProcessingParameterDefinition And create a new WidgetWrapperFactory for creating a suitable wrapper corresponding to a parameter
2017-05-15 16:02:45 +10:00
%End
%ConvertToSubClassCode
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
if ( sipCpp->type() == QgsProcessingOutputVectorLayer::typeName() )
Partially port wrappers to QgsProcessingParameterDefinition And create a new WidgetWrapperFactory for creating a suitable wrapper corresponding to a parameter
2017-05-15 16:02:45 +10:00
sipType = sipType_QgsProcessingOutputVectorLayer;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
else if ( sipCpp->type() == QgsProcessingOutputRasterLayer::typeName() )
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
sipType = sipType_QgsProcessingOutputRasterLayer;
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
else if ( sipCpp->type() == QgsProcessingOutputMapLayer::typeName() )
sipType = sipType_QgsProcessingOutputMapLayer;
[processing] Add explicit output type for multiple layers This was a missing capability in the processing API - while algorithms could declare multiple layer input parameters, there was no corresponding multi-layer output. This meant that algorithms (such as Package Layers, Vector Split) which create a set of layers which cannot be determined in advance had no way to pass these generated layers on for further model processing steps. It's also useful for algorithms which operate on a specified folder, processing all layers found there, and allowing these generated outputs to be utilised in other model steps (e.g. packaging all of them, merging them, etc)
2018-02-11 10:57:44 +10:00
else if ( sipCpp->type() == QgsProcessingOutputMultipleLayers::typeName() )
sipType = sipType_QgsProcessingOutputMultipleLayers;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
else if ( sipCpp->type() == QgsProcessingOutputHtml::typeName() )
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
sipType = sipType_QgsProcessingOutputHtml;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
else if ( sipCpp->type() == QgsProcessingOutputNumber::typeName() )
Restore basic stats alg
2017-06-07 07:12:25 +10:00
sipType = sipType_QgsProcessingOutputNumber;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
else if ( sipCpp->type() == QgsProcessingOutputString::typeName() )
Add string output type
2017-06-13 12:32:17 +10:00
sipType = sipType_QgsProcessingOutputString;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
else if ( sipCpp->type() == QgsProcessingOutputFolder::typeName() )
Add folder output type
2017-06-22 18:21:33 +10:00
sipType = sipType_QgsProcessingOutputFolder;
[processing][API]introduce QgsProcessingOutputFile output and fix gdal2xyz test
2017-09-27 11:29:00 +03:00
else if ( sipCpp->type() == QgsProcessingOutputFile::typeName() )
sipType = sipType_QgsProcessingOutputFile;
[processing] Port refactor fields to new API
2017-07-21 19:46:27 +02:00
else
sipType = nullptr;
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
public:
QgsProcessingOutputDefinition( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputDefinition.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
virtual ~QgsProcessingOutputDefinition();
virtual QString type() const = 0;
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Unique output type name.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
QString name() const;
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the name of the output. This is the internal identifier by which
algorithms access this output.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`setName`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
void setName( const QString &name );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Sets the ``name`` of the output. This is the internal identifier by which
algorithms access this output.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`name`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
QString description() const;
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the description for the output. This is the user-visible string
used to identify this output.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`setDescription`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
void setDescription( const QString &description );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Sets the ``description`` for the output. This is the user-visible string
used to identify this output.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`description`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
protected:
};
typedef QList< const QgsProcessingOutputDefinition * > QgsProcessingOutputDefinitions;
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
class QgsProcessingOutputMapLayer : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A map layer output for processing algorithms, where layers may be either vector or raster.
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
run sipify
2017-12-15 10:36:55 -04:00
If the actual layer output type is known (e.g. always vector or always raster), use
QgsProcessingOutputVectorLayer or QgsProcessingOutputRasterLayer instead.
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputMapLayer( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputMapLayer.
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
%End
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
[processing] Add a generic map layer output type For occasions when an algorithm creates a map layer, but the type is not known in advance (i.e. could be raster OR vector)
2017-11-26 15:39:36 +10:00
%End
virtual QString type() const;
};
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
class QgsProcessingOutputVectorLayer : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A vector layer output for processing algorithms.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
Rename some enum values for clarity
2017-08-19 02:46:22 +10:00
QgsProcessingOutputVectorLayer( const QString &name, const QString &description = QString(), QgsProcessing::SourceType type = QgsProcessing::TypeVectorAnyGeometry );
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputVectorLayer.
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
virtual QString type() const;
Rename some enum values for clarity
2017-08-19 02:46:22 +10:00
QgsProcessing::SourceType dataType() const;
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the layer type for the output layer.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`setDataType`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
Rename some enum values for clarity
2017-08-19 02:46:22 +10:00
void setDataType( QgsProcessing::SourceType type );
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Sets the layer ``type`` for the output layer.
[sipify] fix bad handling of \see within sentences and other docstrings improvements
2018-01-09 17:26:37 -04:00
.. seealso:: :py:func:`dataType`
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
%End
};
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
class QgsProcessingOutputRasterLayer : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A raster layer output for processing algorithms.
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputRasterLayer( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputRasterLayer.
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
[processing] Add explicit output type for multiple layers This was a missing capability in the processing API - while algorithms could declare multiple layer input parameters, there was no corresponding multi-layer output. This meant that algorithms (such as Package Layers, Vector Split) which create a set of layers which cannot be determined in advance had no way to pass these generated layers on for further model processing steps. It's also useful for algorithms which operate on a specified folder, processing all layers found there, and allowing these generated outputs to be utilised in other model steps (e.g. packaging all of them, merging them, etc)
2018-02-11 10:57:44 +10:00
%End
virtual QString type() const;
};
class QgsProcessingOutputMultipleLayers : QgsProcessingOutputDefinition
{
%Docstring
A multi-layer output for processing algorithms which create map layers, when
the number and nature of the output layers is not predefined.
.. note::
Always prefer to explicitly define QgsProcessingOutputVectorLayer,
QgsProcessingOutputRasterLayer or QgsProcessingOutputMapLayer where possible. :py:class:`QgsProcessingOutputMultipleLayers`
should only ever be used when the number of output layers is not
fixed - e.g. as a result of processing all layers in a specified
folder.
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputMultipleLayers( const QString &name, const QString &description = QString() );
%Docstring
Constructor for QgsProcessingOutputMultipleLayers.
%End
static QString typeName();
%Docstring
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
virtual QString type() const;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
Add raster layer output parameters
2017-06-06 14:38:24 +10:00
};
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
class QgsProcessingOutputHtml : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A HTML file output for processing algorithms.
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputHtml( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputHtml.
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
virtual QString type() const;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
Add file based and HTML outputs to c++ API
2017-06-06 15:23:10 +10:00
};
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
Restore basic stats alg
2017-06-07 07:12:25 +10:00
class QgsProcessingOutputNumber : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A numeric output for processing algorithms.
Restore basic stats alg
2017-06-07 07:12:25 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputNumber( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputNumber.
Restore basic stats alg
2017-06-07 07:12:25 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Restore basic stats alg
2017-06-07 07:12:25 +10:00
virtual QString type() const;
};
Add string output type
2017-06-13 12:32:17 +10:00
class QgsProcessingOutputString : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A string output for processing algorithms.
Add string output type
2017-06-13 12:32:17 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputString( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputString.
Add string output type
2017-06-13 12:32:17 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Add string output type
2017-06-13 12:32:17 +10:00
virtual QString type() const;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
Add string output type
2017-06-13 12:32:17 +10:00
};
Add folder output type
2017-06-22 18:21:33 +10:00
class QgsProcessingOutputFolder : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A folder output for processing algorithms.
Add folder output type
2017-06-22 18:21:33 +10:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
Add folder output type
2017-06-22 18:21:33 +10:00
QgsProcessingOutputFolder( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputFolder.
Add folder output type
2017-06-22 18:21:33 +10:00
%End
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
%End
Add folder output type
2017-06-22 18:21:33 +10:00
virtual QString type() const;
Use c++ method for available sources
2017-07-03 19:42:29 +10:00
Add folder output type
2017-06-22 18:21:33 +10:00
};
Add string output type
2017-06-13 12:32:17 +10:00
[processing][API]introduce QgsProcessingOutputFile output and fix gdal2xyz test
2017-09-27 11:29:00 +03:00
class QgsProcessingOutputFile : QgsProcessingOutputDefinition
{
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
A file output for processing algorithms.
[processing][API]introduce QgsProcessingOutputFile output and fix gdal2xyz test
2017-09-27 11:29:00 +03:00
.. versionadded:: 3.0
%End
%TypeHeaderCode
#include "qgsprocessingoutputs.h"
%End
public:
QgsProcessingOutputFile( const QString &name, const QString &description = QString() );
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Constructor for QgsProcessingOutputFile.
[processing][API]introduce QgsProcessingOutputFile output and fix gdal2xyz test
2017-09-27 11:29:00 +03:00
%End
static QString typeName();
%Docstring
run sipify
2017-12-15 10:36:55 -04:00
Returns the type name for the output class.
[processing][API]introduce QgsProcessingOutputFile output and fix gdal2xyz test
2017-09-27 11:29:00 +03:00
%End
virtual QString type() const;
};
Add framework for algorithm outputs This somewhat changes the meaning of outputs from processing 2.x. In 2.x processing outputs were used both as a method of specifying inputs to algorithms (file paths to destination layers created by the algorithm) AND pure outputs (such as statistics calculated by the algorithm). This is now split. The old input-type-outputs (destination layers) are now input parameters (since the parameter value IS an input to the algorithm). To differentiate them from parameters indicating pure input layers a new "isDestination()" method was added to QgsProcessingParameterDefinition. Output definitions are now purely indications of values CREATED by the algorithms. Suitable candidates are the existing calculated stats and actual file path/URI of any layers created by the algorithm. Moving forward we should ensure all algorithms output as much useful information as possible - e.g. number of features processed, number of skipped features, count null geometries encountered, etc...
2017-05-15 12:29:44 +10:00
/************************************************************************
* This file has been generated automatically from *
* *
* src/core/processing/qgsprocessingoutputs.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/
Reference in New Issue Copy Permalink