GPF Workflows

Target release6.0
Document status
Document owner
DesignerFormer user (Deleted)
DevelopersFormer user (Deleted)
QAOlga Faber (Unlicensed)


  • Generalise tile-based pull-processing processing to multi-purpose push-processing workflows, i.e. allow execution of GPF graphs from source(s) to target(s).
  • Make pull-processing an implementation detail of GPF operators
  • Account for GPF operators that don’t compute tiles (or don’t even output products? maybe later...)
  • Allow progress monitoring of whole workflow and individual workflow step execution

Background and strategic fit

A number of GPF operators don't compute target tiles at all: Binning, Mosaicing, Pixel Extraction, Statistics, and many more. In order to trigger their computation, awkward code is usually introduced to trigger the one-time computation of the operator's result. Tile-based pull-processing shall become an implementation detail, a number of operators just implement a new execute() method.


  • It is assumed it is always possible to bring processing nodes in a unambiguous order ensuring correct processing of outputs in each step.
  • It is assumed that outputs of an operator are still generated by their initialize() methods, otherwise we introduce incompatibility with existing graphs


#TitleUser StoryImportanceNotes
1Operator.execute() methodWrite operators by implementing a execute() method that takes a progress monitor and a context object as parameter. The context object is used to access the workflow and its steps and can be used e.g. by a target or intermediate step to determine and set appropriate tile sizes to be used by a ReadOp located at the start of the workflow.Must have
2API to run graphs as workflow

User interaction and design


Below is a list of questions to be addressed as a result of this requirements document:

What happens if an operator requires in its "execute"-method the results from another operator's "compute_tile"-method?

Not Doing