A Hierarchical Matching Method for Vectorial Road Networks Using Delaunay Triangulation

Round 1

Reviewer 1 Report

The paper is well written, presented and contributes to the body of knowledge. The methodology has the potential to be applied to other urban sectors for infrastructure applications with sector oriented modifications. 

Author Response

We sincerely thank you for your helpful comments.

[Point 1]: The paper is ell written, presented and contributes to the body of knowledge. The methodology has the potential to be applied to other urban sectors for infrastructure applications with sector oriented modifications.

[Response 1]: With much appreciation, my coauthors and I sincerely thank you for the comments and suggestions.

Author Response File: Author Response.pdf

Reviewer 2 Report

The authors propose a novel framework to match the hierarchical urban road networks, and the results (in terms of accuracy) seem promising. Although this paper is timely and methodologically sound, it can be improved in the following fronts.

• As generating a hierarchical road network is a starting point of the proposed method, the authors should justify their “hierarchical generation process” in more details. It would be great to find a visualized example of the three-layer system in e.g., Figure 2. Furthermore, the authors should clarify whether the changes in the classification threshold of a road network will lead to different matching results.

• Although the proposed method DTRM has a higher accuracy rate than the benchmark method PRM in general, there still exists some samples (2 out of the 8 case study areas, as indicated in Figure 17) yielding worse results by using DTRM. The authors should state the potential reasons for the lower performance.

• The authors conducted the sensitivity analysis of the buffer threshold (in section 3.6). However, it seems that rotation is not considered in testing the impact of buffer size on estimation accuracy. As the authors claim that “the Euclidean distance between features with the same name also changes with the rotation”, they should clarify why the rotation impacts are not examined in the sensitivity analysis.

• More background information on the experimental areas should be introduced. Why are the two selected cases representative? Do they represent all types of road networks? If not, what are their limitations? Will there be any potential biases using the selected cases? The authors need to justify the case representativeness in more details.

• Despite a rigorous framework proposed in this research, this paper fails to engage with the wider readership of the journal. The authors should emphasize the potential application of their approach in the areas of e.g., transport modeling, urban planning, and public management. Suggest reading, for instance, https://0-journals-sagepub-com.brum.beds.ac.uk/doi/10.1068/b306; http://joss.bartlett.ucl.ac.uk/journal/index.php/joss/article/view/255; https://0-link-springer-com.brum.beds.ac.uk/article/10.1007/s11067-018-9427-9; and https://0-journals-sagepub-com.brum.beds.ac.uk/doi/abs/10.1177/2399808320924433.

• An English language editing is suggested (e.g., in line 100: “fuses” rather than “fusions”). I recommend the authors inviting a native speaker to proofread the manuscript.

Author Response

We sincerely thank you for your helpful comments, which have helped us clarify many points and improve the paper. In what follows, we describe in greater detail how the revised paper has addressed your comments.

[Point 1]: The authors propose a novel framework to match the hierarchical urban road networks, and the results (in terms of accuracy) seem promising. Although this paper is timely and methodologically sound, it can be improved in the following fronts.

[Response 1]: Thank you for your suggestions and comments.

[Point 2]: As generating a hierarchical road network is a starting point of the proposed method, the authors should justify their “hierarchical generation process” in more details. It would be great to find a visualized example of the three-layer system in e.g., Figure 2. Furthermore, the authors should clarify whether the changes in the classification threshold of a road network will lead to different matching results.

[Response 2]: Thank you for your valuable comments. To illustrate the hierarchical generation process of the road network more clearly, we have complemented Figure 2 to show a three-layer road network. As shown in Figure 2, according to the principle of hierarchical generation, an example of an urban road network is first divided into four subregions which form L1. Then, for the upper-right subregion in L1, the road network of L2 and L3 generated from the source road network and the target road network are illustrated, respectively. The difference between the source road network and the target road network is subtle for L1, moderate for L2, and obvious for L3. This part has been added to the end of Section 2.2 (See lines 172-180).

