Rev. 1: Prof. Laurent Husson

This is essentially a technical article to accompany the release of a new version of software TerraceM. Changes with earlier versions are significant and adjoining an article is indeed useful to present the changes. The authors meticulously document the many improvements of the new version. The main improvement that the authors put forward is the introduction of an automated method to detect shoreline angles along uplifted coastlines using machine learning. Another improvement is the possibility to use ICESat-2 altimetry that TerraceM facilitates. Last, it permits to map shallow bathymetric structures. I haven't put it to the test, but I trust the software works fine.

Reply: We thank the reviewer for the positive assessment of the manuscript, for recognizing the value of this methodological contribution, and for the constructive comments detailed below. We acknowledge that some parts of the text lacked clarity, which may have led to misunderstandings. We have revised the manuscript accordingly and introduced several modifications to better explain the rationale behind the new version of TerraceM. We have carefully responded to all comments and incorporated the majority of the reviewer’s suggested modifications. We believe these revisions significantly improve the clarity and transparency of the manuscript’s rationale and objectives and more clearly reflect the scope and advances of TerraceM-3. Thank you again for the thoughtful and valuable feedback, which has helped strengthen the manuscript. 

The manuscript is well written and besides the technical section describing the neural networks (which is essentially inaccessible to the non-specialist) the article reads well. 

Reply: We rewrote part of the technical description to make it more accessible to non-specialists (lines 259-280).

I however, have one main concern that -to put it bluntly, my apologies- is that I don't see the benefit of using this sophisticated, computationally and carbon expensive method, to carry out the mapping of coastal terraces? 

Reply: We thank the reviewer for pointing out this important topic. TerraceM-3 is distributed with a pre-trained neural network and therefore does not require training the neural network by users, which is usually requires most of the energy consumption. In routine applications, ML shoreline-angle mapping takes only 2 to 5 seconds per shoreline angle in a standard desktop or laptop computer and does not require high-resources. This makes the associated computational and energy costs negligible. Please find a clarification on the benefits of this method in the next reply.

ML does not seem to outperform manual techniques (indeed the authors are satisfied by the fact that they yield similar results). I might have missed something, but I feel sorry to say that I don't see the rationale of this, beyond the technical performance. 

Reply: The goal of ML in TerraceM-3 is not to outperform experts, but to replicate expert-level mapping consistently, obtaining repeatable results, and at scale. The manuscript does not claim that ML is superior in mapping marine terraces or in understanding coastlines. It instead emphasizes improved consistency, accessibility, and global applicability, especially in regions where expertise in marine-terrace mapping or high-resolution DEMs are unavailable.

The reviewer apparently assumes that outperformance of ML relative to a human operator is the only valid justification for its use. We agree, it is reasonable to ask what the added value is, if results are merely “similar” without obvious superiority. However, this line of reasoning implicitly assumes that similarity in results equates to redundancy and overlooks other important scientific values associated with methodological innovation, such as reproducibility, scalability, transferability, and reduction of operator-dependent bias. In addition, the proposed method reduces the time and effort required for training new users, which result in less carbon costs.

Sorry for the self-reference, I will try to explain this with an example; since the release of TerraceM in 2016, we have trained many students and professionals in neotectonics and marine-terrace mapping. The process of learning marine-terrace mapping and gaining experience with TerraceM requires repetitive training exercises and a significant time and energy investment. TerraceM-3 and the ML -based mapping tool can be used by students and researchers with knowledge of marine-terrace morphology and processes, while mimicking the mapping criteria of a trained expert user. This expedites analysis without requiring extensive training and democratizes the access in resource-limited settings. Furthermore, by using machine learning, we reduce qualitative uncertainties related to user experience, especially if a group of researchers want to joint or compare different marine terrace mapping databases. Reducing bias is important because geological interpretations are based on data, and if the data are biased, the resulting interpretations will be less precise.

Given the fascination for high techs, this approach may obscure the purpose of investigating coastlines -although these are admittedly mentioned in the introduction- by implicitly suggesting that the purpose of science is to blindly pursue technological advances at any cost -including environmental in that case- and not to understand the world we live in. 

Reply: From our view this moves the discussion to a more philosophical perspective, indicating scientific priorities, which are undoubtedly important, but not directly tied to the manuscript’s content. We appreciate the reviewer‘s thoughtful reflection, we attempt to clarify some conceptual aspects and rationale:

