## 3 Results and Discussion
### Alternative Workflow Implementation through GNU Makefile  
The original implementation of the STARS image workflow is a Linux shell script. At an early stage in the design and realization of our workflow, we understood that our approach had to be modular and that the resulting image products might come in versions with the need for reprocessing when new routines became available or when ancillary input data were updated. As the computational cost for complete reprocessing cycles is prohibitive, we needed an approach that would allow the rerun of only the necessary processing steps. Specifically, we wanted to routinely allow the:  
* addition of image sources to the collection and the automatic processing of only these by the workflow,
* the replacement of a workflow step and have this lead to reprocessing of image half-products leading to up-to-date end-products, and
* the parallelization of the execution of the workflow through intelligent rules. We achieved the above using a GNU Makefile, which is a facility to define file-oriented input/output processes and associated file dependencies through rule-based specifications [63]. Originally devised to help in software development projects, it serves well to define more general computer processes like our image workflow. An example Make rule depicting the implementation of a processing step is shown in Equations (1) to (3). Determine the files that will be atmospherically corrected. The output of the \"find\" call is placed in the list. \[\text{actor\_list\_src}:=\$(\text{shell find \text{\textminus}/stars/acquired/DG/ \text{\textminus}name ^{*}.TIF^{\text{\textminus}}\mid\text{sort})} \tag{1}\]  
Generate the corresponding full paths of the output files. Copy the '\(\text{actor\_list\_src}\)', but substitute 'acquired/DG' by 'derived/1_actor_6s'. \[\text{actor\_list\_dst}:=\$(\text{join \$(\text{subst acquired/DG,derived/1\_actor\_6s},\$(\text{abspath \$(\text{addsuffix}}\)  
\(\text{\textminus}/\),\(\text{\textminus}(\text{actor\_list\_src})))))),$(\text{addprefix /\$(\text{\textminus}(\text{notdir \textminus}(\text{actor\_list\_src}))))}$}\] (2)  
Atmospheric correction: add one Makefile rule per src/dst file pair. \"make\" will determine if the 'dst' file needs to be (re-)created, and the recipe is a call to pythonWrV8.py  
\[\$(\text{call addrule,\$(\text{actor\_list\_src}),$(\text{actor\_list\_ dst}),$(\text{\textminus}(\text{base)}/\text{actor\_6s}/PythonWrapper \&\text{\textminus}$}\]  
python $(\text{base})/\text{actor\_6s}/PythonWrapper/pythonWrV8.py -band4n8 alldir=$S(\text{dir \$S$<$})\] (3)  
-outputdir=$S(dir \$S$(\text{dir \$S$<$}))\]  
Specific challenges had to be resolved for our implementation with Make. Image providers use non-trivial and non-standardized filename conventions. Make was originally meant to operate in a flat folder structure, with the file name prefix, stem, and extension as primary keys to the file's semantics. Source and target files can be referred to by a filename pattern, but this mechanism allows only one  
Figure 8: Temporal progression of NDVI (average (blue line) and standard deviation (shaded)) for all the fields for a specific crop (cumulative statistics) based on all the VHSR satellite images processed in the workflow. Statistics for all peanut fields in Sukumba, Mali, for the year 2014 (**left**) and for all maize fields in Kofa, Nigeria, for the year 2015 (**right**). wildcard. Tile stitching, as a many-to-one image process, is specifically cumbersome because many tiles should produce a single image mosaic, but the individual tile filenames do not make explicit the spatial relations between tiles that one needs to understand for stitching. In other words, Make is not spatially aware. Our solution to these challenges is to devise the file dependency rules on the fly: one Make statement constructs the actually required Make-rules, as opposed to a single rule with wildcards. These rules are subsequently executed.