Besides, the changes in the classification threshold of a road network may lead to different matching results. We fully agree with you on this point. To confirm the rationality of our stratification, Dr and HitRate are used to evaluate the difference distribution of the target matched strokes and the potential candidate strokes in L1 under different stratification proportions. Section 4.2 has been complemented to explain how the stratification threshold is selected. (See lines 682-727).

[Point 3]: Although the proposed method DTRM has a higher accuracy rate than the benchmark method PRM in general, there still exists some samples (2 out of the 8 case study areas, as indicated in Figure 17) yielding worse results by using DTRM. The authors should state the potential reasons for the lower performance.

[Response 3]: Thank you for your valuable comments. We have analyzed the potential causes that affect performance. Figure 31 (d) and Figure 32 (b) show that the error matches (red lines) are mainly distributed in the nongrid area of narrow areas. The reason for the precision decrease of the two cases could be explained as follows: For such narrow areas, the matching relationship established in L1 is limited. In the complex hybrid road matching, there are gaps between the pattern parameters. While the hybrid street pattern needs to be handled at the boundary between different street patterns. Such operation may affect the accuracy of matching and is one of the limitations of the proposed method in this study. During this type of operation, the trade-off between the upper level matched relationship (i.e., L2) and the similarity of this layer (i.e., L3) needs to be further studied. The analysis has been added to the revised paper in Section 3.3(lines 483-491).

[Point 4]: The authors conducted the sensitivity analysis of the buffer threshold (in section 3.6). However, it seems that rotation is not considered in testing the impact of buffer size on estimation accuracy. As the authors claim that “the Euclidean distance between features with the same name also changes with the rotation”, they should clarify why the rotation impacts are not examined in the sensitivity analysis.

[Response 4]: Thank you for your valuable comments. In section 3.6, the effect of buffer size on the matching performance of PRM and DTRM under different rotation angles is compared. Figure 28 shows the precision and recall of PRM and DTRM with different buffer sizes and rotation angles. According to the experimental results, we clarify how the rotation angle and buffer radius affect the two methods. This part has been added in Section 3.6 (lines 615-629).

[Point 5]: More background information on the experimental areas should be introduced. Why are the two selected cases representative? Do they represent all types of road networks? If not, what are their limitations? Will there be any potential biases using the selected cases? The authors need to justify the case representativeness in more details.

[Response 5]: Thanks for your valuable comment. Regarding the principles of choosing experimental areas, the first consideration is scale. Thus, the datasets with the same scales and different scales are chosen. Different scales may cause a big difference in the basic matching unit-MMU and thus bring certain challenges to the matching algorithm. The second consideration is the representative of the street pattern. The street patterns of all the experimental subregions are examined. The patterns of urban streets are the result of many interacting phenomena over time, such as geography, natural setting, socio-economic transformation, and so on. In this process, several typical street patterns are gradually formed: grid-like (planned) street networks, irregular (self-evolved) street networks, and hybrid street networks (planned and self-evolved structures coexist). According to the three typical street patterns, R1, R2, R3, and R4 belong to irregular (self-evolved) street networks; R5 and R7 are mainly grid-like (planned) street networks, while R6 and R8 are mainly hybrid street networks. The eight subregions cover three typical patterns of urban streets and therefore the effectiveness of our proposed model can also be examined from the perspective of the street pattern. Also, Figure 16 shows the eight experimental subregions that are added to observe the pattern of each subregion intuitively and clearly. These changes have been added in Section 3.1 in the revised version (lines 407-422).

[Point 6]: Despite a rigorous framework proposed in this research, this paper fails to engage with the wider readership of the journal. The authors should emphasize the potential application of their approach in the areas of e.g., transport modeling, urban planning, and public management. Suggest reading, for instance, https://0-journals-sagepub-com.brum.beds.ac.uk/doi/10.1068/b306; http://joss.bartlett.ucl.ac.uk/journal/index.php/joss/article/view/255; https://0-link-springer-com.brum.beds.ac.uk/article/10.1007/s11067-018-9427-9; and https://0-journals-sagepub-com.brum.beds.ac.uk/doi/abs/10.1177/2399808320924433.