The reviewer suggests that integration of ML and ICESat-2 satellite data in mapping marine terraces can be seen as a kind of technological fetishism or a blind fascination; this kind of new technological advances could potentially obscure the purpose of investigating shorelines. However, such as statement risk confusing method with scientific purpose. We would like to state that the manuscript does not attempt to redefine the purpose of coastal geomorphology. It is aimed at addressing well-known practical limitations in marine terrace mapping, introducing a tool designed to improve precision, accuracy, and reproducibility by mimicking the expert-user mapping criteria. We believe the comment is attributing to the manuscript an intent and epistemological stance that are not present or reflected in the text.

We emphasize that TerraceM-3 does not promote a” blind-technological vision of science”, but rather follow a long-standing empirical tradition in Earth sciences, where methodological innovation is used to reduce uncertainty. Geological understanding in this work remains grounded in classical concepts: wave-abrasion processes, sea-level changes, marine terrace geomorphology, and tectonic deformation. The technological components are only used to improve how these classical markers are measured. Regarding the point on “carbon expensive”, environmental costs, TerraceM-3 includes a pre-trained neural network, the tool runs efficiently on standard hardware without need for training and without significant carbon costs. 

More specific and detailed comments are given below. 

To summarize, since the software will be released, it requires a notice, and this article could serve as such, but it is a pity that little scientific content accompanies this release. I hope this helps,

Reply: We acknowledge the critic by the reviewer, this is a technical article that primarily presents the new advances of TerraceM, rather than reporting an important scientific discovery. Accordingly, the scientific content is limited to two areas, where we tested the tool and we elaborated interpretations on the deformation mechanisms with the aim of extending scientific discussions. Nevertheless, we believe this tool will enable other researchers advance the science based on the study of marine terraces.

MAIN POINTS

: 254-297, section 2.2: this section attempts to describe the NN mapping procedure, but assumes that the reader is already knowledgeable about the technique. I'm not asking for a course on NN theory, but clearly, this section (and accompanying figure 5) will filter out a large part of the audience. Yet, this should be an important step, as the reader should be convinced that the use of NN is a progress for terrace mapping. Please clarify.  

Reply: We thank the reviewer for this important comment. We agree that the original version of Section 2.2 placed too much detail on generic neural-network concepts and not in the geomorphic terms. e.g., what the NN actually learns to do and why this represents progress for terrace mapping. We rewrote part of this section (lines 259-280) to explicitly describe the geomorphic task addressed by the NN in a less technical way.

306: I see the shoreline angles, I see the linear regressions, which seem to be fair. However, one may wonder whether this procedure is doing a better job than earlier methods. It would be useful to also show the linear regressions of the terraces that have been initially manually mapped from the DEM (those of fig.4E), and to quantify the difference between the manual and automated methods. 

Reply: For the Cerro El Huevo analysis we only used ML mapping. The figure 4E shows the inner edges used to place the profiles, but no manually shoreline angles were mapped. In this figure and section, we explain the preparation of the data before mapping using inner edges. This is the central objective of TerraceM PreMAP, to reduce spurious lateral correlations before proceed to ML shoreline angle mapping. We modified the caption of Figure 4E to make it clear and also the line indicated (233-234). 

325-340: I understand the reasoning, which is a decent hypothesis. However, the tilt values seem quite large. If the ~1.5 km high / ~150 km wide NR was entirely uplifting the SAm coastline, the shoreline that climb over it during the last stage (right panel, fig. 6)  would be tilted at a max angle of ~0.01°, which is 300-10 times lower than what it observed. How can this be reconciled?

Reply: We appreciate this comment, following this and previous suggestions by the reviewer we calculated the incremental tilt and tilt rate, this is an important point that we missed in the previous version of the manuscript. 

Nevertheless, the comparison proposed by the reviewer assumes that the maximum surface tilt induced by Nazca Ridge subduction can be approximated from a height/width ratio ~1.5 km / ~150 km = ~0.01 (rad) or ~ 0.57°. The 0.01° proposed by the reviewer appears inconsistent with calculations and published geometric constraints. For instance, Saillard et al. (2011) report ridge flank slopes of ~0.55° near the ridge axis and ~0.15° south of the projected Cerro el Huevo location. These values are comparable to the terrace tilts documented in our manuscript. Moreover, the coastal tilting recorded by marine terraces reflects the flexural dynamic response of the SAM plate to ridge subduction rather than the static geometric slope of the incoming ridge, which explain spatial tilt variability. The resulting incremental tilt values that we calculated (following the reviewer suggestion) do not represent anomalously large gradients. We clarified this point in the revised manuscript lines (322 - 338).

