Reviews and Responses for Enhancing Aircraft Ground Trajectories through Map-Matching and Stochastic Pavement Roughness Modeling

Martin Schlosser; Hannes Braßel; Hartmut Fricke;

Original paper

The DOI for the original paper is https://doi.org/10.59490/joas.2024.7898

Review - round 1

Reviewer 1

The authors’ long-term goal is to estimate the loads induced by taxiing on landing gears of aircraft based on freely available data. To this end, this paper presents a methodology for (i) generating 4D surface trajectories of aircraft taxiing on the ground of airports based on OpenSky Network (OSN) data, and (ii) generating surface roughness profiles using stochastic modelling. The topic of the paper is interesting; in the context of the OpenSky Symposium, I think the generation of 4D surface trajectories based on sparse ADS-B and geospatial airport data is of great relevance. This is especially in view of the fact that only a limited number of sources have dealt with OSN surface trajectories to date and this paper thus expands the state of knowledge in this regard. All in all the paper is well written and structured, for this reason my following comments only aim to further enhance and clarify the paper.

Major comments: None Minor comments:

  • Generally, I think you use too many brackets in your text. I suggest using less in order to improve the readability of your manuscript.

  • Generally, I suggest using less the word “like” (e.g., see Section 1.1.2).

  • In general, I find that you use too many abbreviations in your paper. Consider limiting abbreviations to terms that are frequently used throughout the text. For terms mentioned only once or twice, it’s better to write them out in full to enhance readability and clarity.

  • Page 1, Line 28 / Figure 1: In the best case, you have access to data that the aircraft itself logs (e.g. flight data recorder data). The ‘trajectory data’ mentioned in the paper is only of interest to stakeholders who do not have access to data logged by the aircraft. Indeed, I recommend highlighting the fact that open access data is used and emphasising this as a strength of the methodology presented in the paper.

  • Page 2, Line2 42/43: Another reason for the missing/sparse datapoints are coverage issues, which can be very significant for certain airports, especially for surface trajectories in OSN (viewed the other way round: There are currently few airports at which the ground coverage of OSN is very good). Here, too, I would point out in the paper that the methodology presented can partially overcome this limitation of OSN data.

  • Page 2, Line 54: Shouldn’t it be «…has been subject to scientific discourse for several years and remains…”

  • Page 3, Line 74: I recommend emphasizing the point that the unavailability of FDR data is a general issue, i.e., not only your study is affected.

  • Page 3, Line 78: Write out ADS-B, as it is the first time you use it.

  • Page 3, Line 88: You mention Olive et al., but you cite Basora et al. [22]

  • Page 4, Lines 92 to 98: You could also mention Olive et al.’s contribution on taxiway filtering:
    https://www.researchgate.net/publication/382143178

  • Page 4, Lines 100 to 103: I suggest simplifying the first sentence, it is rather long and hard to comprehend.

  • Page 5, Line 161: I’d rather use the word “summarized” than “depicted”, as Figure 3 only provides an overview of your method.

  • Page 5, Line 176: Comma needed after “dimensions”

  • Equation 1: You do not introduce formula symbol “L” in the text.

  • Equations 2 and 4: Formula symbol “n” is used for different quantities. I suggest introducing a new formula symbol / letter in one of the equations to enable a clear differentiation.

  • Page 6, Line 192: You do not explicitly state what formula symbol “G” is. I think it is an undirected graph, right?

  • Equation 6: You do not introduce formula symbol in the text.

  • Equations 3, 7, 12: Is there a reason why you use once "\cdot" and once "×\times" for a multiplication operation?

  • Equations 9 and 10: Formula symbol ‘m’ is already used in another context. To avoid confusing readers, I suggest introducing a new symbol for the selected window size.

  • Page 8, Line 225: To enhance clarity, I suggest writing “…being calculated similarly to Equation 1 and…”.

  • Equation 12: Is Equation 12 not missing brackets?

  • Section 2.2: Just out of curiosity: How do you determine the wheelpath of an aircraft in your method? I ask because the calculation of a wheelpath can be quite complex if it is to be calculated correctly.

  • Figure 5: The orange dot in Figure 5 is not well visible. Consider drawing both a bolder point as well as selecting another color.

  • Page 9, Line 255: Comma missing after [52]

  • Equation 13: Formula symbol “r” is not introduced in the text.

  • Figure 6: Is the colorbar really in the unit of meters? I am asking since the z-scale of the diagram is in the unit of mm.

  • Figure 7 is hardly readable (In general, I think the fontsizes is too small).

  • Page 11, Lines 292-293: You mention a surface rated as “A”. You might want to mention that this refers to the PCI scale.

  • Page 11, Line 303: You might consider combining the two paragraphs, as the latter is rather short and thematically refers to the former one.

  • General comments regarding Section Results: You somehow mix methods (i.e., how you created the results generated) and the actual results. You might want to consider moving the parts of your current results section describing how you calculated your results to Section Methods.

  • In the first paragraph of Section Results, you mention that you considered 292 ground movements of A220-300 aircraft at Frankfurt Airport. Are all these 292 movements using the same taxiways/runways as specified in the bullet point list on Page 12? Besides, you mention that you considered both take-offs and landings. From the bullet point list, however, one can infer that the described movement sequence refers to the one of an arriving aircraft.

  • Figure 8: Why is the average speed between ground distance 1000m and approximately 3000m so noisy?

Reviewer 2

Overview
The paper “Enhancing Aircraft Ground Trajectories through Map-Matching and Stochastic Pavement Roughness Modeling” focusses on the data analytical challenges of aerodrome manoeuvring area load monitoring. The approach aims to derive a digital twin inspired tool to address the relevant surface load/fatigue/maintenance measures based on associated surface movement trajectories. The paper explores the use of open – and typically – sparse ADSB data for the ground movement portion of flight at aerodromes and establishes a surface movement area model to build a representation of the movement area. The paper is structured along those two major building blocks. It introduces the problem statement/space and the underlying conceptual and methodological approach. A very brief use-case presents experimental results, and closes with a conclusion iterating on what was shown, associated benefits/drawbacks, applications, and potential future work. The building blocks (i. trajectory complementation, and ii. pavement model) are thoroughly presented including the related mathematical description/formulation of the model/approach. This puts the paper into the realm of a methodology-based journal paper.

Overall assessment
The paper presents a comprehensive body of work. From a reading perspective, it would be desirable to work on balancing the sections a bit more (e.g. long introduction [about 4 pages] vs 1-page conclusion sandwiching the body broadly broken down into an extensive method/approach part [7-8 pages] and a short 1,5 page result section). It is understood that the focus of the paper is on the approach and modelling. However, the body would benefit from a better integration of the application (or use-case). While the modelling concepts and formulation are well introduced, it remains widely an abstract presentation (more suitable for a thesis). The – too brief – application to Frankfurt does not necessarily help the reader to see how the approach is applied/instantiated with what type of results. The paper is overall well written and shows a good interplay between the text and supporting visualisations. However, the visualisations lack – sometimes – of readability. In particular, the chosen heatmap colouring / spectrum might inflate the numerical relevance. Ditto, on the use of sub-plots. A break-out of the sub-plots might help to “navigate” the graphics in a better way (at the cost of having more visualisations) in such a way that the text/graphic “spacing” is shorter.