[Response 6]: Thanks for your comment. To clarify the application of the study, a wider background and its application are given in the first paragraph and the last paragraph as below.

“Geospatial data matching that connects different data sets and makes them interoperable has a wide range of applications in the spatial analysis due to the need to utilize information from different data sources [1]. On the one hand, large amounts of various geospatial data can be easily obtained from federal, state, and local governments or private companies. On the other hand, identifying corresponding objects is an essential step in change detection and continuous incremental updating. Thus, new features can easily be detected and heterogeneous data sets can be integrated into an enriched product by improving positional or semantic accuracies [2].”

“The model developed in this study is suitable for the integration and update of urban road networks and their applications in navigation systems. The methodology also has the potential to be applied to other urban sectors for infrastructure applications with sector-oriented modifications, such as public management [29], urban planning [30-31] and transport modeling [32].”

[Point 7]: An English language editing is suggested (e.g., in line 100: “fuses” rather than “fusions”). I recommend the authors inviting a native speaker to proofread the manuscript.

[Response 7]: Thank you for your suggestions and comments. We have fixed it. To improve the quality of the English and the writing of this paper, it has been polished by a professional retouching agency.

Author Response File: Author Response.pdf

Reviewer 3 Report

1. Original Submission

1.1. Recommendation

Major Revision

2. Comments to Author

Ms. Ref. No.: ijgi-863039

Title: Hierarchical urban road-network matching method using Delaunay triangulation

Zejun Zuo, Lin Yang, Xiaoya An, Wenjie Zhen, Haoyue Qian, and Songling Dai

Overview and General Recommendation:

I liked the structure in the end of the intro with paragraphs for “our research, our contribution, and paper organization.” I believe the paper is of interest for this journal. That said, I have some concerns and comments that need to be addressed before any recommendation to accept this paper can be made. Especially, my comments below regarding the issues of metrics and their phrasings will need to be incorporated for the entire paper.

For all my comments below, please accept them as suggestions on how to increase the impact of your work. Feel free to dispute me where you see fit.

Major comments:

1. Please adopt a funnel approach in the introduction to start with a broader context. As an easy fix, maybe a paragraph could be added to the beginning of the intro as a generic intro to the subject of this paper.
2. Section 3.2: The evaluation indices are problematic. Firstly, please rephrase your expressions and descriptions to make sure it abides by the well-established data science jargon. For example, what you call “matching accuracy” is actually precision. Accuracy is the ratio of all correctly predicted true positive or negatives to everything. Also, phrases like “correct matching accuracy” are awkward, please rephrase.
   1. No need for “* 100%” at the end; the formula is already a ratio.
   2. I don’t understand the “AM”. What are these ambiguous features that are not possible to match with a software? Who decided that’s not possible? And if the program cannot match those, why do you include it in the precision? As you know, precision is the ratio for (correct positive predictions/all positive predictions). Something doesn’t add up here.
3. A suggestion: you can use F-1 score to provide a single metric that will combine precision and recall to show the real success of your model in comparison to PRM. Maybe Figure 16 can be done for F-1 score instead of precision.
4. The accuracy growth rate (which is actually the precision g. rate) is not an established metric at all. If it is, please cite it. If you propose it, then state that along with why this was needed. It seems like you are just quantifying the change in precision as a percentage of the PRM’s precision. There is nothing wrong with that, but I think it’s pointless, even misleading. Because:
   1. Precision alone is not a measure of your success. In fact, you can usually maximize precision by sacrificing recall. So your AGR is not a convincing argument without looking at your recall, which renders AGR unnecessary.

My suggestion is to either completely remove AGR, or add a new column for F1 score, and then simply report that difference in F1 scores of DTRM and PRM in the last column. And for figure 17, just chart that difference of F1s.