366-372: bathymetry=> this is an intersting point that should be better highlighted. Therefore, instead of referring to the not-so-explicit Fig.3, why not showing an example? From the coast of Algeria in particular. Should, in practice, coastal bathy be useless for the algerian case study, simply showing an example in SI, should show the improvement brought by the technique. This specific addition to TerraceM could be useful to many.

Reply: Thank you for this constructive suggestion. We extended the application of bathymetry, including an example site in Algeria into a new figure 7 (lines 411-443).

413-420 and following discussion: "results are consistent..."=> indeed they are. Not only ML is consistent with previous works of Authemayou, but MA and ML and FD are consistent. Then, one may wonder about the benefit of using a complex, computationally expensive method like TerraceM. This is unclear to me if the authors want to benchmark their method with a well documented case-study (comparing with Authemayou) or comparing the 3 methods (MA ML FD) and in this case -no offense- it is indeed difficult to see the benefit. 

Reply: We thank the reviewer for highlighting this lack of clarity. Indeed, we obtained broadly consistent results across methods, though with different levels of precision and accuracy. It is clear that the use of ICESat-2 topography results in higher precision compared to FABDEM-based mapping. Regarding the comparison between ML and MA, we agree with the reviewer, both produce similar and consistent results, which is precisely the expected and desired behaviour of a valid mapping tool. The added value of TerraceM-3 and the ML-based approach does not lie in producing different terrace measurements, but in providing a standardized, reproducible, and scalable way of obtaining results that are comparable to those of experienced users. This was the objective of the validation example, that resulted in the recognition of additional levels not documented by Authemayou et al. (2017).

We acknowledge that the objectives of this section were not clear enough. We revised the text to explicitly emphasize that this example is intended as a benchmarking and validation exercise for TerraceM-3 (Lines 447), we also included the added value of using TerraceM-3 ML and why repetition between ML and MA results are important (Lines 517-523).

In the following discussion, the authors further indicate that the difference between MA and ML is extremely small. "the performance of the machine learning approach is comparable to that of an experienced user" Why would one use ML then? 

Reply: We thank the reviewer for highlighting this point. As mentioned in the previous comment and at the beginning of this reply, the goal of ML in TerraceM-3 is not to exceed expert performance, but to reproduce expert-level mapping consistently independently of user mapping experience. The fact that the ML results are comparable to those of an experienced user is therefore a key outcome rather than a limitation.

While a trained expert can achieve similar accuracy, manual mapping is inherently operator-dependent and affected by user experience, learning curves, and subjective decisions. Thus, differences in user experience may lead to non-systematic errors and uncertainties that are difficult to quantify. In contrast, the ML-based approach provides stable and repeatable outputs that are independent of operator mapping experience. 

We present a new ML mapping not to replace expert judgment, but to formalize expert knowledge into a tool that improves reproducibility of marine-terrace mapping, while preserving expert-level performance.

