the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 21 Nov 2024
Short Communications: Multiscale topographic complexity analysis with pyTopoComplexity
Abstract. pyTopoComplexity is a Python package designed for efficient and customizable quantification of topographic complexity using four advanced methods: two-dimensional continuous wavelet transform analysis, fractal dimension estimation, Rugosity Index, and Terrain Position Index calculations. This package addresses the lack of open-source software for these advanced terrain analysis techniques essential for modern geomorphology research, enhancing data comparison and reproducibility. By assessing topographic complexity across multiple spatial scales, pyTopoComplexity allows researchers to identify characteristic morphological scales of the studied landform. The software repository also includes a Jupyter Notebook that integrates components from the surface-process modeling platform Landlab (Hobley et al., 2017), facilitating the exploration of how terrestrial processes, such as hillslope diffusion and stream power incision, drive the evolution of topographic complexity over time. When these complexity metrics are calibrated with absolute age dating, they offer a means to estimate in-situ hillslope diffusivity and fluvial erodibility, which are critical factors in determining the efficiency of landscape recovery after significant geomorphic disturbances like landslides. By integrating these features, pyTopoComplexity expands the analytical toolkit for measuring and simulating the time-dependent persistence of geomorphic signatures against environmental and geological forces.
- Preprint
(15456 KB) - Metadata XML
-
Supplement
(5675 KB) - BibTeX
- EndNote
Status: closed
-
RC1: 'Comment on egusphere-2024-3415', Anonymous Referee #1, 28 Dec 2024
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
Line 23: Are “utility and popularity” necessary?
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
Line 176: What is the difference between "ruggedness" and "roughness"?
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
Line 209: "...consistent with the Taylor series expansion"?
Line 211: Watch in text citation format
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
Figure 3: Color the points in (b) with the color of the landslide or label the number?
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
Section 4: I think this section is really solid. Nice work.
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
Citation: https://doi.org/10.5194/egusphere-2024-3415-RC1 -
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
-
RC2: 'Comment on egusphere-2024-3415', Anonymous Referee #2, 13 Jan 2025
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining
or are you saying where those two values are equal it “represents the vector of topographic…” Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
Line 240: citation for published NFSR valley landslide inventory?
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
Line 250: Do you set a threshold to define “low RMSE”?
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
____________________________________________________________________________
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
Citation: https://doi.org/10.5194/egusphere-2024-3415-RC2 -
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
Status: closed
-
RC1: 'Comment on egusphere-2024-3415', Anonymous Referee #1, 28 Dec 2024
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
Line 23: Are “utility and popularity” necessary?
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
Line 176: What is the difference between "ruggedness" and "roughness"?
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
Line 209: "...consistent with the Taylor series expansion"?
Line 211: Watch in text citation format
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
Figure 3: Color the points in (b) with the color of the landslide or label the number?
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
Section 4: I think this section is really solid. Nice work.
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
Citation: https://doi.org/10.5194/egusphere-2024-3415-RC1 -
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
-
RC2: 'Comment on egusphere-2024-3415', Anonymous Referee #2, 13 Jan 2025
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining
or are you saying where those two values are equal it “represents the vector of topographic…” Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
Line 240: citation for published NFSR valley landslide inventory?
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
Line 250: Do you set a threshold to define “low RMSE”?
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
____________________________________________________________________________
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
Citation: https://doi.org/10.5194/egusphere-2024-3415-RC2 -
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
-
AC1: 'Comment on egusphere-2024-3415', Larry Syu-Heng Lai, 31 Jan 2025
Authors’ responses and revisions to reviews for the manuscript titled “Short Communication: Multiscale topographic complexity analysis with pyTopoComplexity” by Lai et al.
=====
Dear reviewers,We sincerely appreciate your valuable comments that significantly improve this manuscript. Here we provide our point-by-point responses to your review comments, including corresponding line numbers in the revised manuscript (the “clean” version). We also add a list of a few minor changes in addition to the suggestions.
Sincerely,
Larry Syu-Heng Lai
=====Responses to RC1:
This is a neat contribution to the ever-growing Python suite of morphometry tools, and the authors have chosen an excellent test case in dating landslide deposits. In addition to using these tools to ask questions about rates and dates of upland processes, the application to landslide (and probably terrace?) dating means that nonspecialists might consider using the package to assess geohazards in other sites. For this reason, my advice to the authors mostly focuses on pitching their manuscript/software to a broader, less technical audience.
[Authors’ response]: We appreciate the valuable review provided by reviewer 1. We have incorporated some relevant revisions in the Abstract (line 10), Introduction (lines 26-27), section 2.1 (lines 84-86), section 3 (lines 238-249), and Conclusions (lines 470-475) to enhance the clarity and applicability of the study’s methodology in estimating the chronology of event sedimentation on terrace surfaces within alluvial fan systems and landslide geohazards.
---
The number one piece of feedback I have is to reconsider the figures chosen for this manuscript. While they are very cool for a geomorphologist intimately interested in landscape evolution and morphometry, in general, the use of small multiples with teeny font and tricky-to-interpret contours does not convince a more generic potential user of the software to try it out. Figure 3 is the figure most “on the right track” toward this end. I strongly recommend designing a schematic showing each of the topographic metrics the package can perform demonstrating on some sort of sketch for a representative landscape (perhaps a landslide). You can keep many elements of the current Figure 1, but instead of showing the modulation of the grid size, just show one grid size and use a consistent colorbar. Make a figure that a hazard practitioner might understand. For the other figures, I recommend re-envisioning how maybe only one or two panels might be zoomed in to and annotated.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram illustrating pyTopoComplexity’s capabilities and its workflow. Additionally, we’ve also reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
The second piece of advice is to be more explicit in explaining to reader why these mathematically and computationally complex approaches are indeed more informative than the simple ones alluded to in this text. For the text, this involves explaining how this packages’ metrics capture process geomorphology well/better than the status quo (Lines 36-37). For the figures, the comparison figure/table between the R2 and RMSE in age prediction using the metrics in the package and the more “conventional” approaches should feature in the main text rather than the supplement.
[Authors’ response]: We have revised the lines 34-37 to be more explicit about why these newer methods were proposed and used. We also added a table in the Appendix A along with the main text to show a summary of comparison among tested metrics in this paper.
---
My line-by-line comments fulfil some of those tasks:
Line 21: Maybe I'm out of the loop but I am more familiar with roughness than complexity, so maybe start with "roughness" and then say "and we're gonna call that topographic complexity"
[Authors’ response]: We prefer to use “topographic complexity” because it is less ambiguous compared to other terminologies used across various research fields. In recent years, the geomorphology community has commonly used “roughness” to describe the how complexity of a land surface, regardless of the metrics employed. However, there is a well-established metric named “roughness” that directly measures the largest difference between a central pixel and its surrounding cell within a moving search window (Wilson et al., 2007), which often means differently from what has been described in many geomorphic research. This metric has been used in ecological, bathymetric, and engineering research for decades and is one of the measures supported by GDAL in QGIS by default. To avoid confusion and find the most neutral term to describe surface complexity, we prioritize using “topographic complexity” over “topographic roughness” throughout our paper.
---
Line 23: Are “utility and popularity” necessary?
[Authors’ response]: We have removed these words from the manuscript.
---
Line 36-37: “…because they can be more directly connected to process-based geomorphic models.” Provide example or at least a citation?
[Authors’ response]: We have revised the lines 34-38 with citations to clarify our points here.
---
Line 50: I have been chastised in the past for providing imperial units, even when the data were collected in imperial units. Maybe this is a more grave offense in an EGU journal.
[Authors’ response]: Thanks for your comment. This is why, in the pyTopoComplexity, we have included the ability to automatically detect the distance units (in meters or feet) from any input DTM data and conduct unit conversion when necessary. This is also crucial when connecting the topographic complexity measurements with the Landlab simulation. The example input DTM data from the Washington Geological Survey was collected in imperial units, but the Landlab modeling framework and parameters require metric units. The codes and notebooks provided in the pyTopoComplexity and ensure the unit consistency and result reproducibility.
---
Line 53: “users” instead of “researchers” here and throughout (might be students in a course!)
[Authors’ response]: We have replaced “researchers” as “users” throughout the paper.
---
Figure 1: Cartoon! I need a cartoon first! These small multiples are fun but maybe start with a more general schematic of a landscape, ID the different indices, and then give us an example
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: Clarify that the package is not limited to Linux? (the “pip install” command can be executed in Windows, etc)
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options. Furthermore, to run the landlab notebook correctly, we clarify in lines 194-195 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Line 67: Recommend using the phrasing in Line 94 (“2D Ricker or Marr wavelet (i.e., Mexican hat wavelet) function”), or “also called Mexican hat wavelet.” As someone coming across this phrase for the first time it feel colloquial, even if it’s not. Might help non-native English speakers out a bit.
[Authors’ response]: We have revised this sentence following this suggestion (line 69).
---
Lines 90-92: I'm getting a little lost here. I think these two sentences need to be broken up by an example. Then I think the second sentence could use a schematic diagram.
[Authors’ response]: We have revised this sentence following this suggestion (lines 89-91).
---
Line 122: Is there a more recent example of how fractal analysis is crucial for studying surface processes?
[Authors’ response]: We have cited more recent works here (lines 119-122).
---
Line 147: re: Rugosity Index, maybe I'm out of the loop, but I recommend starting off with a definition before giving the examples of its use.
[Authors’ response]: We have reorganized the texts in section 2.3 to clarify the definition of RI first before giving the examples of its use. (lines 150-163)
---
Line 162: Loop this into the introduction - say TI of 1 is flat, and with increasing surface (contoured) are to planimetric area it'll go up, or something like that
[Authors’ response]: We have reorganized the texts in the section 2.3, following this suggestion. (line 153)
---
Lines 165-166: Maybe elaborating on this would help someone who has never used these tools before but is a practitioner of say geohazards or restoration etc.
[Authors’ response]: We have revised the texts in lines 155-156 to better elaborate the difference in conventional RI and ACR-RI, and clarify that users have the option to choose which metric to be calculated in this module.
---
Line 176: What is the difference between "ruggedness" and "roughness"?
[Authors’ response]: This is an great question. Traditionally, “ruggedness” and “roughness” can sometimes be used interchangeably to describe surface complexity. To our knowledge, “ruggedness” tends to emphasize the irregularity of the terrain at larger spatial scales. There is a conventional metric called “Terrain Ruggedness Index,” which is defined differently from the “roughness index” (Shary, 1995; Florinsky, 2017; Wilson et al., 2007). In this paper, we have tested all of these metrics in comparison to the four advanced metrics provided in pyTopoComplexity (lines 286-290, Figs S8-S9). Since using these terms in a general sense can be quite confusing and ambiguous in this manuscript, we have revised this sentence and opted for the most neutral term, “surface complexity”.
---
Section 2.5: I wonder if the description of the Landlab components and defaults belong in the supplement? This being a short communication about your software, perhaps you can save space and cite out this already-published software?
[Authors’ response]: Thanks for the comment. We have significantly simplify the technical details of Landlab and related theoretical frameworks, and only cite necessary references to fit it the short format of this paper. However, we believe the current section 2.5 in this section provide the minimum information required for readers to understand our later case study and simulation tests in section 3 and 4, and thus prefer to put them in the main text.
---
Line 209: "...consistent with the Taylor series expansion"?
[Authors’ response]: We have revised this sentence following this suggestion. (line 199)
---
Line 211: Watch in text citation format
[Authors’ response]: We have corrected the citation format here. (line 208).
---
Lines 269-272: This section is a good example of meaningfully connecting process and morphometry. Do more of this throughout!
[Authors’ response]: Thank you for your kind compliment!
---
Figure 3: Color the points in (b) with the color of the landslide or label the number?
[Authors’ response]: We have updated the color symbols in Fig. 3b following this suggestion.
---
Line 288: When I got to the end of the first paragraph I actually wrote "now show me the performance of traditional metrics!" So I was pleased to see that you did just that! But, I think that means I'd like to see the R2/RMSE metrics of the traditional vs fancy metrics in the main text. The burden of proof lies in the authors to convince geomorphologists and practitioners to adopt their software over things like GRASS, and so I recommend you provide a convincing table to demonstrate that.
[Authors’ response]: In the revised manuscript, we added a table in the Appendix A to show a summary of comparison among tested metrics in this paper.
---
Section 4: I think this section is really solid. Nice work.
[Authors’ response]: We genuinely appreciate your kind words.
---
I am happy to report that I cloned the repo, built the environment, and successfully ran an example notebook with an example DEM as well as a DEM from my own research. All on my Windows laptop in under 20 seconds! Well documented and easy to use. My only small suggestion is to use Pathlib instead of os.path to name files.
[Authors’ response]: It is fantastic to confirm that the codes work on other Windows machines (pyTopoComplexity was initially developed on a MacOS machine). We also appreciate your recommendation to use Pathlib instead of os.path. However, some of the older modules in Landlab simulation models and their tutorial examples use os.path. To maintain internal consistency and avoid potential conflicts when communicating with all Landlab components, the current version of pyTopoComplexity prioritizes using os.path. We plan to switch to Pathlib in future updates once all conflicts are resolved.
=====
Responses to RC2:
General comments
I really enjoyed reading this work and believe it will be relevant and useful to the broader scientific community. The authors’ goal to address the lack of open-source software that facilitates advanced analysis of topographic features is clearly presented. The pyTopoCompelxity toolkit seems to be a resource that will help fill that gap and broaden the accessibility of quantitative topographic analysis.
[Authors’ response]: We appreciate the valuable review provided by reviewer 2!
---
One broad comment is related to the intended audience and schematics. I think that the accessibility of the article (and the toolkit in general) would increase with additional figures or text that demonstrate the utility of each topographic metric. This may be beyond the scope of this work, but including a simple schematic of each of the four topographic metrics that can be measured with the pyTopoComplexity toolkit would be incredibly useful. A figure along these lines could increase your audience as well as make it more likely that someone will utilize this cool resource. In particular, it would really help prepare the readers to look at Figure 2. PyTopoComplexity could help lead to greater incorporation of more rigorous topographic analysis in fields outside of typical Geoscience/Earth Science studies; such as ecological or biological studies.
[Authors’ response]: We’ve redesigned Figure 1 to include a schematic diagram that illustrates pyTopoComplexity’s capabilities and its workflow. We hope this revised Figure 1 will provide a clearer understanding of the tool for audiences from diverse research backgrounds.
---
A second broad comment relates to figures. The figures contain a lot of really good information, but it is a little easy to get lost and difficult to read the axes at times (is there space to increase font sizes?). For figures that contain multiple subplots (within the a and b panels), it might be helpful to add additional labels. For example, a Fig 4a.2, in text citation might help readers go back and forth between the text and figures more easily when you reference specific observations/trends.
[Authors’ response]: We’ve reduced the number of panels and subfigures in Figures 3, 4, and 5 in the main text, as suggested, and enlarge the in-figure texts to enhance clarity. We retained original figures for the complete simulation results and moved them to the revised supplementary materials as Figures S10 and S11, in case readers are interested in these details.
---
Third, I really like the use of a case study. It helps demonstrate how this toolkit can be useful compared to other traditional tools and connect complicated mathematical concepts into the “real world” examples.
[Authors’ response]: Thank you for your kind compliment!
---
Lastly, the authors discuss how to install using Linux, but in reality this can be installed in other ways as well. To increase the applicability and access I would emphasize that those who don’t use linux can also utilize the resources. This could be done briefly in the text and/or the github repository page. I don’t use a linux system right now and I was able to download the zip file from the author’s github repository. Then use the “environment.yml” file to create a new environment with conda prompt on my own machine. I was unable to run the landlab example (see technical note below - maybe something wrong with my own installation), but the other four example notebooks ran smoothly with my own GeoTIFF!
[Authors’ response]: We’ve revised the sentences in lines 60-64 to make it clear that pyTopoComplexity can be installed on Windows, MacOS, and Linux systems, as long as the required Python environment is properly set up. We’ve also added more installation options, like through conda-forge. Furthermore, to run the landlab notebook correctly, we clarify in lines 193-194 that users must install Landlab separately, following Landlab’s installation instructions (https://landlab.readthedocs.io/en/latest/installation.html).
---
Specific comments
Lines 24-29: This is a great list of previous applications of terrain analysis. To further emphasize the point, and similar to your last example, you could include references to the growing literature using topographic metrics and analysis for soil organic matter/carbon and other nutrient dynamic studies.
[Authors’ response]: We’ve included a few words with citations to mention recent applications in soil carbon cycle research (lines 28-29). Thanks for the suggestion.
---
Lines 34 - 37: I agree with this statement, but it should be backed up with a citation if there is an appropriate one. These more rigorous metrics are more connected to process-based geomorphic models, but is there evidence that this demonstrates that they are more effective than conventional metrics?
[Authors’ response]: We have revised the lines 34-38 and added citations accordingly to clarify our points here.
---
Lines 41-42: “... they have been confined to marine bathymetric studies and involve various mathematical limitations, assumptions, and designs.” I interpreted this as the limitations inable use for terrestrial landscapes? It might add clarity to add a few words at the end here if so along the lines of - “bathymetric studies and involve various mathematical limitations, assumptions, and designs that make them not suitable for terrestrial studies”
[Authors’ response]: Thanks for the comment. However, to our knowledge, there is no previous examinations, proof, and discussions about whether Rugosity Index (RI) could be suitable for terrestrial studies, albeit its mathematical definition of RI suggest that it should not work exclusively on bathymetry data. This is part of the reason why we incorporate this metric in our software, allowing marine geology and ecology works to be able to use pyTopoComplexity for their work, but also test the applicability in terrestrial surface complexity analysis in the landslide examples. Our results show that, although not offering the best data predictability, RI can still offer certain degree of geomorphic meanings in terrestrial settings like landslide-prone terrains.
---
Figure 1: I like the idea and the inclusion of figure 1 because it is helpful to see two scales for each module method. However, from a visual perspective, I think it could be helpful to add a little more space between the bottom two modules and the top two modules. Additionally, the axis labels could benefit from being larger (a little difficult to read).
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
I think it would be helpful to include an annotated schematic of each of these topographic metrics on a simple landscape. Maybe even before the presentation of this first figure. This would help convince people who are less familiar with the metrics (or even those who are) of their utility. Since figure 1 is a little complicated, a simpler schematic presented first would also prepare people to digest figure 1.
[Authors’ response]: We’ve redesigned Figure 1 with a schematic diagram to address this comment.
---
Line 63: I would suggest including the fact that one could access the pyTopoComplexity package from the Lead Author’s github page and a Zenodo link. Although Linux may be an easy way to install and use for many researchers, the fact one could access the code from other sources is a perk. I downloaded and installed the environment with the .yml file in the conda prompt (but also maybe this is why I had an issue with the landlab notebook?).
[Authors’ response]: Please refer to my response to a similar suggestion made by reviewer 2 in their last general comment. As we have revised relevant texts (lines 60-64) and included more installation options like conda-forge.
---
Line 67: I believe the term Ricker wavelet is synonymous with the Mexican hat wavelet. Is there a reason for choosing one name over the other? *I see now on line 93 you say “Ricker or Marr wavelet (i.e., Mexican hat wavelet)...” I would bring this up to line 67 and then stick with Ricker through the rest of the text (and Table 1). Although this might mean you would have to change the name of your python scripts as well if you choose to go that route.
[Authors’ response]: We’ve revised these sentences based on this suggestion (lines 69 and 91). We maintain the consistent usage of the “Mexican hat” wavelet in accordance with other landslide research publications we extensively discuss in the subsequent sections, such as Booth et al. (2017)
---
Line 68: small comment that might add clarity “for the Mexican hat wavelet in 2D-CWT analysis or the size of the moving window (Δ) for the other three methods"
[Authors’ response]: We have revised this sentence to improve the clarity (lines 68-69).
---
Line 69: Nothing to change, but just an appreciation comment. This automatic conversion to maintain consistency is really great and will help out if/when I will use this tool for an undergraduate introductory class!
[Authors’ response]: We really appreciate your kind words.
---
Lines 91 - 93: I like how you explain what an increase/decrease in these values mean in the physical world (larger s means you are capturing larger scale features while smaller s values mean you are capturing smaller scale landscape features). This could be done to a greater extent for the FD analysis.
[Authors’ response]: Thanks for your comment. For the fractal dimension (FD) analysis, we have revised the explanation of the possible meanings of fractal dimension in landscape measurements. (Lines 119-123)
---
Line 105: do you see different final results depending on the use of “fftconvolve” versus “convolve2d”? And if so, how big of a difference?
[Authors’ response]: There’s no discernible difference in the results when using high-resolution Lidar data. In our case studies and subsequent simulation experiments, we focus on the average values of the 2D-CWT curvature measurements within mapped landslide polygons, which don’t reveal any noticeable difference across two methods. Notably, using the slower “convolve2d” function offers an advantage. It can still produce results even when the input DTM raster file is partially damaged (with unexpected extreme values or NaN grids) or incorrectly projected. In contrast, the ‘fftconvolve’ package will terminate execution with an error message in such cases. Although we didn’t delve into these technical details in the manuscript, we’ve addressed this situation in the markdowns/documentations to inform users within the Example_pycwtmexhat.ipynb
---
Line 119: I am a little lost in your discussion of Fractal dimension analysis. I am less familiar with the calculator of this metric. It could be helpful to add a brief sentence or two saying what values of this mean in the “real world” like you do for the other metrics. For example, as FD increases, do we see more or less similarity across the landscape?
[Authors’ response]: We’ve revised the explanation of the possible meanings of fractal dimension in landscape measurements (lines 119-123).
---
Line 124 - 127: Since I am less familiar with this method and metric, does how you have adapted the variogram method change what results you see? Maybe this is a naive question.
[Authors’ response]: Unfortunately, we currently lack the knowledge to provide a definitive answer. The pyTopoComplexity package has not delved into exploring other more sophisticated methods for estimating fractal dimension. The variogram method is widely regarded as one of the most computationally efficient approaches to approximate fractal dimension for DTM data (Taud and Parrot, 2005). In this regard, we adhere to the methods and logical design outlined by Pardo-Igúzquiza and Dowd (2022).
---
Line 144: What population of values does pyfracd.py calculate the standard error and coefficient of determination of? Within a cell? Across the whole landscape?
[Authors’ response]: The population is calculated within the moving window, so it depends on the size of the window defined by the users.
---
Line 165: the pyTopoComplexity toolkit can calculate both the RI and the ACR-RI, correct? It might be helpful to explicitly reiterate that.
[Authors’ response]: We have clarified this functionality in the revised manuscript (line 159).
---
Line 166: Citation for “could provide a better representation of local surface complexity because it is not biased by slope.”
[Authors’ response]: As we’ve reorganized the text in this section 2.3, we believe it would be clearer if we included a citation to Du Preez (2015) in the relevant lines (150-159).
---
Line 204 - 205: A little unclear what this sentence is saying. Are you redefining or are you saying where those two values are equal it “represents the vector of topographic…”
[Authors’ response]: We removed “, where” to improve the clarity of this sentence. (line 201).
---
Line 205: To clarify, Shd and Sc are simply gradient values or are they the magnitude of slope? Does the magnitude of slope refer to something else here? If it is not just hillslope gradient, it might help to clarify that.
[Authors’ response]: You are correct about S_hd and S_c. We have included a notation list in the Appendix B to clarify them.
---
Figure 2: I really like this example to demonstrate the landlab implementation of the pyTopoComplexity toolkit.
[Authors’ response]: Thank you so much!
---
Line 240: citation for published NFSR valley landslide inventory?
[Authors’ response]: Citation added. (line 251)
---
Line 243-244: Did you exclude these areas in your analysis or did Booth et al. (2017) exclude them from their analysis? I think your analysis, but clarification would be helpful.
[Authors’ response]: Booth et al. (2017) excluded them as well. We revised this sentence to clarify it. (line 254)
---
Line 249: Can you include the age of your oldest landslide directly in the text? It is in the figures/supplement, but would be helpful to have directly here.
[Authors’ response]: Age values added. (Line 261)
---
Line 250: Do you set a threshold to define “low RMSE”?
[Authors’ response]: The ranges of the RMSE values differ for various metrics. Therefore, we can only determine the optimal spatial scale with “relatively low” RMSE values in each method. This clarification is provided in line 262.
---
Line 256-257: Is this what you expected?/Does this make sense when we think about real world context, what we know about processes, and what these metrics represent?
[Authors’ response]: The surprising similarity in good predictability between 2D-CWT and TPI was a revelation to us as we delved deeper into its analysis. We have offered some potential explanations for this phenomenon (lines 269-280) and subsequently highlighted why we prefer 2D-CWT over TPI in later analysis because 2D-CWT possesses a unique ability to isolate complex signals at various spatial scales, which holds significant implications for real-world applications (lines 298-309).
---
Line 268 - 272: This addresses my previous comment (line 256-257)! I like this. I think it really helps put what your toolkit can measure in real world context and why someone might choose one metric over another.
[Authors’ response]: We appreciate your valuable feedback!
---
Line 290-291: Perhaps I missed it somewhere but do you have all the R2 and RMSE values for this comparison somewhere in a table? If so, please reference it here.
[Authors’ response]: These details of R^2 and RMSE for each method measuring at each spatial scale are shown in the supplementary figures. In the revised manuscript, we added a new table as Appendix A to show the overall R^2 RMSE range for every method tested in this paper.
---
Line 352 - 362: I really like this real world application and thoughts about spatial scale variability. Figure 4 has a lot of information and I found myself getting a little lost going between the text and the figure. It could be helpful to have figure 4a.1 - 4a.10 or something like that. So when you say “For a given D, the non-linear diffusion model tends to underpredict the reduction rate of surface complexity during the early stages of landscape recovery following a catastrophic landslide.“ you could reference a specific subplot in the bigger figure. It would help the reader process your conclusions.
[Authors’ response]: We have added labels to each subplots in the updated Figs. 4 and 5, and cite them accordingly in the main text.
---
Line 374 - 376: At what time scale would you expect tree throw to occur and be relevant again? Decades? Centuries?
[Authors’ response]: According to the discussion within Roering et al. (2010), it is likely to be within decadal timeframe. We have included this information in the revised text. (lines 501-502)
---
Technical comments
I had some issues with running the landlab simulation notebook. It could be related to me installing pyTopoComplexity in conda with the environment.yml file? Side note - this warning started to show up; “DeprecationWarning: landlab.io.read_esri_ascii has been deprecated, use landlab.io.esri_ascii.load instead”.
[Authors’ response]: The issue is likely due to incomplete or incorrect installation of the Landlab. We have clarified that users for this notebook need to install Landlab separately following Landlab’s own installation instructions. (lines 193-194).
---
The example script “Example_pyfracd.ipnb” worked with my own imported .tif file, but not the example DEM provided. There was a "ZeroDivisionError: division by zero” error. Perhaps again, this is an issue with my installation. The other three example notebooks worked with the example DEM though.
[Authors’ response]: We have re-tested the codes on both MacOS and Windows, and can’t not replicate this error. This is very likely caused by incorrect installation or incomplete python environment set up. We have include more instructions with additional installation option through conda-forge. Since it sounds like reviewer 2 can exclude conda commands, and we hope the new installation using ‘conda install’ can resolve this issue.
---
Again, I enjoyed reading this work and think it has the potential for wide use across multiple fields of study (beyond geomorphology). I look forward to trying to incorporate it into future courses.
[Authors’ response]: Thank you once more for your very helpful review. If you encounter any issues or wish for additional functionalities in future updates that could be beneficial to your teaching, please don’t hesitate to contact us.
=====
Other additional revisions:
Line 1: Remove “s” out of the “Communication” from title to match the article type.
Lines 86-98: Minor reorganization made to improve clarity about parameters and equations.
Line 303: Include the unit of diffusivity parameter D
Line 236-248: Provide a more detailed introduction to this section, exploring the background and significance of topographic complexity analysis in geohazard assessment. This could potentially attract more attention from hazard practitioners.
Lines 478-479: Add the source of the example Lidar DTM data.
Citation: https://doi.org/10.5194/egusphere-2024-3415-AC1
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 233 | 96 | 9 | 338 | 30 | 6 | 7 |
- HTML: 233
- PDF: 96
- XML: 9
- Total: 338
- Supplement: 30
- BibTeX: 6
- EndNote: 7
Viewed (geographical distribution)
| Country | # | Views | % |
|---|---|---|---|
| United States of America | 1 | 151 | 46 |
| China | 2 | 28 | 8 |
| Germany | 3 | 24 | 7 |
| France | 4 | 19 | 5 |
| Brazil | 5 | 11 | 3 |
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
- 151