5. Table 5: For R6, the AGR is wrong, it should be -2.13%, not positive.
6. In Figure 16, and section 3.3 in general, your area definition is vague. From what I understand, you had three areas. First one is intact, second one is divided into 4 (r1,..r4), and third one divided into three (r5,…,r7). However, starting from Figure 16, you start referring the total of these as Area 1, 2, 3, …, 8. And you never explained how they correspond: e.g. R1 corresponds to Area 2. This is seriously problematic, please update the whole phrasing.
7. In Line 381, you mention the computer specs for the experiment. Since you didn’t reported anything like runtime, this shouldn’t be that important, however, I still cannot help but wonder why do you have a GTX 960 with a Pentium and an 3.5 gb RAM? Is there a reason you have such powerful GPU (compared to rest of the hardware) for your code? E.g. have you written any part of the code to run on the GPU? Also, 3.5 gb ram is really low for Visual Studio development. No changes needed for this (if your spec is actually accurate), but it just seems weird.
8. Can you publish the datasets you used in this study? If not, please tell why.
9. How did you test your datasets with PRM? Did you implement the algorithm yourselves, or was there an available third party application for that?
10. That PRM study goes back to 2011. Haven’t there been any recent work for point feature matching that you can compare your findings with?

Minor comments:

1. Figure 1 definitely requires some formatting visually. The content is alright, but the styling are problematic. Symmetry, spacing, etc.
2. L141: No need for new paragraph. Just merge L141 and L142.
3. Table 2: Please write the column titles explicitly; no need for abbreviations like NS, NN, etc. There is plenty of space.
4. L428: Space needed between Area2 and Area3, wherever else it applies.
5. Tables 3-4-5 and others: Please divide the columns to make the distinction clear.
6. If possible, please provide a professional email address from your organization for correspondance.

Author Response

We sincerely thank you for your helpful comments, which have helped us clarify many points and improve the paper. In what follows, we describe in greater detail how the revised paper has addressed your comments.

[Point 1]: Please adopt a funnel approach in the introduction to start with a broader context. As an easy fix, maybe a paragraph could be added to the beginning of the intro as a generic intro to the subject of this paper.

[Response 1]: Thanks for your suggestion. In the revised version, the introduction begins with a wider background of geospatial data matching and its applications. The paragraph of

“Geospatial data matching that connects different data sets and makes them interoperable has a wide range of applications in the spatial analysis due to the need to utilize information from different data sources. On the one hand, large amounts of various geospatial data can be easily obtained from federal, state, and local governments or private companies. On the other hand, identifying corresponding objects is an essential step in change detection and continuous incremental updating. Thus, new features can easily be detected and heterogeneous data sets can be integrated into an enriched product by improving positional or semantic accuracies.” has been added in the revised manuscript.

[Point 2]: Section 3.2: The evaluation indices are problematic. Firstly, please rephrase your expressions and descriptions to make sure it abides by the well-established data science jargon. For example, what you call “matching accuracy” is actually precision. Accuracy is the ratio of all correctly predicted true positive or negatives to everything. Also, phrases like “correct matching accuracy” are awkward, please rephrase.

• No need for “* 100%” at the end; the formula is already a ratio.
• I don’t understand the “AM”. What are these ambiguous features that are not possible to match with a software? Who decided that’s not possible? And if the program cannot match those, why do you include it in the precision? As you know, precision is the ratio for (correct positive predictions/all positive predictions). Something doesn’t add up here.

[Response 2]: Thanks very much for pointing this out. Formula 11 in the previous version refers to Formula 13 in the paper of “Bisheng Yang, Yunfei Zhang & Xuechen Luan (2013): A probabilistic relaxation approach for matching road networks, International Journal of Geographical Information Science, 27:2, 319-338”. The parameters of TP, FP, and FN are obtained by the comparison between the results obtained by our method and those from manual matching. “AM” indicates some ambiguous cases that can barely be judged by human inspection. In Yang et al., 2013’work, “AM” is included in calculating precision because this part is disjoint from TP and FP. We have also checked the expressions of evaluation indicators in other several papers on the topic of road network matching (Song, et al.,2011; Tong, et al., 2014; Safra et al., 2013). Precision represents the matching accuracy in object matching. It is defined as the percentage of correctly matched pairs concerning the total number of matched pairs. It is determined by the TP (true positive) which stands for the number of road pairs that are correctly matched and FP (false positive) which stands for the number of road pairs that are incorrectly matched.