418-420: First, SL curves of Bintanja and Lisiecki are being used (and I'm fine with that choice), and the uncertainties of these SL curves are being propagated in the interpretation. Second, highstands are assigned to shoreline angles. This is a fairly common hypothesis, but of course the relationship is not as simple, and this is a known source of uncertainty, that compares to the uncertainty related to the mapping of the terraces. Similar comment holds with the assumption of constant coastal uplift. 

Reply: We agree with the reviewer that the direct assignment of marine terraces to sea-level highstands might be inaccurate under temporally variably deformation rates and marine terrace reoccupation. We also acknowledge that the assumption of constant coastal uplift represents an additional source of uncertainty.

In this study, we revisit the mapping of Authemayou et al. (2017) using the same chronological constraints and interpretative framework adopted by those authors. In this specific example, our primary objective is not to refine the terrace chronology or uplift history, but to compare elevation differences and similarities between our mapping and the previous one in order to test the performance of ICESat-2 data and the ML-based mapping approach (Line 447).

To make these assumptions clearer, we now explicitly state in the text that both the chronological assignment of terrace levels to highstands and the assumption of constant uplift rates are interpretative choices that follow the study of Authemayou et al. (2017) and represent known sources of uncertainty (Lines 474-477).

MISC

: 71: magmatic inflation seems quite marginal compared to the other generic processes. 

Reply: Thank you for this suggestion. magmatic inflation can be rapid but for apparently short periods of time We believe this fits in the context of crustal deformation mechanisms, but not it all with the time-range expected for marine terraces. We extended the description of process including also mantle deformation sources, such as in Angola (Walker et al 2016), which deformation is stored permanently in marine terraces (Line 71).

114: extra-comma in "of digital topography, may compromise". 

Reply: this was corrected as suggested


140: "marine or lacustrine highstands" => replace by "sea or lake levels stands" (because it is more general than highstands).

Reply: this was corrected as suggested

148: following the comment on the computational power, please add somewhere a paragraph on the energy/carbon budget of ML and of using TerraceM3 (as opposed to other methods).

Reply: we included this clarification in lines 154-155

154: the code is open source, which is desirable, but could there be another option than Matlab, which is conversely not freely available? 

Reply: Yes, we also include a python version, please notice that this is described in line 593.

186: "which can be straightforward if the mapper has a basic knowledge on the morphology of marine terraces and GIS software" => of course! is that useful to specify that some knowledge of is needed? It incidentally suggests that TerraceM3 can be used entirely blindly, which raises some questions!

Reply: In any case, a solid background in geomorphology and an understanding of marine-terrace formation processes are required. Machine-learning methods help reduce the amount of practical training needed for marine-terrace mapping; however, they do not eliminate the need for geomorphological expertise or conceptual understanding. TerraceM3 is not designed to operate independently of geomorphological understanding, as with any analytical tool, its proper application ultimately depends on the user. 

217: "complex geodynamic setting, making it an ideal scenario" => the fact that it is "complex" doesn't seem to make it "ideal" a priori. Quite the opposite, most of the time, in fact!

Reply: We thank the reviewer for highlighting this logical issue. We modified these lines to indicate the challenges of studying this site (Lines 255-257)

225: tautological proposition "some terrace levels are discontinuous and their lateral continuity is difficult to discern"

Reply: Thank you for noticing this repetition, we rewrote these lines for clarity(Lines 255-257)

228-234: I don't get it: I don't see any change in the mapped terraces on each of the panels of Fig. 4, which seem to say that the initial RRIM mapping remained unchanged throughout. If so, what's the use of the PreMap workflow?

Reply: This is not the mapping phase, instead this the preparation phase that requires identifying the inner edges to avoid lateral miscorrelation. After this step comes the mapping of the shoreline angles of marine terraces, this is the purpose of PreMAP. We rewrote these lines for clarity (Lines 229-237). 

328: "areas of gravitational relaxation and subsidence" => not sure what this means. There might be some hints in Saillard et al 2017 regarding uplift and subsidence near tectonic asperities or ridges. 

Reply: Following Hampel et al. (2004), we replaced this term by mass transfer, which is probably clearer

338: "These results highlight...": not true, since the results, according to the authors, simply confirm what was already known from observations and models. 

Reply: We respectfully disagree with this comment. While previous studies have documented uplift patterns along the Marcona Bay and Cerro el Huevo based on geomorphic observations and geodynamic modeling (e.g., Hsu, 1992; Saillard et al., 2011; Jara-Muñoz et al., 2019, Hampel et al., 2004 etc.), they did not quantify the tilting of marine-terrace sequences nor relate changes in tilt polarity to the migration of the Nazca Ridge. We have revised the text to clarify this point and better emphasize the novel approach of our scientific contribution (Lines 374-377).

395 and 413 and 417 and elsewhere: Authemayou, not Anthemayou

Reply: We are sorry for this mistake, we corrected this typo along the text 

FIGURES

: Fig 3: I found it almost impossible to understand, at least at this stage of the article (it is possible that after reading the rest of the article, one can understand it better, though; but that would imply that the figure or its description are mispositioned in the article). This is probably due to the design of the architecture and workflow, where one gets instantaneously lost, and to the fact that there is almost no description of any of the modules. 

Reply: We thank the reviewer for this comment, we agree the figure wasn’t clear. We remake the figure rewriting also the caption to increase the clarity. We hope the reviewer find this new version clearer.

Fig. 6: on panel C, tilt values are those that are recorded at present-day. i.e. 0.47 to 0.08° for terraces dated between MIS13 and MIS9. But the tilt at present-day should in fact be the integral of the tilting history from MIS13 to present-day. Including the following phases, which would change the figures to (0.47 0.08) + (0.06 -0.05) + (-0.36 -0.06) for the left panel; (0.06 -0.05) + (-0.36 -0.06) for the central panel; (-0.36 -0.06) for the right panel.

Reply: We thank the reviewer for this constructive comment. The tilt values shown in Fig. 6 correspond to the present-day finite tilt of each individual terrace surface. These values already represent the time-integrated angular deformation from the time of terrace formation to the present. Therefore, they do not require summation with subsequent tilt differences. The incremental angular deformation between two terraces is obtained from the difference between their finite tilts (e.g., θ₁₃ − θ₉), which isolates deformation occurring between this time interval. Instead, the sum of finite tilt values from different terraces would lead to double-counting deformation because each measured tilt already includes all subsequent deformation phases. We calculated the incremental tilt and the tilt rate for each terrace level and we include it in Fig. 6. We clarified and extended the discussion of this tilt in the manuscript, also considering the potential effect of local faults (Lines 365-372).

Fig. 7: C and D are inverted. Regardless, couldn't they be combined? I don't see the benefit of panel D (only showing MA).

Reply: Figures 7C and 7D (now renamed Fig 8) show different and complementary information. Figure 8C illustrates the elevation patterns of marine terraces obtained using the different mapping methods (MA, ML, and FD), and is used to compare the results of these approaches. In contrast, Figure 8D shows the uplift rates calculated using the chronological constraints of Authemayou et al. (2017).

For Figure 8D, we only used the manual mapping (MA), as MA represents the benchmark against which the other mapping methods are evaluated. This panel is therefore not intended to compare mapping techniques, but to jointly visualize topography of the Sahel ridge and uplift rates in order to discuss whether the observed deformation pattern is related. In this context, Figure 8D provides complementary geological information that is not conveyed by Figure 8C alone.

Both figures are based on the projection of shoreline angles along the X–Y profile and are not inverted. This can be verified by the fact that terraces at Tipaza are lower and display lower uplift rates than those at Douaouda. To facilitate interpretation and avoid confusion, we added X–Y labels to both panels.

Rev. 2: Dr. Michele Delchiaro

This manuscript presents TerraceM-3, a substantial new release of the TerraceM software designed to improve the precision, reproducibility, and accessibility of wave-abrasion terrace mapping. The authors introduce three key methodological developments: (i) TerraceM_PreMAP, a systematic preprocessing workflow intended to minimize geometric biases in swath-profile construction; (ii) a machine-learning framework for automated shoreline-angle detection, which aims to replicate expert mapping behaviour and thereby reduce operator-dependent variability; and (iii) an ICESat-2 module that enables the direct downloading, filtering, and processing of photon-counting altimetry data, addressing the widespread scarcity of high-resolution topography in many coastal regions.

Overall, the manuscript is well written, clearly structured, and technically sound. The scientific motivation is strong, and the topic is highly relevant for the tectonic geomorphology and coastal geohazards communities. The integration of machine learning into a traditionally qualitative geomorphic task is thoughtfully implemented and benchmarked against manual mapping, while the two case studies (Cerro El Huevo, Peru; Sahel Ridge, Algeria) effectively demonstrate the applicability and added value of the proposed workflows. Importantly, the paper represents a substantial methodological step forward relative to earlier versions of TerraceM, especially through its explicit distinction between systematic errors (addressed via standardized preprocessing and improved geometry control) and non-systematic user-dependent errors (addressed through machine learning).

In my opinion, the manuscript is suitable for publication after minor revisions. Most of my comments concern clarifying methodological choices, better explaining how certain components (particularly ICESat-2 and the human–machine interaction concept) are implemented, and improving the discussion of uncertainty and generalization. Addressing these points I hope the paper significantly enhances the clarity, transparency, and practical utility for a broad readership.

Reply: We greatly appreciate the positive evaluation of the overall scientific motivation, technical implementation, relevance, and the step forward represented by TerraceM-3 compared to earlier versions. We have carefully addressed each of the specific points raised in the detailed comments, with particular attention to the description of ICESat data and the human-machine interactions, related uncertainties and the training of the machine learning. We are grateful for the reviewer’s time and feedback, which have strengthened the final version of the manuscript.

Minor comments

LINES 119-124 and 342-380: ICESat-2 is technically correctly described throughout the manuscript, and the references are appropriate. However, the description is somewhat fragmented and occasionally ambiguous, especially for readers who are not already familiar with satellite altimetry products. Given that ICESat-2 represents a key methodological pillar of TerraceM-3, its role and data characteristics could be explained more explicitly and more consistently.

Reply: We thank the reviewer for this comment. We modified the text to make the description of ICESat data clearer, the details are indicated below.

Here are some points:

Are ICESat-2 data used in this study globally available?

Reply: Yes, we added the description in lines 121 and 564.

Which is the acquisition time window for the ICESat-2?

Reply: For photon-counting lidar instruments like ATLAS, the term “acquisition-time window” is not formally used in the documentation. Rather data sampling and footprint overlap are used and described in terms of along-track measurement density, beam geometry and operation time. We added the additional information in lines 383 and 388.

What is meant by “high resolution” when referring to ICESat-2 data (e.g., along-track point spacing versus spatial coverage)?

Reply: The term “high resolution” refers to the 20 cm along-track photon returns (measurement spacing) and the centimetre-level accuracy of the elevation measurement. We added the description of high resolution and photon spacing in lines 388-390.

How are bare-earth elevations obtained in practice, including the role of photon classification (ATL products) and associated filtering assumptions?

Reply: The noise/background is filtered by accounting for returns that represent a coherent elevation structure along track, rather than being randomly scattered. After this step, the vertical structure of the remaining cluster can be split into the earliest returns (canopy), intermediate returns (branches/leaves) and the latest returns (bare-earth).  We added a description in lines 400-402

The bathymetry data are very interesting, and this is a point to explore a bit to me. Could the authors provide more detail on how the bathymetric data can be integrated into the terrace mapping workflow?

Reply: We included a new study site where the bathymetry was extracted in Algeria (Lines 418-443). We also explained the integration of TerraceM BAT and the TerraceM ICESat-2 mapping workflow if the operator want to map submarine terraces (lines 418-419). 

LINES 245-252: Is the swath boxes exclusion done directly in Terrace_M-3?

Reply: Yes, the exclusion is done in QGIS. We clarified the point suggested by the reviewer in line 242 

LINE 470-494: It is not clear if the “Analysis of human-machine interaction” is implemented in TerraceM-3. If yes how?  Referring to the presented results, how is expert behaviour encoded in the training data? 

Reply: We thank the reviewer for this insightful comment, which highlights that the link between the human-machine interaction analysis and TerraceM-3 was not sufficiently explicit. We have now added a short introductory paragraph at the beginning of Section 3 that clarifies the purpose of the section and its direct connection to the machine-learning algorithms in TerraceM-3 (Lines 525 – 529).

The human–machine interaction analysis itself is not a feature that runs inside TerraceM-3. Rather, the insights gained from the experiment were used to design and train the neural network that is now implemented in TerraceM-3.

We encoded the expert behaviour during the training of the neural network, we used a large dataset of manually mapped shoreline angles previously produced by an experienced interpreter (Freisleben et al., 2020), this is now explained in lines 284 - 289.

Which parts of the manual mapping process - segment selection, exclusion of noisy areas, identification of platform/cliff- are used to train the neural network? What exactly does the machine-learning model predict? Does it reproduce the expert’s sequence of decisions (platform/cliff segments + regressions), or only the final shoreline angle?

Reply: We thank the reviewer for this comment, we clarified this in Lines 286-291, as indicated before the Neural Network (NN) is trained with thousands of previously mapped profiles, we trained two NN one for recognizing the paleo-cliff and another for recognizing the paleo-platform, therefore the automated mapping follows the human mapping criteria of the manual mapping. The shoreline angle comes as a result of the segments identified by the NN, however, this marker is very important as we use it as a measure of the performance of the ML mapping. 

 Technical corrections

LINE 162: Better to put parenthesis here “Cerro El Huevo (Peru), and Sahel Ridge (Algeria)”?

Reply: We modified the countries adding a parenthesis as suggested

LINE 272: Correct into “consisted of”.

Reply: We corrected this typo

LINE 295: Correct into “Authemayou”.

Reply: We corrected this typo along the text

Figure 1: “Erodability” or “erodibility”? Make it consistent in all the manuscript.

Reply: We thank the reviewer for highlighting this error, we corrected the term in fig 1