the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 18 Dec 2025
TerraceM-3: Integrating machine learning and ICESat-2 altimetry to estimate deformation rates from wave-abrasion terraces
Abstract. Wave-abrasion terraces are geomorphic marker horizons that provide information of past water levels, in marine and lacustrine environments. By integrating elevation measurements and age knowledge they serve as strain markers to assess vertical deformation rates associated with tectonic and/or climatic processes. As most geomorphic markers, wave-abrasion terraces are ephemeral features, and their topographic signature has variable levels of noise. Therefore, accurate and precise estimates of marine terrace morphology are essential to obtain significant uplift/subsidence rates. TerraceM-3 enables users to reduce non-systematic and systematic errors in terrace mapping by integrating machine learning techniques to replicate human mapping criteria, and standardized and reproducible workflows to handle systematic errors. In many regions, the availability of high-resolution topographic data remains relatively scarce limiting precision in geomorphic marker mapping. TerraceM-3 introduces a new module for downloading, filtering, and processing centimeter-resolution topographic data from the ICESat-2 satellite at global scale. The TerraceM-ICESat module produces vegetation-free profiles ready for assisted machine-learning mapping into a graphical user interface. Shallow bathymetry may be also extracted to extend the mapping of drowned terraces offshore. The new functionalities of TerraceM-3 were tested along tectonically active coasts in Peru and Algeria, revealing detailed deformation histories controlled by subducted seamounts and crustal faults. TerraceM-3 is designed to support research in tectonic geomorphology and paleoclimate studies by enhancing the precision and accuracy of wave-abrasion terrace mapping with applications in the assessment of coastal hazards.
- Preprint
(5239 KB) - Metadata XML
-
Supplement
(1283 KB) - BibTeX
- EndNote
Status: final response (author comments only)
- RC1: 'Comment on egusphere-2025-5364', Laurent Husson, 16 Jan 2026
-
RC2: 'Comment on egusphere-2025-5364', Michele Delchiaro, 16 Jan 2026
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.
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.
Here are some points:
Are ICESat-2 data used in this study globally available?
Which is the acquisition time window for the ICESat-2?
What is meant by “high resolution” when referring to ICESat-2 data (e.g., along-track point spacing versus spatial coverage)?
How are bare-earth elevations obtained in practice, including the role of photon classification (ATL products) and associated filtering assumptions?
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?
LINES 245-252: Is the swath boxes exclusion done directly in Terrace_M-3?
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? 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?
Technical corrections
LINE 162: Better to put parenthesis here “Cerro El Huevo (Peru), and Sahel Ridge (Algeria)”?
LINE 272: Correct into “consisted of”.
LINE 295: Correct into “Authemayou”.
Figure 1: “Erodability” or “erodibility”? Make it consistent in all the manuscript.
Citation: https://doi.org/10.5194/egusphere-2025-5364-RC2
Model code and software
TerraceM-3: Marine terrace mapping using machine learning and satellite altimetry J. Jara-Muñoz et al. https://zenodo.org/records/17439972
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 215 | 91 | 20 | 326 | 37 | 14 | 17 |
- HTML: 215
- PDF: 91
- XML: 20
- Total: 326
- Supplement: 37
- BibTeX: 14
- EndNote: 17
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Review of article "TerraceM-3: Integrating machine learning and ICESat-2 altimetry to estimate deformation rates from wave-abrasion terraces" by Jara-Munoz et al, Esurf
Laurent Husson, Jan 16th, 2026
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!
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.
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? 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. 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. 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,
Regards,
Laurent Husson
MAIN POINTS
l 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.
l 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.
l 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?
l 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.
l 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.
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?
l 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.
MISC
l 71: magmatic inflation seems quite marginal compared to the other generic processes.
l 114: extra-comma in "of digital topography, may compromise".
l 140: "marine or lacustrine highstands" => replace by "sea or lake levels stands" (because it is more general than highstands).
l 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).
l 154: the code is open source, which is desirable, but could there be another option than Matlab, which is conversely not freely available?
l 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!
l 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!
l 225: tautological proposition "some terrace levels are discontinuous and their lateral continuity is difficult to discern"
l 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?
l 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.
l 338: "These results highlight...": not true, since the results, according to the authors, simply confirm what was already known from observations and models.
l 395 and 413 and 417 and elsewhere: Authemayou, not Anthemayou
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.
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.
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).