On the one hand, in our cases, the matching relationship in the test areas can be identified through human inspection, which means the value of AM is zero. On the other hand, to follow the well-established data science jargon, the expressions and descriptions of “Precision” and “Recall” are rephrased in the revised version, and “AM” has been removed. Since matching accuracy is defined as precision, “precision” is used instead of “matching accuracy” in the revised text. The “* 100%” at the end of Formula 11 and Formula 12 have been removed in the revised version. These changes have been updated in Section 3.2 in the revised version.

[Point 3]: A suggestion: you can use F-1 score to provide a single metric that will combine precision and recall to show the real success of your model in comparison to PRM. Maybe Figure 16 can be done for F-1 score instead of precision.

[Response 3]: Thank you for your valuable suggestion. We have added the index of F1-score to combine precision and recall, and added new column of F1-score in Table 3, Table 4, and Table 5. The comparison of F1-score between DTRM and PRM is also illustrated in Figure 16 instead of precision. The discussion of precision has also been revised to the discussion of F1-score. These changes have been updated in Section 3.3 in the revised version.

[Point 4]: The accuracy growth rate (which is actually the precision g. rate) is not an established metric at all. If it is, please cite it. If you propose it, then state that along with why this was needed. It seems like you are just quantifying the change in precision as a percentage of the PRM’s precision. There is nothing wrong with that, but I think it’s pointless, even misleading. Because:

(1) Precision alone is not a measure of your success. In fact, you can usually maximize precision by sacrificing recall. So your AGR is not a convincing argument without looking at your recall, which renders AGR unnecessary.

(2) My suggestion is to either completely remove AGR, or add a new column for F1 score, and then simply report that difference in F1 scores of DTRM and PRM in the last column. And for figure 17, just chart that difference of F1s.

[Response 4]: Thank you for your valuable comments. The index of AGR has been removed from Section 3.2 and the column of AGR has been removed from Table 3, Table 4, and Table 5. We have added a new column for F1-score in Table 3, Table 4, and Table 5. The difference in F1 of DTRM and PRM has been charted in Figure 17 to replace AGR values. The discussions of F1 difference have also been added as well in Section 3.3.

[Point 5]: Table 5: For R6, the AGR is wrong, it should be -2.13%, not positive.

[Response 5]: Thanks for pointing this out. The column of AGR has been removed from Table 3, Table 4, and Table 5.

[Point 6]: In Figure 16, and section 3.3 in general, your area definition is vague. From what I understand, you had three areas. First one is intact, second one is divided into 4 (r1,..r4), and third one divided into three (r5,…,r7). However, starting from Figure 16, you start referring the total of these as Area 1, 2, 3, …, 8. And you never explained how they correspond: e.g. R1 corresponds to Area 2. This is seriously problematic, please update the whole phrasing.

[Response 6]: Thanks for your valuable comment. To better establish the corresponding relationship between the eight subregions and the number on the horizontal axis. In the revised version, Area 1 is numbered as R1. Area 2 is divided into four subregions, numbered as R2, R3, R4, and R5. Area 3 is divided into three subregions, numbered as R6, R7, and R8. Therefore, the number on the horizontal axis corresponds to eight subregions (from R1 to R8). The following text (Section 3.2, Section 3.3, Section 3.4, Section 3.5, and Appendix) that references these subregions strictly use terms (R1-R8) to ensure the clarity and consistency of the paper. These changes have been made in the revised version (lines 413-418).