Section 1: Introduction
The introduction motivates the work/paper by zooming in on the challenges of surface movements and potential wear and tear on the maneuver infrastructure (runway and taxiway system, and apron). The leading idea revolves around a “digital twin” for the management of associated health monitoring and management/scheduling of associated maintenance work. Such a capability will be based on modeling the interaction between the observed air traffic movements/trajectories, including aircraft type specific influencing factors, and the infrastructure. These elements are combined into a respective load monitoring flow chart/conceptual approach guiding the paper. (Well done!) The prevalent problem of sparse and incomplete ground movement trajectory data and the wear-and-tear interaction between aircraft and surface/pavement is motivated wrapping up the general portion of the introduction. An overview of the state-of-the-art elaborates on the key building blocks: trajectory modelling and surface movement/pavement characterization. The introduction closes with a reflection on the scope and objectives of the paper. The scope/objectives, and how these are addressed, are mapped to portions of the document.

Some pointers for your considerations: There is nothing wrong in terms of content/presentation. However, the introduction spans over 4 pages (with the content adding up to 14 pages \sim30 %) and covers already substantial ground/content. Think about balancing the sections, possibly lifting the motivation and scope/objectives into a dedicated introduction and use the other portions as a conceptual section guiding the work. I strongly recommend to limit the introduction to max 1 or 1,5 pages, pushing section 1.1. into a more appropriate subsection for the background. Think about what the major contribution of the paper is: you correctly work from the idea of a “digital twin” for maintenance purposes. How could this be better structured? Think about how Figure 1 or Figure 3 could be a guiding diagramme.

Section 2 – Methodology
Section 2 marks the major building block of the paper introducing the aerodrome surface mapping approach and the surface/pavement roughness model. The text steps the reader through the modelling in a nice combination of text, mathematical formulation, and associated visualisations. There is a good discussion / motivation of the selected approaches/methods/parameterization chosen. Some pointers for your considerations:

  • Editorial: I like that you provide some pointers at the start of a section. However, in section 2 it feels a bit mechanical (i.e., start of section tells about what is coming and then each sub-section [e.g., l.171, l.244] iterates about this one more time. How about dropping this?

  • Entry para 2.1: it might be worth spelling out why the work is done in UTM.

  • l.184: (certainly splitting hairs here) The ceiling function ‘ensures’ (or forces) njn_j to be an integer (if the ceiling definition/parameterisation is set for natural numbers); ‘remains’ sounds a bit awkward in this context.

  • l.181-193: It might be worth to elaborate on the “goodness” of OSM data motivating the spatial resolution/threshold distance. How many invalid edges can be found/eliminated. The chosen interpolation and validity criterion ensure the removal of ‘dangling’ nodes/forking orphan edges. I assume such ‘invalid’ nodes/edges are then considered to be ‘merged’ with the adjacent edge (and associated start/end nodes). Have a word about what happens with or represent ‘invalid’ edges. L.202-205 might be covering this, but it is isolated from the discussion here. Note: the later then also speaks about a ‘search radius’ which I failed to link to the provided criteria.

  • L.172/194 vs l. 197: Tracked aircraft positions are introduced as T=(xi,yi,ti)iN=1T = {(xi , yi , ti )}^N_i=1, thus NN denoting the total number of position data points. Strictly speaking a flight (one object) is correctly described by Tf,i=(xf,i,yf,i)Tf ,i = (xf ,i , yf ,i) [l.196] as a subset of all positions. The statement fNf \in N is a misnomer (with probably NN referring to the total ‘N’umber of flights studied). Maybe fFf \in F – as NN is already used elsewhere or drop it here since Tf,iTf,i covers this already.

  • Equation 5/following lines: nice use of a penalty factor in combination with the orientation/movement direction.

  • l.205 (another hair-splitting comment): Airport Operations Area is the totality of – what ATS refers to as ‘movement area’ and the appended facilities (e.g., hangars). Can it overlap? For sure certain portions/sub-components of the AOS – in their OSM representation – can.

  • l.238-242: well done! Keep this practice to tell the reader what you took from previous (or other work).

  • Editorial/style: check l.241-243 vs ‘mechanical’ repetition – maybe drop some? … trajectory will be expanded using a stochastic pavement roughness model. 2.2 Pavement Roughness Modeling This section explains the … procedure for creating stochastic roughness profiles …

  • l.246-248: check use of parentheses, e.g., (cf. Fig. 5). Vs (cf. Fig. 5. The …. 103m10^{-3} \, \text{m}).

  • Figure 5 – caption: the color coding is barely visible – obviously, ‘grey’ is used for non-red. The orange ‘start point’ can be easily overlooked. Think about people maybe working with a (black-and-white) copy of your paper. How about using other – more prominent – shapes for certain points you want to emphasise. The aspect of damage pattern is only mentioned in the caption itself – you might loose here. Ditto dsx/dsy/dex/dey can certainly be inferred here (as it takes a while until the text uses them, e.g., l.298f). But what do they tell us (here)?

  • L.250-252: How about make it easier to read/understand (i.e., remove fillers, break-down long sentences)?: The defined grid then serves as input for the generation of the so-called base surface, into which both d[D]esign-related irregularities and typical damage patterns are subsequently inserted [to] disting[uishing] intobetween pavement material and damage rating.

  • L.259: remove stray space before the fullstop.

  • l.261ff/Figure 6: Please add some context, provide some text outside the caption, and/or change the scale labels. For the uninitiated reader, the figure suggests some ‘heavy’ variances (e.g. first look at heat-colour scale/label -3:3 vs [m] in label, the x10310^{-3} should probably sit in the legend label). Ditto, the fact that we see a 10cm by 10cm portion takes a while to work out.

  • L.285/Figure 7: The figure is hard to understand, and the just mentioned Table 2 is easier to understand with the preceding text. Can it go?

  • l.302-318/Figure 8: I went over this section of the paper several times (including the preceding portion of establishing/characterising the roughness (elevation) profile. The bit I could not infer how the ‘data resolution’ is handled (or I missed it elsewhere in the paper, even when checking the use-case at Frankfurt/EDDF in the next section). How many interpolated trajectory position points are used vs the pavement roughness/damage resolution? Seeing the fine-scale modelling of the pavement roughness, I fail to comprehend the wear-and-tear interaction between aircraft/tyres along the predicted taxi-routing and the impacted pavement “target” area. L.245 gives a general description on ‘dimensions’. Is this the implemented ‘resolution’ for the use-case? A derived – curiosity-kills-the-cat – question: I wonder how the idea of a digital twin accounts for higher use (and associated load/wear-and-tear) of sections of the surface/pavement exposed to the tyre contact. The modelling will see an aircraft taxi along the predicted path, i.e., nose-wheel on this path and the main gear in equidistant offsets from it.

Section 3 – Results The result section applies the developed method to a use-case at Frankfurt airport (EDDF) and for a specific aircraft type, i.e., Airbus A220-300. The use-case analysis includes a total of 292 movements. The surface was modelled for four sub-sections of different dimensions. A composite figure shows an example for the trajectory prediction/complementation, respective associated and derived measures for taxi speed, heading/orientation, and the surface overall elevation change. The final sub-plot shows a sub-section roughness (including its inset light). The section is relatively brief and lacks a bit of cohesiveness. L.327 speaks about 4 sub-sections. Figure 8 leaves it open how the analysed trajectory/ies relate to these sections. The final subplot zooms in on a subsection (and basically pointing out one of the inset lights). I would have expected to learn about some (summary) observations from those 292 movements. Since the paper abstract also markets diagnosis of surface structural issues/load monitoring, it would have been useful to elaborate on the findings for this sample (or any other smaller set chosen and/or link this with the selected four sections). I am cognisant that this comment might require some substantial more input to the paper. Please have a thought about the “contribution” / main aim of the paper. If we focus on a methodology paper, the use-case could be integrated at different points across the paper. This would avoid that this section feels less like an add-on … On top the reader may better comprehend the gems you have in your paper/approach. One could also argue that this section could easily go without impacting the content of the paper too much. So have a think on what to do with it.

Section 4 – Conclusions and Outlook
The conclusion is well-organised working through i.) what was shown in the paper, ii.) weaknesses/strengths of the approach/methods, iii.) how it can be applied, and iv.) ideas for future work. Interestingly, the conclusion does not dwell on the use-case. This might confirm the focus of the paper (in my read: methodological journal paper). Thus, you might have implicitly answered the need for section 3 as a stand-alone section.

