HeProMo: A decision support tool to estimate wood harvesting productivities

In the field of forestry, one of the most economically important ecosystem service is the provision of timber. The need to calculate the economic effects of forest management in the short, medium, and long term is increasing. Forest operations or timber harvesting, which comprises felling, processing, and transport of trees or timber, are responsible for a large part of the costs and environmental impacts associated to forest management or enterprises. From a decision maker’s perspective, it is essential to estimate working productivity and production costs under given operating conditions before any operation is conducted. This work addresses the lack of a valid collection of models that allows estimating time, productivities, and costs of labor and machinery for the most important forest operations in forest stands under Central European conditions. To create such models, we used data from forest enterprises, manual time studies, and the literature. This work presents a decision support tool that estimates the wood harvesting productivities of 12 different kinds of forest operations under Central European conditions. It includes forest operations using chainsaws, harvesters, skidders, forwarders, chippers, cable and tower yarders, and helicopters. In addition, the tool covers three models for wood volume estimation. The tool is written in Java and available open-source under the Apache License. This work shows how the tool can be used by describing its graphical user interface (GUI) and its application programming interface (API) that facilitates bulk processing of scientific data. Carefully selected default values allow estimations without knowing all input variables in detail. Each model is accompanied by an in-depth documentation where the forest operation, input variables, formulas, and statistical background are given. We conclude that HeProMo is a very useful tool for applications in forest practice, research, and teaching.

the submission process. I agree that the article describes different aspects of the software. However, I think that the article is an independent scientific work, because it also describes the method how this software was developed in detail (e.g. data collection, modeling approach), compares the software with other existing software, and declares where the software fills a gap of knowledge.
The figures, tables and list are most clearly presented and correctly labelled. The title is adequate and informative. The literature is, for the most part, up-to-date and relevant.
Detailed and general remarks/questions: (Table 1) Please specify 'place at the forest road' (skidder, Forwarder 2x). Did you mean truckaccessible road (Helicopter) or a forest road and you need an additional 'Holz vorführen'?
We meant truck-accessible road and clarified this in the manuscript.
(Line 59) Please specify the costs of 100%. Wood costs at the roadside? Please add a source.
We added a clarification in brackets. We adapted Figure 1 to avoid confusion (replaced "time studies" with "manual time studies", "data monitoring" with "permanent data monitoring", added an example, and removed the two "automation"-arrows). Manual time studies are conducted by observing the workers and machines during a forest operation with a stop watch. Permanent data monitoring is e.g. a nationwide survey where forest enterprises regularly report operational data.
( Table 2) The place of table 2 seems to be wrong (maybe to line 137 after the first referencing) We moved the table to the correct place.

(Table 2) If possible, add year of actualization and Influence factors of the models.
We added the year of actualization to the table. We did not add the influence factors of the models, as this would make the table too complicated -many models have around 5 influence factors (plus around 10 common to all models), some of the older models many more (up to 27 influence factors).

(Line 185) Is there a possibility to implement the actual conversation between CHF/USD/EUR?
At the moment no. The currency code in the software is just a character string that can be changed to an arbitrary value. As cost unit rates differ across countries and regions (even if the currency is the same), even if we would actually have the possibility for a conversion, the cost unit rates still need to be adapted to local conditions, making the conversion useless. We reformulated that sentence in the manuscript.