[Point 7]: In Line 381, you mention the computer specs for the experiment. Since you didn’t reported anything like runtime, this shouldn’t be that important, however, I still cannot help but wonder why do you have a GTX 960 with a Pentium and an 3.5 gb RAM? Is there a reason you have such powerful GPU (compared to rest of the hardware) for your code? E.g. have you written any part of the code to run on the GPU? Also, 3.5 gb ram is really low for Visual Studio development. No changes needed for this (if your spec is actually accurate), but it just seems weird.

[Response 7]: Thanks for your comment. This is because our team has done a work of a parallel road-network matching (Bo Wan, Lin Yang*, Shunping Zhou, Run Wang, Dezhi Wang, and Wenjie Zhen. A Parallel-Computing Approach for Vector Road-Network Matching Using GPU Architecture. International Journal of Geo-Information, 2018, 7, 472). Thus, this experiment has also been conducted on the same computer.

[Point 8]: Can you publish the datasets you used in this study? If not, please tell why.

[Response 8]: Thanks for your valuable comment. The datasets we used in this study can be published. The link is “https://figshare.com/s/1f8f6ce647f5cbfa2914”.

[Point 9]: How did you test your datasets with PRM? Did you implement the algorithm yourselves, or was there an available third party application for that?

[Response 9]: Thanks for your valuable comment. The author of PRM has not published the source code of the algorithm but provided the pseudo-code. Thus, PRM has been implemented using the C++ programming language by ourselves. Its software-development environment is composed of Visual Studio 2010 and MapGIS 10 (Zondy, Wuhan, Hubei, China). To ensure fairness, the development environment, the test datasets, and the test computer of PRM are the same as DTRM.

[Point 10]: That PRM study goes back to 2011. Haven’t there been any recent work for point feature matching that you can compare your findings with?

[Response 10]: Thank you for your comment.

The works for matching road networks with different coordinate systems are summarized in the fifth paragraph of Introduction. The list of studies later than 2011 is as follows:

Luan, X. In A structure-based approach for matching road junctions with different coordinate systems. Proceedings of the Twenty-second ISPRS Congress, Melbourne, Australia, 2012; Melbourne, Australia, 41-46.

Siriba, D.N.; Dalyot, S. Automatic georeferencing of non-geospatially referenced provisional cadastral maps. Survey Review, 2012, 44, 142-152.

Yang, B.; Luan, X.; Zhang, Y. A pattern-based approach for matching nodes in heterogeneous urban road networks. Trans. in GIS, 2014, 18, 718-739.

Among them, the method proposed by Yang et al. (2014) that also considered the problem of uneven deviation caused by different coordinate systems is representative and worthy of comparison. However, the source code has not been released publicly and the methodological process is relatively cumbersome. Indeed, the openness of the source code in GIS academia is not as good as in computer science. Limited by this actual situation, we did not compare our experimental results with Yang’s work. However, from the principle the method, Yang’s method and our method are common in using a hierarchical matching framework, but different in the backbone matching unit embedded in the framework. A pattern-based node group acts as the backbone matching unit in Yang’s method, in which the corresponding control points between blocks strategy is employed. Whereas, MMU acts as the backbone matching unit of our proposed method and its similarity is based on the angle vectors under node/arc constraints. Compared with Yang’s method, the MMU similarity of our method has advantages in suppressing the influence of local distance deviation or rotation angle. Yang’s method has disadvantages in processing a matching task that includes missing road segments in the hierarchical boundary, and the distance threshold obtained by using M-estimation may bring considerable uncertainty to the accuracy of the matching. However, our method considers both the hierarchical transfer matching and independent matching of the MMU, and the matching perform robustly when encountering missing road segments.

Another representative algorithm is the probability-relaxation-matching algorithm (PRM), which is very widely employed in road network matching studies in recent years (Song et al., 2011; Yang et al., 2015; Zhao et al., 2010; Zhang et al., 2012; Zhang et al., 2018 and Yang et al., 2013). Thus, as one of the representative algorithms, PRM is adopted as the baseline method. In Song et al., 2011’s study, the pseudo-code is provided. Therefore, the PRM algorithm was implemented under the same experimental environment as our algorithm in this study. The evaluation of algorithm performance, the rotation test on the basic matching unit and entire road network have been fully compared between the two methods.