Editorial comments
This is a well written paper. Thus, no real comments on this part.

  • ++1 for the correct technical use of “cf.” (i.e., Latin word ‘confer’) which even I did violate for far too long!

  • The practice of introducing abbreviation “once” is a conundrum. Be mindful that some of your abbreviations are introduced very “early” in the paper, e.g., AOA, PSD, and then picked up later in the text. Readers not using the same terminology/deep in your work, might have to go back to find the meaning. Thus, I recommend to – as a minimum – only introduce the abbreviation in the section where you ‘work’ with it (i.e., use it multiple times), or be generous and re-introduce it then again.

  • I recommend to refer ‘explicitly’ to “Equation (11)” or “Eq. (13)”. This may help a reader to “see” the difference to a reference, i.e., denoted by square brackets [11] or [13].

Visualisations
Your diagrams are super helpful. Congrats: ++1, or Figure 4 conveys a clear message. In general, do not try to overload or snow-under your visuals. Interested readers would like to grasp what is shown. Thus, pay attention to size of labels, readability of annotations, etc. Or improve this by providing a hook for the reader to find back what you point out in the text. I mentioned this above. In my view, the heatmap/rainbow colour coding is a misleading palette. In particular, check what you can do with the scales. In a nutshell, move away from the defaults of your graphing tool/library. Figure 7 did not help me at all understanding what you highlighted in the text. But it is certainly “colourful”. Think about breaking up some of your composite plots. In particular, Figure 8 comprises to much/different things. Figure 2 and Figure 8 top show trajectory plots. There are some real interesting aspects to both: some segments cut through the grass / appear outside the taxiways. There is some talk about quality for Figure 2, but that is a point you could work out better – possibly also showcasing how your approach helps to remove such inconsistencies. (another note: for sure remove the ground distance scale from Figure 8 top – or help a reader to understand why it is telling something))

References
++1 on the use of the high number of references. In this case, it works out nicely as you also add some valuable take-away from the background (why/what is important for your paper). Just be mindful in future work to not overload the paper/article (and increase the perception of sections taken out of a thesis).

Response - round 1

First, we would like to express our gratitude to both reviewers for the detailed and constructive feedback. In the following, we address each of the specific points mentioned in Section 2 to resolve the identified shortcomings, with the goal of further enhancing the quality of the paper. The key innovations and adjustments can be summarized as follows:

  • We have completely restructured Chapter 3. First, we renamed it "Application and Results" and then subdivided it into distinct subchapters. The chapter now begins with a concise introduction to the preprocessing of OpenSky Network data, followed by two additional subchapters dedicated to trajectory modeling and pavement modeling. For both areas of investigation, we have expanded the analyses, including, for example, an accuracy and error discussion related to the modeled trajectories. These revisions have resulted in a more balanced integration of the content with the other chapters.

  • We have particularly revised the majority of our figures and added new ones to better complement the textual explanations. In particular, in the figures depicting Airport Operational Areas (AOA), we replaced the satellite images with georeferenced data derived from The Aeronautical Information Exchange Model (AIXM), which offer significantly higher resolution and provide more detailed information.

  • Table 1 and Table 2 have been expanded, now showing more details concerning irregularities.

Important note: All references in this response document (lines, figures and tables) and their numbers refer to the original paper prior to incorporating any review comments.

Response to reviewer 1

Generally, I think you use too many brackets in your text. I suggest using less in order to improve the readability of your manuscript.

At the outset, it is worth mentioning that most parentheses are used for textual references (e.g., figures), citations, or abbreviations. Nevertheless, we have made an effort to revise and adapt any parentheses containing substantive textual content.

Generally, I suggest using less the word “like” (e.g., see Section 1.1.2).

The lexical repetitions have been reduced through rephrasing with suitable alternatives.

In general, I find that you use too many abbreviations in your paper. Consider limiting abbreviations to terms that are frequently used throughout the text. For terms mentioned only once or twice, it’s better to write them out in full to enhance readability and clarity.

We have addressed the comment and removed obsolete abbreviations, particularly those that are unofficial or uncommon, including DT (digital twin). The remaining abbreviations are widely used in the aviation context, for example, RWY/TWY, AIP, and ADS-B, as well as recognized within the scientific domain, like Power Spectral Density (PSD), or frequently referenced in our publication, such as OpenStreetMap (OSM).

Page 1, Line 28 / Figure 1: In the best case, you have access to data that the aircraft itself logs (e.g. flight data recorder data). The ‘trajectory data’ mentioned in the paper is only of interest to stakeholders who do not have access to data logged by the aircraft. Indeed, I recommend highlighting the fact that open access data is used and emphasising this as a strength of the methodology presented in the paper.

The comment is highly valuable, as the acquisition of flight trajectory data, for instance, those recorded through Flight Data Monitoring systems, is often challenging for scientific purposes. We have added the following passage:
"Notably, the use of open-access trajectory data derived from OpenSky Network is a key strength of the methodology presented in this study, as it allows stakeholders without access to proprietary aircraft-logged data, such as Flight Data Monitoring (FDM) information, to replicate and implement our approach effectively."

Page 2, Line2 42/43: Another reason for the missing/sparse datapoints are coverage issues, which can be very significant for certain airports, especially for surface trajectories in OSN (viewed the other way round: There are currently few airports at which the ground coverage of OSN is very good). Here, too, I would point out in the paper that the methodology presented can partially overcome this limitation of OSN data.

This comment is also valid, and we have therefore revised the text as follows:
"However, aircraft position data often suffer from sparse, noisy, or temporally and spatially misaligned data points due to sensor-based measurements and coverage issues, which can be particularly significant for certain airports, especially for ground trajectories recorded in the OpenSky Network. These coverage limitations result in only a few airports where OpenSky Network provides high-quality ground trajectory data (e.g., Zurich Airport). To address these challenges, our focus is on developing a robust methodology for processing and analyzing aircraft ground trajectories, employing map-matching techniques with open-source data to enrich sparse input trajectories and partially overcome the limitations of OpenSky Network ground data.
Additionally, we revised the corresponding Figure 2.