(Line 316) For English, the API (variable identifiers, methods, class) was adopted. What about French and Italian?
We think that at the moment an API in English for international users should be sufficient. It is in our opinion unusual to have an API in multiple languages. The German API exists rather for historical reasons, because the German version of HeProMo was the one used most for years. However, if we get feedback from the community that an API in additional languages is a desired feature, we won't hesitate to implement that.
(Line 422) What about the limitation of influence factors, e.g. individual operators performance, and exceptional situation (storm, bark beetle,…)? Should they take into account by the specific correction factor? Is something planned in the future?
Differences in performance of individual operators are not considered, but it is assumed that all operators are sufficiently trained on the used machines. If the performance of the operators is systematically lower or higher than assumed in the models, then the specific correction factor can be used.
The models are currently not intended for exceptional situations, such as storm or bark beetle, because the underlying data was gathered in standard situations. Until now it was not planned to extend the tools in that direction, but if the demand for it exists, it would certainly be interesting to extend the tool in that direction.
(General) What about Versioning of the software? Are the (stable) APIs always follow the change of the main JAVA program immediately?
The software version described in the manuscript is version 2.4.3 (June 2020) and is the most up-todate version. We added the version number to the software availability section.
The API always follows the changes of the software immediately. How it changes depends on the type of change: -Changes in the calculation method (e.g. due to newer data from forest enterprises, added or removed influence factors, or a bug) -> Immediately reflected by the API. Such changes will be clearly documented and the older versions always remain available for backward compatibility.
-Changes of the name of an input variable (e.g. because of a spelling error or a wrong translation) -> a new identifier with the correct name will be added to the API, the old one will remain in the API for backward compatibility but marked as Deprecated (a Java annotation that tells the developer that a certain class or method shouldn't be used anymore).
So, in a nutshell, the API is designed to remain stable, but the calculation behind may change. If this is the case, it will be clearly indicated.

(General/line 434) How can the interested scientific community influence the further development of the program?
The source code and relevant files of HeProMo are now stored on GitHub. There are multiple possibilities how the further development of the program can be influenced. For example, a "fork" is possible, which means that an interested user copies the complete source code to an own project, and continues further development at his own discretion. Or an interested user creates an "Issue", where he can request a new feature or file a bug. Or he adapts the code and sends a "pull request", which is a request to us to integrate code written by someone else into our code. We clarified this in a footnote.

(Line 464) Should the community improve the software?
We offer this possibility to the community by making the code open source. The community can improve the software (in addition to our efforts to do so), if desired.

The manuscript:
HeProMo: A decision support tool to estimate wood harvesting productivities is an interesting work presenting development and application of new tool specifically dedicated to Central European forestry conditions. The manuscript is written in a good way, is understood, though some parts require rewriting (marked in the main file). Additionally, I would suggest to write more why this tool was developed, what was the reason of developing it and what actually the new tool replaces in practices (in fact hypothesis of job undertaken would be useful before the objective/s were formulated, conclusion should answer the objective/s more directly).
English corrections, prof-reading would improve the manuscript, too.

Detailed comments are in the main file to be considered for improvement of revised version.
Good luck with further work,

Reviewer
Thank you for your very helpful comments. We considered most of your 31 comments marked in the main file, including a rewriting of the abstract and reorganizing table captions. However, we disagree with a few of your comments, and explain the reasons in the following: [Comments in manuscript, lines 101/108] Replace are with were (2x), PLease use past tenses when describe methods, results, discussion and conclusion.
In our opinion, present tense is correct in the marked places because it describes the behavior of the software, i.e. it describes facts that are still true and continue to be true. For the rest of the manuscript, we checked the tenses again and believe they are correct, as we did not change them after language editing and they seem reasonable to us.

[Comment in manuscript, line 393] Please add why new tool was needed for Central European conditions? Where was the difference/gap that new tool was needed?
This is explained in the introduction and at the beginning of chapter two. In the introduction, we explain why such a tool is needed (lines 82-86 of the revised document with tracked changes) and where it fills a gap (lines 87-94 of the revised document with tracked changes). At the beginning of chapter two, we characterize the forests and the forest operations in Central Europe (e.g. single-tree thinning, small timber volumes per cut) to point out why forest operations in these regions are different than elsewhere (lines 105-110 of the revised document with tracked changes).
English corrections, prof-reading would improve the manuscript, too.
The manuscript was language-edited by a professional language editor before we submitted the manuscript to PLOS ONE.
[Comment in manuscript, Table 1] to be deleted. motor-manual means by chainsaw, this extra info can be deleted While this information might be obvious to an expert in the field of forestry, parts of the paper might be more interesting to people with a computer science background, and we believe that this is a useful information for these people.