The list of papers using the framework of probability-relaxation-matching algorithm is as follows:

Song, W.; Keller, J.M.; Haithcoat, T.L.; Davis, C.H. Relaxation—Based point feature matching for vector map conflation. Trans. GIS 2011, 15, 43–60.

Yang, L.; Wan, B.; Wang, R.; Zuo, Z.; An, X. Matching road network based on the structural relationship constraint of hierarchical strokes. Geomat. Inf. Sci. Wuhan Univ. 2015, 40, 1661–1668.

Zhao, D.; Sheng, Y. Research on automatic matching of vector road networks based on global optimization. Acta Geod. Cartogr. Sin. 2010, 39, 416–421.

Zhang, Y.; Yang, B.; Luan, X. Automated matching crowdsourcing road networks using probabilistic relaxation. Acta Geod. Cartogr. Sin. 2012, 41, 933–939.

Zhang, J.;Wang, Y.; Zhao,W. An improved probabilistic relaxation method for matching multi-scale road networks. Int. J. Dig. Earth 2018, 11, 1–21.

Yang, B.; Zhang, Y.; Luan, X. A probabilistic relaxation approach for matching road networks. Int. J. Geogr. Inf. Sci. 2013, 27, 319–338.

Minor comments:

[Point 11]: Figure 1 definitely requires some formatting visually. The content is alright, but the styling are problematic. Symmetry, spacing, etc.

[Response 11]: Thank you for your suggestions and comments. We have checked the format and style of Figure 1 and re-drawn it in the revised paper.

[Point 12]: L141: No need for new paragraph. Just merge L141 and L142.

[Response 12]: Thanks for your comments. L141 and L142 have been merged. Besides, we have checked all the paragraphs and merged some short paragraphs into one paragraph in the revised paper.

[Point 13]: Table 2: Please write the column titles explicitly; no need for abbreviations like NS, NN, etc. There is plenty of space.

[Response 13]: Thank you for your suggestions. We have rewritten the column titles of Table 2 in the revised paper.

[Point 14]: L428: Space needed between Area2 and Area3, wherever else it applies.

[Response 14]: Thanks for pointing this out. Space between Area2 and Area3 has been added and we have checked the format of the full text and fixed them.

[Point 15]: Tables 3-4-5 and others: Please divide the columns to make the distinction clear.

[Response 15]: Thank you for your comments. We have adjusted the style of columns in all the tables to make the distinction clear.

[Point 16]: If possible, please provide a professional email address from your organization for correspondence.

[Response 16]: Thank you for your suggestions. I have provided my organizational email to the editor and changed the information in the system.

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

The manuscript has been greatly improved - all my concerns have been well addressed by the authors. 

Author Response

With much appreciation, my coauthors and I sincerely thank you for the comments and suggestions.

Reviewer 3 Report

Thank you to authors for employing my suggestions. Recommending for acceptance...

Just one request: please add the DOI or URL for your figshare repository in the article so that the readers can access it. If you think figshare cannot maintain the code for a long time, consider uploading your data to this submission as a supplementary data.

It is important for readers to always have access to your data.

Author Response

We sincerely thank you for your helpful comments, which have helped us clarify many points and improve the paper.

[Point 1]: Thank you to authors for employing my suggestions. Recommending for acceptance...

Just one request: please add the DOI or URL for your figshare repository in the article so that the readers can access it. If you think figshare cannot maintain the code for a long time, consider uploading your data to this submission as a supplementary data.

It is important for readers to always have access to your data.

[Response 1]: Thank you for your suggestions.

We have added the “Data and codes availability statement” before Acknowledgments in the revised paper so that the readers can access it (lines 709-711).

The statement is “The data and code that support the findings of this study are available in the OneDrive repository with the identifier(s) at the private link https://figshare.com/s/1f8f6ce647f5cbfa2914.”