Page 2, Line 54: Shouldn’t it be «…has been subject to scientific discourse for several years and remains…”

Thanks for the comment, which is valid as well. The phrasing has been corrected accordingly.

Page 3, Line 74: I recommend emphasizing the point that the unavailability of FDR data is a general issue, i.e., not only your study is affected.

This objection is valid as well. We have adapted the passage as follows:
"Onboard systems within the framework of Flight Data Monitoring collect extensive data, complying with IR-OPS standards of European Union Aviation Safety Agency (EASA), noted for their breadth in parameters and precision. However, access to such data is generally limited and represents a common restriction across studies in the aviation domain, including this one."

Page 3, Line 78: Write out ADS-B, as it is the first time you use it.

The abbreviation ADS-B is now already included in the list describing our bottom-up approach (see page 2). At that point, we have now properly spelled out the abbreviation, making it unnecessary to do so at the text location mentioned by the reviewer.

Page 3, Line 88: You mention Olive et al., but you cite Basora et al. [22]

The content of the sentence is correct; however, we simply forgot to reference the appropriate source. Basora et al. [Basora et al. 2019] focus on statistical analyses, whereas Olive et al. [Olive et al. 2018] apply machine learning approaches (missing reference). The correct reference has now been added.

Page 4, Lines 92 to 98: You could also mention Olive et al.’s contribution on taxiway filtering.

The referenced source is indeed a perfect fit for our current publication. In this regard, we had direct contact with Xavier Olive during the ICRAT 2024 conference in Singapore. Our objective was the same—processing sparse ground trajectories—however, we approached this goal using different methodologies (map-matching vs. Kalman filter). We have included the source in our bibliography and integrated it into the following passage in Chapter 1.1 (State-of-the-Art) and Subchapter 1.1.1 (Trajectory Modeling and Analysis):
"Sparse or inaccurate trajectory processing includes inverse sampling (interpolation) and error reduction (smoothing) techniques. These methods cover outlier testing [Bach and Paielli 2014], spline-based smoothing [Giovino 2008], and model-based reconstruction using filters like the Kalman filter [Khadilkar and Balakrishnan 2011; Tang et al. 2022; Olive et al. 2024]." (see reference [Olive et al. 2024])

Page 4, Lines 100 to 103: I suggest simplifying the first sentence, it is rather long and hard to comprehend.

The sentence was simplified as follows:
"Pavement roughness significantly impacts aircraft performance, component lifespan, and the safety of ground operations. It necessitates adherence to regulatory standards for determining ground loads during aircraft certification and for the design and maintenance of Airport Operational Areas (AOA) pavements across Europe."

Page 5, Line 161: I’d rather use the word “summarized” than “depicted”, as Figure 3 only provides an overview of your method.

The comment is understandable and has been implemented accordingly.

Page 5, Line 176: Comma needed after “dimensions”

Correct—this adjustment has been made.

Equation 1: You do not introduce formula symbol “L” in the text.

That is absolutely correct. LjL_j represents the length of a segment SjS_j as the Euclidean distance, defined in Eq. (1) as the magnitude of the vector between the starting point Qj,startQ_{j,\text{start}} and the endpoint Qj,endQ_{j,\text{end}}. We have now provided an explanation of the symbol LjL_j in the text.

Equations 2 and 4: Formula symbol “n” is used for different quantities. I suggest introducing a new formula symbol / letter in one of the equations to enable a clear differentiation.

The symbol for the number of interpolations in Eq. (2) and Eq. (3), njn_j, has now been replaced with pjp_j to enhance clarity.

Page 6, Line 192: You do not explicitly state what formula symbol “G” is. I think it is an undirected graph, right?

Exactly—an explanation of the symbol has been added to the text.

Equation 6: You do not introduce formula symbol in the text.

A very important remark that prompted us to carefully re-evaluate Eq. (6). As a result, we have revised both the introductory text and Eq. (6) as follows:
"A plausibility check γ\gamma evaluates the orientation alignment of the aircraft’s heading ii with the angular orientations of the OSM edges kk in the undirected graph GG. The check calculates the heading difference Δθi,k\Delta\theta_{i,k} and compares it to an angular threshold αth\alpha_{th}, ensuring alignment within a predefined tolerance, considering both standard (|Δθi,k||\Delta\theta_{i,k}|) and perpendicular (|Δθi,k+π2||\Delta\theta_{i,k} + \frac{\pi}{2}|) alignments:"
γi,k={1if min(|Δθi,k|,|Δθi,k+π2|)αth0otherwise\gamma_{i,k} = \begin{cases} 1 & \text{if } \min(|\Delta\theta_{i,k}|, |\Delta\theta_{i,k} + \frac{\pi}{2}|) \leq \alpha_{th} \\ 0 & \text{otherwise} \end{cases}

Equations 3, 7, 12: Is there a reason why you use once "\cdot" and once "×\times" for a multiplication operation?

No, there is no specific reason. To maintain clarity across our equations, we replaced ’×\times’ by ’\cdot’ in Eq. (7). An exception are multiplications in exponential notations in running text, which are typically represented with a ’×\times’.

Equations 9 and 10: Formula symbol ‘m’ is already used in another context. To avoid confusing readers, I suggest introducing a new symbol for the selected window size.

We follow the reviewer’s suggestion and have changed the symbol for the window size in Eq. (9) and Eq. (10) from ’mm’ to ’ww’.

Page 8, Line 225: To enhance clarity, I suggest writing “…being calculated similarly to Equation 1 and…”.

This aspect was also noted by the second reviewer. To improve differentiation between source references in square brackets ’[1]’ and equations in round brackets ’(1)’, we have added the term ’Equation’ before the equation number in all text sections where an equation is referenced.

Equation 12: Is Equation 12 not missing brackets?

That is fundamentally correct; however, we have revised Equation (12) because the chosen Haversine approach in Equation (11) already provides values in degrees. Therefore, a conversion from radians is no longer necessary.

Section 2.2: Just out of curiosity: How do you determine the wheelpath of an aircraft in your method? I ask because the calculation of a wheelpath can be quite complex if it is to be calculated correctly.

Determining the exact wheel path can indeed be complex, particularly during turning maneuvers and varying taxi operations. However, the term ’wheel path’ was likely misleading in the context of our study, as it solely refers to the main landing gear width, which is more accurately described as ’wheel track’. We have adjusted the terminology accordingly.

Figure 5: The orange dot in Figure 5 is not well visible. Consider drawing both a bolder point as well as selecting another color.

In accordance with the comments from both reviewers, Fig. 5 and its caption has been revised. Regarding the displayed damage patterns (red), the symbol for the nodes has been adjusted (’$\medblackdiamond$’), and the starting node has been consistently colored in green.

Page 9, Line 255: Comma missing after [52]

The comment is correct and has been implemented.

Equation 13: Formula symbol “r” is not introduced in the text.

In this case, ’rr’ is not a formula symbol but rather an index used to differentiate the properties of the wave vector qq and the wavelength λ\lambda. Specifically, ’rr’ represents ’roll-off,’ while ’ss’ stands for ’short’. For clarification, we added a short explanation in the corresponding text.

Figure 6: Is the colorbar really in the unit of meters? I am asking since the z-scale of the diagram is in the unit of mm.

All units in the coordinate system in Figure 6 are consistent with the SI unit ( m). The elevation color bar of subplot 2A (upper right) includes the exponent 10310^{-3} to convert the units from ( m) to ( mm), as shown in the lower edge of the color bar. In the interest of consistency to the other subplot, we have removed the exponent so that the elevation values are displayed in ( m) with corresponding decimal places, similar to the other color bars.

Figure 7 is hardly readable (In general, I think the fontsizes is too small).

We have adjusted the font sizes and enlarged the graphic to fit the full column width. Additionally, the majority of our figures are vector graphics, ensuring that zooming within the PDF is lossless. For all non-vector graphics, we have ensured a sufficiently high resolution to allow zooming without noticeable pixelation.

Page 11, Lines 292-293: You mention a surface rated as “A”. You might want to mention that this refers to the PCI scale.

The reference to the PCI scale is already explained in the preceding paragraph (see lines 279–280). However, for better understanding, we have reiterated the rating at the corresponding point in the text.

Page 11, Line 303: You might consider combining the two paragraphs, as the latter is rather short and thematically refers to the former one.

The two mentioned paragraphs have now been combined according to the reviewer’s recommendation.

General comments regarding Section Results: You somehow mix methods (i.e., how you created the results generated) and the actual results. You might want to consider moving the parts of your current results section describing how you calculated your results to Section Methods.

In our opinion, the only connection to the methodology lies in the quantification of the input parameters for the graph model (proximity threshold ϵ\epsilon and search radius rsr_s) as well as the input parameters for the modeling of pavement roughness (Hurst exponent HH, standard deviation σ\sigma, and surface width YY). Since these are variables whose individual numerical values have a direct impact on the results, we believe they are more appropriately addressed in the "Results" section, now titled "Application and Results" . To summarize, these parameters are initially presented and explained in general terms in the methodology section and are assigned specific values in the results section to generate concrete outcomes. In this context, Therefore, we have revised Chapter 3 and documented all input parameters that contributed to the individual results.

In the first paragraph of Section Results, you mention that you considered 292 ground movements of A220-300 aircraft at Frankfurt Airport. Are all these 292 movements using the same taxiways/runways as specified in the bullet point list on Page 12? Besides, you mention that you considered both take-offs and landings. From the bullet point list, however, one can infer that the described movement sequence refers to the one of an arriving aircraft.

First, it should be noted that the original test dataset contained 649 flight movements. After filtering for ground movements, the test dataset was reduced to 291 entries. These movements include takeoffs and landings on different RWYs, as well as taxiing procedures using various TWYs and parking positions, resulting in diverse ground trajectories. This aspect was not adequately described in the original paper, which is why we revised the corresponding text passage accordingly.
The presented results refer to only one sample flight movement from the filtered test dataset, which consists of 291 flight movements (see Figure 1 below, which also has been added to the paper’s review version). Specifically, this involves a landing on RWY 07R with the final parking position V163, being applied as a sample trajectory to our trajectory and pavement modeling approach. However, we applied our methodology to all ground movements within the filtered test dataset. For the sake of clarity, results are presented exclusively for the selected sample ground movement. To enhance precision and understanding, we have added Figure 1 and supplemented the textual descriptions as follows:

  • Line 315 ff., new Chapter 3.1 in the revised version:"For this study, we analyzed a test dataset consisting of Airbus A220-300 aircraft flight movements at Frankfurt Airport (EDDF) used as reference aircraft type within the load monitor. This test dataset was obtained from the OpenSky Network, spans from May 2019 to June 2022, and contains 649 recorded movements. To extract only ground movements, the test dataset was initially filtered based on altitude, airport area, and a minimum number of 10 data points per trajectory. As a result, the final test dataset contains 291 ground movements, comprising 145 departures and 146 arrivals of aircraft using different RWYs, TWYs, and parking positions."

  • Line 324: "Building on this, we applied our map-matching approach to all 291 ground movements. Figure 12 (former Figure 8) presents the corresponding results for one representative sample of ground movement from the dataset, involving a landing on RWY 07R at EDDF airport.

  • Line 327: The aspects related to the stochastic pavement model have been fully relocated to the new Subchapter 3.2.

Samples of aircraft ground movements from prefiltered OpenSky Network test dataset distinguished into inbound (red) and outbound (blue) traffic summing up to 291 movements.

Figure 8: Why is the average speed between ground distance 1000m and approximately 3000m so noisy?

Regarding the sample ground movement underlying Figure 8, it should first be noted that the groundspeed values of 125 m s−1 are to be considered unrealistic and likely correspond to the last reliable speed measurement. These values were then presumably propagated to the remaining data points on the ground.
The average speeds presented in Figure 8 were calculated by determining the distance and time between adjacent ADS-B points from the OpenSky Network dataset. Subsequently, the quotient of distance and time was calculated, representing the average speed between these data points. Importantly, data points filled via map-matching were excluded from this calculation, as interpolating timestamps between given ADS-B points and applying them to the filled data points does not necessarily reflect the actual movement behavior of the aircraft.
An analysis of the OpenSky Network ADS-B data points within the ground distance range of approximately 1000 m–3000 m reveals that the distances between adjacent data points vary (approximately between 5 m–25 m), while the time intervals between these points remain relatively constant at around 1 s. This discrepancy results in fluctuating groundspeed values. It is likely that the provided timestamps are imprecise.
These aspects have now been added to new Subchapter 3.2.

Response to reviewer 2

Overall assessment:

  • From a reading perspective, it would be desirable to work on balancing the sections a bit more (e.g. long introduction [about 4 pages] vs 1-page conclusion sandwiching the body broadly broken down into an extensive method/approach part [7-8 pages] and a short 1,5 page result section).

  • It is understood that the focus of the paper is on the approach and modelling. However, the body would benefit from a better integration of the application (or use-case). While the modelling concepts and formulation are well introduced, it remains widely an abstract presentation (more suitable for a thesis). The – too brief – application to Frankfurt does not necessarily help the reader to see how the approach is applied/instantiated with what type of results.

  • However, the visualisations lack – sometimes – of readability. In particular, the chosen heatmap colouring / spectrum might inflate the numerical relevance. Ditto, on the use of sub-plots. A break-out of the sub-plots might help to “navigate” the graphics in a better way (at the cost of having more visualisations) in such a way that the text/graphic “spacing” is shorter.

Section balancing:
We generally agree with the reviewer that the chapter lengths are not well-balanced. The actual introduction (Chapter 1) is indeed somewhat lengthy. Our intention was to engage the reader as effectively as possible and clearly highlight the necessity of the modeling aspects discussed at the beginning as part of a bottom-up approach within the load monitor, which serves as a component of a digital twin for aircraft landing gear. Both the trajectory model and the pavement roughness model are merely building blocks within the overall modeling approach in the load monitor, and thus serve as means to an end. Subchapter 1.1, State-of-the-Art, was intentionally kept shorter, although a literature review is always an essential part of any scientific work. The same applies to subchapter 1.2, Scope and Objectives. In summary, while the reviewer’s critique regarding the uneven text distribution is understandable, we do not see a significant benefit in substantially shortening the introductory Chapter 1. On the contrary, we are concerned that doing so might result in the loss of important information that helps the reader grasp the "big picture" and contextualize our work appropriately. Besides that, we revised Chapter 3 completely, Application and Results,so that the length of the text sections between the introduction and the results is now more balanced.
Application/use-case:
It should first be noted that we have significantly revised Chapter 3, Application and Results, as part of the review process. In addition to the inclusion of additional figures, we conducted a more detailed analysis of the dataset used, for example, by calculating the errors in distance and speed caused by the sparse position data.
Readability of figures:
We have carefully considered the reviewers’ feedback on the figures and have revised almost every figure accordingly, incorporating their suggestions. Additionally, we have introduced specific new figures where necessary. For instance, Figure 8 has been split, with trajectory modeling and the speed/heading analyses now presented in separate figures.

Introduction:
There is nothing wrong in terms of content/presentation. However, the introduction spans over 4 pages (with the content adding up to 14 pages \sim30 %) and covers already substantial ground/content. Think about balancing the sections, possibly lifting the motivation and scope/objectives into a dedicated introduction and use the other portions as a conceptual section guiding the work. I strongly recommend to limit the introduction to max 1 or 1,5 pages, pushing section 1.1. into a more appropriate subsection for the background. Think about what the major contribution of the paper is: you correctly work from the idea of a “digital twin” for maintenance purposes. How could this be better structured? Think about how Figure 1 or Figure 3 could be a guiding diagramme.

We have sought to improve the overall balance of the text, as also outlined in Response Box 1 under ’Section balancing’. That being said, implementing the suggested adjustments would require extensive revisions affecting nearly all aspects of the paper. We kindly ask for your understanding that while we acknowledge and appreciate the feedback, these recommendations will be considered for future work but would exceed the scope of the present study.

Methodology:
Editorial: I like that you provide some pointers at the start of a section. However, in section 2 it feels a bit mechanical (i.e., start of section tells about what is coming and then each sub-section [e.g., l.171, l.244] iterates about this one more time. How about dropping this?
Editorial/style: check l.241-243 vs ‘mechanical’ repetition – maybe drop some?
… trajectory will be expanded using a stochastic pavement roughness model. 2.2 Pavement Roughness Modeling
This section explains the … procedure for creating stochastic roughness profiles …

Indeed, the introduction at the cited sections appears somewhat mechanical and repetitive. Line 241/242 was left unchanged, but we have revised the introductory sentences as follows:

  • Line 171: "For enriching sparse trajectory data, we define the dataset of all tracked aircraft positions as T={(xi,yi,ti)}i=1NT = \{(x_i, y_i, t_i)\}_{i=1}^N [...]"

  • Line 244: "The starting point for creating stochastic roughness profiles (cf. Figure 3) is the creation of a grid [...]"

Entry para 2.1: it might be worth spelling out why the work is done in UTM.

We have added the following sentences:
"UTM is employed as it provides a consistent, planar coordinate system with minimal distortion at local scales. Its metric framework enables precise and straightforward calculations of distances and speeds, making it particularly suitable for aerodrome surface analysis."

l.184: (certainly splitting hairs here) The ceiling function ‘ensures’ (or forces) njn_j to be an integer (if the ceiling definition/parameterisation is set for natural numbers); ‘remains’ sounds a bit awkward in this context.

The sentence has been revised as follows:
"Thereby, \lceil \cdot \rceil represents the ceiling function, which ensures that pjp_j is an integer and guarantees a minimum spatial resolution for edge identification."

l.181-193: It might be worth to elaborate on the “goodness” of OSM data motivating the spatial resolution/threshold distance. How many invalid edges can be found/eliminated. The chosen interpolation and validity criterion ensure the removal of ‘dangling’ nodes/forking orphan edges. I assume such ‘invalid’ nodes/edges are then considered to be ‘merged’ with the adjacent edge (and associated start/end nodes). Have a word about what happens with or represent ‘invalid’ edges. L.202-205 might be covering this, but it is isolated from the discussion here. Note: the later then also speaks about a ‘search radius’ which I failed to link to the provided criteria.

First, it should be noted that OSM data consists of vector data, which can achieve arbitrarily high resolution through data point enrichment (see interpolation between OSM data points in Equations (1), (2), and (3)). In the present study, the parameter ϵ\epsilon was set to 3 m, ensuring a sufficiently high density of OSM data points. Decreasing this value increases the resolution of the graph model. While this enhances the precision of the map-matching algorithm, it also increases computational complexity. Thus, determining the interpolation granularity represents a trade-off between result accuracy and computational efficiency. With regard to the construction of the graph model, we first added that self-loops were ignored. Furthermore, we moved the paragraph starting at line 202 upward, resulting in the following section:
"Here, Em,n=1E_{m,n} = 1 indicates a valid edge between vertices mm and nn. To ensure the graph model accurately represents feasible TWY intersections, dthd_{\text{th}} is set slightly above ϵ\epsilon, compensating for any data inaccuracies. Then, a graph G(V,E)G(V,E) with undirected edges, where self-loops are excluded to avoid redundant connections, serves to predict the path between two consecutive ADS-B data points ii and i+1i+1. Compared to [Schlosser et al. 2024], the graph model was enhanced by removing unnecessary edges, and by adapting both the distance threshold dthd_{\text{th}} and search radius rsr_s for identifying valid connections within the map-matching approach. This adjustment enables more precise results, particularly in airport areas characterized by a high density or overlapping of different types of markings within the AOA.

L.172/194 vs l. 197: Tracked aircraft positions are introduced as T=(xi,yi,ti)iN=1T = {(xi , yi , ti )}^N_i=1, thus NN denoting the total number of position data points. Strictly speaking a flight (one object) is correctly described by Tf,i=(xf,i,yf,i)Tf ,i = (xf ,i , yf ,i) [l.196] as a subset of all positions. The statement fNf \in N is a misnomer (with probably NN referring to the total ‘N’umber of flights studied). Maybe fFf \in F – as NN is already used elsewhere or drop it here since Tf,iTf,i covers this already.

Thank you very much - this remark is both important and accurate. To clarify, the following explanations are provided:

  • NN represents the total number of position data points across all flights in the dataset.

  • NfN_f denotes the total number of position data points for an individual flight ff.

We have refined the corresponding sections of the text as follows:

  • Line 172: "For enriching sparse trajectory data, we define the dataset of all tracked aircraft positions as T={(xi,yi,ti)}i=1NT = \{(x_i, y_i, t_i)\}_{i=1}^N, where NN represents the total number of position data points across all flights within the dataset, with xi,yix_i, y_i as Easting and Northing in Universal Transverse Mercator (UTM) format, and tit_i as the timestamp for each position."

  • Line 194: "Map the positions of each flight ff, defined as Tf={(xf,i,yf,i,tf,i)}i=1NfT_{f} = \{(x_{f,i}, y_{f,i}, t_{f,i})\}_{i=1}^{N_f}, to the nearest neighbour graph vertex VV."

  • Line 196: "Let’s introduce a mapping function Φ\Phi, which assigns each aircraft position Tf,i=(xf,i,yf,i)T_{f,i} = (x_{f,i}, y_{f,i}) of flight ff to the most plausible nearby vertex kVk \in V. The function is defined as follows:"

The introduction of an additional variable FF to represent the entirety of all flight movements is therefore not necessary, as the existing notation already provides sufficient clarity and avoids redundancy.

l.205 (another hair-splitting comment): Airport Operations Area is the totality of – what ATS refers to as ‘movement area’ and the appended facilities (e.g., hangars). Can it overlap? For sure certain portions/sub-components of the AOS – in their OSM representation – can.

It is indeed correct that the AOAs themselves do not overlap; rather, it is their centerline markings that do, particularly in intersection areas or on aprons where different markings exist (e.g., lead-in lines, turning lines, and taxilanes). The text passage has been revised as follows:
"This adjustment enables more precise results, particularly in airport areas characterized by a high density or overlapping of different types of markings within the AOA."
Just for information: As an alternative to OSM data, we have acquired data from The Aeronautical Information Exchange Model (AIXM) for EDDF airport through the German ANSP DFS GmbH. AIXM is an open-source XML format provided by EUROCONTROL and the FAA (see https://aixm.aero/). It facilitates the transition from paper-based Aeronautical Information Services (AIS) to digital data. AIXM offers detailed digital aeronautical information, including aerodromes, airspace structures, routes, and flight restrictions. The provided aerodrome data offers significantly higher precision regarding surface markings and lighting compared to OSM and reflects the current state at EDDF airport as accurately as possible.
Since we now partially incorporate AIXM data in the present paper, we have provided the corresponding details in Subchapter 2.1.

l.246-248: check use of parentheses, e.g., (cf. Fig. 5). Vs (cf. Fig. 5. The …. 103m10^{-3} \, \text{m}).

The missing bracket has been added.

Figure 5 – caption: the color coding is barely visible – obviously, ‘grey’ is used for non-red. The orange ‘start point’ can be easily overlooked. Think about people maybe working with a (black-and-white) copy of your paper. How about using other – more prominent – shapes for certain points you want to emphasise. The aspect of damage pattern is only mentioned in the caption itself – you might loose here. Ditto dsx/dsy/dex/dey can certainly be inferred here (as it takes a while until the text uses them, e.g., l.298f). But what do they tell us (here)?

In accordance with the comments from both reviewers, Figure 5 and its caption has been revised. Regarding the displayed damage patterns (red), the symbol for the nodes has been adjusted (’$\medblackdiamond$’), and the starting node has been consistently colored in green.
Additionally, it should be noted that we consider it highly unlikely that anyone would print the paper in grayscale, and that the digital version will consistently be used. Therefore, it is essential to ensure that the color coding remains visible. An explanation of the damage pattern is provided further below in the text (see page 10 - 12). The comments regarding the start points and endpoints in the XX-direction and YY-direction (sxsx, exex, etc.) are clear, which is why we have supplemented the figure caption with corresponding explanations. Since these parameters are explicitly referenced again in the following methodology section (see lines 298 - 301, here with specific cross-reference to Figure 5), we are reluctant to remove them from the figure, as they visually support the relevant text passages. Creating an additional figure and placing it at the appropriate text location would also not be effective.
The figure caption of Figure 5 has been revised as follows:
"Grid with nodes for the base surface (grey), damage pattern (red), including the damage pattern’s start point (green), and indices for the start (ss) and end (ee) grid points in the XX-direction and YY-direction. The nodes for the base surface are denoted as sxsx and sysy (start) and exex and eyey (end), while the start and end nodes for the damage pattern are denoted as dsxdsx and dsydsy (start) and dexdex and deydey (end)."

L.250-252: How about make it easier to read/understand (i.e., remove fillers, break-down long sentences)?

The sentence has been simplified as follows:
"The defined grid serves as input for generating the base surface. Both design-related irregularities and typical damage patterns are then inserted, distinguishing between pavement material and damage rating."

L.259: remove stray space before the fullstop.

The space before the end of sentence has been removed.

l.261ff/Figure 6: Please add some context, provide some text outside the caption, and/or change the scale labels. For the uninitiated reader, the figure suggests some ‘heavy’ variances (e.g. first look at heat-colour scale/label -3:3 vs [m] in label, the x10310^{-3} should probably sit in the legend label). Ditto, the fact that we see a 10cm by 10cm portion takes a while to work out.

Line 265 has been modified as follows:
"Figure 6 shows an exemplary base surface with dimensions of 0.1 m ×\times 0.1 m. It is important to note that the elevation values (Z-axis and color bar) are given in  × 10−3 m =  mm."
With regard to the size of the displayed portion of the base surface, it should be noted that the dimensions are also provided at the beginning in the figure caption. In the interest of consistency (cf. Figure 7), we have removed the exponent so that the elevation values on Z-axis and color bar are displayed in ( m) with corresponding decimal places.

L.285/Figure 7: The figure is hard to understand, and the just mentioned Table 2 is easier to understand with the preceding text. Can it go?

Unfortunately, we are unable to understand what makes Figure 7 difficult to interpret. It illustrates design-related irregularities using concrete slabs as an example and exemplary damage patterns of pop-outs. In our opinion, the figure adds value, as it visually represents both the irregularities and their implementation in the modeling approach, allowing the reader to see how these irregularities manifest in practice. Table 2 provides an exemplary range of values for specific irregularities, which are used for their modeling. In this regard, Figure 7 serves as a valuable visual complement to Table 2. In summary, we would like to retain Figure 7.

l.302-318/Figure 8: I went over this section of the paper several times (including the preceding portion of establishing/characterising the roughness (elevation) profile. The bit I could not infer how the ‘data resolution’ is handled (or I missed it elsewhere in the paper, even when checking the use-case at Frankfurt/EDDF in the next section). How many interpolated trajectory position points are used vs the pavement roughness/damage resolution? Seeing the fine-scale modelling of the pavement roughness, I fail to comprehend the wear-and-tear interaction between aircraft/tyres along the predicted taxi-routing and the impacted pavement “target” area. L.245 gives a general description on ‘dimensions’. Is this the implemented ‘resolution’ for the use-case? A derived – curiosity-kills-the-cat – question: I wonder how the idea of a digital twin accounts for higher use (and associated load/wear-and-tear) of sections of the surface/pavement exposed to the tyre contact. The modelling will see an aircraft taxi along the predicted path, i.e., nose-wheel on this path and the main gear in equidistant offsets from it.

For us, the reviewer’s comments on this matter were not entirely clear. However, we would like to attempt to clarify the points raised as follows:
Data Resolution/Trajectory:
After applying the map-matching approach to complete the sparse trajectories, a trajectory with a specific number of data points is obtained. These data points are then used to determine the total length of the trajectory, which is subsequently fed into the pavement profile modeling process. This is demonstrated in the "Application and Results" chapter with the example trajectory presented there: due to the different pavement materials, modeling in four sections is required, with the length of all these sections approximately corresponding to the total length of the trajectory. Therefore, there is no direct link to the number of interpolated aircraft positions, but rather to the total length of the trajectory.
Resolution/Dimension:
The term ’resolution’ in relation to the modeled pavement profiles refers solely to the level of detail in the grid, specifically the number of nodes (see lines 244 - 248). By adjusting the resolution, design-related irregularities and damage patterns can be represented in greater detail (higher resolution in the XX-, and YY-direction). The total width of the pavement profiles to be modeled in the YY-direction is based on the main landing gear width of the reference aircraft, which is 6.7 m, plus a buffer, resulting in a total width of YY = 10 m – this is where the term ’dimension’ is used. This ensures that the pavement profile is wide enough to allow both the main landing gear and nose landing gear to virtually roll over a pavement with specific roughness. The modeled pavement profile should thus be envisioned as a kind of funnel over which our reference aircraft virtually moves. Regardless, the EDDF airport use case does not influence the dimension YY, but rather the underlying reference aircraft.
Wear and Tear/Digital Twin:
It should first be noted that, within the framework of our load monitor, we aim to determine the effects of taxi procedures on landing gear components in terms of accelerations and loads, as part of a digital landing gear twin. The wear and tear effects on pavements caused by aircraft movements are therefore not part of the modeling. However, damage patterns in the pavement, which are caused by frequent taxi movements or overloading, such as the rutting damage pattern, can be represented, which in turn could influence the landing gear structure. The tire-ground interaction is critical for the development of accelerations and loads on the landing gear. In particular, the effects of roughness are explicitly considered in the aircraft certification process according to EASA CS-25 (see Subpart C - Structure, Chapter Ground Loads, CS 25.491 Taxi, Take-off and Landing Roll, cf. https://www.easa.europa.eu/en/downloads/136694/en). The document also publishes a worst-case roughness profile (San Francisco RWY 28R before resurfacing), which, along with other worst-case assumptions, can be used to study the resulting effects. The impact of the macrotexture of pavements on ground loads is considered minimal and only results in loads from rolling friction, which primarily affect comfort. The main risk drivers for landing gear strength are damages leading to sudden vertical accelerations and load impacts on the landing gear (e.g., bumps or edges/height offsets), which can also be generated using our modeling approach. Indeed, the resolution of the generated pavement profiles presents the challenge that the frequency range of the tire model must be capable of depicting the vibrations/vertical accelerations resulting from the surface irregularities (see Chapter 4). Finally, it should be noted that the modeling approaches are solely intended for load determination. The effects of these loads on the wear and tear of tires and landing gear, as well as their structural strength, are not part of the load monitor.
We hope that these additional clarifications will help to shed light on the matter.

Results:
The result section applies the developed method to a use-case at Frankfurt airport (EDDF) and for a specific aircraft type, i.e., Airbus A220-300. The use-case analysis includes a total of 292 movements. The surface was modelled for four sub-sections of different dimensions. A composite figure shows an example for the trajectory prediction/complementation, respective associated and derived measures for taxi speed, heading/orientation, and the surface overall elevation change. The final sub-plot shows a sub-section roughness (including its inset light). The section is relatively brief and lacks a bit of cohesiveness. L.327 speaks about 4 sub-sections. Figure 8 leaves it open how the analysed trajectory/ies relate to these sections. The final subplot zooms in on a subsection (and basically pointing out one of the inset lights). I would have expected to learn about some (summary) observations from those 292 movements. Since the paper abstract also markets diagnosis of surface structural issues/load monitoring, it would have been useful to elaborate on the findings for this sample (or any other smaller set chosen and/or link this with the selected four sections). I am cognisant that this comment might require some substantial more input to the paper. Please have a thought about the “contribution” / main aim of the paper. If we focus on a methodology paper, the use-case could be integrated at different points across the paper. This would avoid that this section feels less like an add-on … On top the reader may better comprehend the gems you have in your paper/approach. One could also argue that this section could easily go without impacting the content of the paper too much. So have a think on what to do with it.

We have renamed Chapter 3 to "Application and Results" and have divided it into three subchapters: Subchapter 3.1 Input Data Preparation, Subchapter 3.2 Trajectory Modeling, and Subchapter 3.3 Pavement Roughness Modeling). Overall, we have significantly expanded the result analyses and supported them with corresponding figures, aiming to enhance clarity and effectively convey the relevant content. Specific statements regarding the impact of the modeled trajectory on landing gear loads within the framework of the load monitor for a digital twin application are addressed in future publications.

Visualisations:

  • In my view, the heatmap/rainbow colour coding is a misleading palette. In particular, check what you can do with the scales. In a nutshell, move away from the defaults of your graphing tool/library.

  • Figure 7 did not help me at all understanding what you highlighted in the text. But it is certainly “colourful”.

  • Think about breaking up some of your composite plots. In particular, Figure 8 comprises to much/different things.

  • Figure 2 and Figure 8 top show trajectory plots. There are some real interesting aspects to both: some segments cut through the grass / appear outside the taxiways. There is some talk about quality for Figure 2, but that is a point you could work out better – possibly also showcasing how your approach helps to remove such inconsistencies. (another note: for sure remove the ground distance scale from Figure 8 top – or help a reader to understand why it is telling something)

Heatmap:
We have adjusted the color coding of the entire enriched trajectory to consist exclusively of blue shades. This improves the visual distinction from the elevation representations in the pavement modeling figures. Additionally, we have ensured consistent color usage across all figures comparing the enriched trajectory with the original ADS-B trajectory: blue represents the enriched trajectory, while red is used for the ADS-B trajectory.
Figure 7:
Refer to the response concerning L. 285/Figure 7 above.
Figure 2 and Figure 8:
As mentioned above, we have completely revised Chapter 3 and improved the figures accordingly. Regarding Figure 8 (now Figure 12), we have added the following passage to the text:
"The original ADS-B trajectory (red) consists of 151 data points, while the enriched trajectory (blue gradient) now comprises a total of 963 data points, thus demonstrating a significantly improved level of detail and enabling higher mapping accuracy. This improvement is particularly evident in turning segments, such as between RWY 07R and TWY M19, and in the transition from TWY L to TWY N10."

Bach, R.E. and Paielli, R.A. 2014. A user guide for smoothing air traffic radar data. NASA Ames Research Center.
Basora, L., Olive, X., and Dubot, T. 2019. Recent advances in anomaly detection methods applied to aviation. Aerospace 6, 11, 117.
Giovino, J.D. 2008. Idealized truth data for system modeling and testing. 2008 integrated communications, navigation and surveillance conference, IEEE, 1–10.
Khadilkar, H. and Balakrishnan, H. 2011. A multi-modal unscented kalman filter for inference of aircraft position and taxi mode from surface surveillance data. Proceedings of the 11th AIAA aviation technology, integration, and operations (ATIO) conference.
Olive, X., Grignard, J., Dubot, T., and Saint-Lot, J. 2018. Detecting controllers’ actions in past mode s data by autoencoder-based anomaly detection. 8th SESAR innovation days.
Olive, X., Waltert, M., Mori, R., and Mouyon, P. 2024. Filtering aircraft surface trajectories using information on the taxiway structure of airports. 11th international conference on research in air transportation (ICRAT).
Schlosser, M., Braßel, H., and Fricke, H. 2024. Analysis of aircraft ground trajectories: Map-matching with open source data for modeling safety-driven applications. 11th international conference on research in air transportation (ICRAT).
Tang, X., Ji, X., and Liu, J. 2022. Predicting aircraft taxiing estimated time of arrival by cluster analysis. IET Intell. Transp. Syst. 16, 252–262.