DOI for the original paper: https://doi.org/10.59490/joas.2024.7716
The paper investigates drone traffic flying over streets of a city, where [conflicts between] drones create obstacles for other drones – a very natural conflict avoidance strategy (flying over streets didn’t look natural to me). Several ways of creating the obstacles are studied, and tradeoffs between safety and efficiency (as well as other KPIs) are evaluated. The topic is interesting, and the technical aspect is solid. I failed to follow the logic of why the drones should follow existing roads (see MAJOR COMMENT) – an assumption that is first made but then lifted in the experiments (still, lifted only to an extent: few "roads" are added – bridges and along a river).
Major comments:
"In major urban areas with tall built-up environment, flying between buildings may be necessary, as it could be inefficient to fly above the tallest buildings." - I’m not sure I follow the logic. The tallest may be 100m, but there may be 3-5m buildings side-by-side; why would you go down to fly between them? In fact, if you have buildings that aredifferentt on different sides of the road, you probably won’t go down to the shortest building height in order to fly between buildings.
"Moreover, due to potential privacy violations, flying above buildings may be discouraged." - Hmm, I’d rather say that flying past my window is a stronger privacy violation (and visual pollution)
"These aircraft will need to operate in a very constrained environment, in which they cannot travel in a straight line to their destinations but will instead stay above the existing road network." - Road network seems too restrictive. Maybe sometimes you’d fly over a road, but using roads only will create the same kind of congestion in the air that you’re trying to avoid on the ground, won’t it? One good thing about UAM is that drones can fly anywhere, distributing traffic and avoiding congestion (of course, there are restricted areas, but they should be minimized to keep traffic efficient and safe).
"This constrained environment greatly limits the manoeuvrability of aircraft, as they will not be able to perform heading changes to solve any potential conflicts with other aircraft." - Exactly this supports my point above. Your sentence below also does:
"Additionally, constrained airspace forces aircraft trajectories to converge at intersections, it makes it a difficult problem to mitigate, especially in a decentralised system." - (however, it’s not clear what you mean by intersections)
In the experiments, you also add bridges and roads over water – I feel this supports my point that flying over roads is too restrictive as well
Minor comments:
I’d suggest that the restriction to fly over roads should be highlighted in the title and abstract
There’s a typo ("with in" instead of "within") already in the abstract, which is probably not acceptable (pun intended).
"Ground transportation within urban areas contributes to increased congestion, which not only worsens air quality due to more vehicles on the road but also results in economic losses [1]" - I think transportation creates congestion, not just contributes to it (no transportation – no congestion,, right?).
Why using "not only…but also"? Why not just enumerate: worsens… and results?
"A potential alternative is to transfer part of ground transportation to the air, as it has the potential to be more beneficial for the environment [2, 3]. "Alternative to what? potential potential – is it a pun intended?
"This interest has led to several government-led research initiatives for drone operations in urban areas [4, 5, 6, 7]." Which interest? led led – again ;-)
dynamic (other aircraft) and static obstacles (buildings and geofences) -> dynamic (other aircraft) and static (buildings and geofences) obstacles?
These urban environments, These aircraft - Which these?
They concluded – The project concluded?
"In a completely decentralised system without any additional constraints, drones will prefer the shortest path to their destination." - Drones prefer such paths in any system
"Traffic complexity attempts to describe the disorder of the airspace" - Maybe "in the airspace"? It’s traffic disorder, not airspace disorder, right? Since you rightly refer to the Metropolis II project, it’d be nice to mind the difference between airspace and traffic- the better the airspace is managed, the easier it is to manage traffic.
Maybe you could link to the unpublished manuscript 19? Why do you need sectors in UTM? In ATMs, low-complexity sectors are needed by humans (and sectorless ATMs have been researched). In fact, I didn’t find where in the paper you do sectors over a cit. Still, in the Conclusion, you mentioned sectors again.
"density of the observed statistic" - density of statistic? Is it the probability density of the random variable?
It’d be nice to see some videos of how your solution works. I didn’t find videos in the supporting material ref 23 (are they the gifs? could be nice to have them immediately available, without the need to download the whole archive)
4000 what?
summing the streets – summing the length of the streets?
Eq(1). A long street may only touch a convex polygon, incorrectly resulting in a low-density value. I’d suggest summing only the street lengths *inside* the polygon.
Why categorizing the clusters? It’d look more natural if each cluster simply had a cost proportional to its density.
"The longer an aircraft is in the air, the more chance it has of encountering another aircraft." - Well, this depends on which density airspace it flies through
"After the airspace has been classified," - Do you classify the airspace? I thought you categorized the clusters (which I thought wasn’t needed)
"This is so that not all aircraft replan at the same time" - This is done to ensure that not all aircraft…?
Actually, I’d love to see simple examples (real or synthetic) where such unfortunate common replanning happens – will be very instructive (and add value to your efforts of avoiding it)!
Fig3. The reds are not convex, maybe don’t use Cluster in their names
Fig 9. (or another fig): Please show the convex polygons (on a real instance, and refer to it from Fig2)
At the end of the paper, the contribution of an author is Eriting (sic). I first thought it was a clever combination of Editing and Writing. However, this is likely not the case because the parentheses explain that it’s Review and Editing, just as for another author who has Writing (Review and Editing) in the same place (the authors seem to have identical contributions, except for the Eriting in place of Writing – that’s why I thought Eriting was the intended spelling)
The large file size may not be needed (think of compressing hi-res images)
The paper is very well written and organized. It clearly describes the scope and the motivations for a decentralised approach to insure safe and efficient management of high density drone operations in a constrained urban environment. It is built upon the results of previous work by the authors including collaborative research projects (Metropolis II, MAAS-GT) which are properly referenced. Commonalities with manned aviation (traffic safety and complexity, dynamic sectoring), as well as specificities of urban drone operations (constrained environment), are sound and well explained. The three clustering strategies (position-based, conflict-based and intrusion-based) are precisely described and the two application examples are relevant to illustrate the behavior of the method in realistic conditions. Next, the experimental study conducted in the urban environment of Rotterdam uses a rigorous approach (hypothesis testing, generation of scenarios, metrics, BlueSky simulations) and provides statistical results on the benefits and counterparts of each method with respect to safety, efficiency, and clustering. Supporting material is provided, offering means for a deeper understanding (in particular through the sensitivity analysis) and replication of the simulations and results.
The following remarks aim to enhance and clarify the paper on minor points.
First, it should be noted that the approach is, in fact, hybrid, as it requires, as a first step, the centralized real-time observation of the drone fleet positions (and safety events). This is indeed clearly indicated through reference [12]. The originality of the approach is that once the clusters have been centrally defined and transmitted to all aircraft, the path determination and the separation are performed by each aircraft individually (the latter using a speed-based resolution algorithm).
The clustering is performed every 10 seconds (line 98). The choice for the value of this update rate seems to be quite arbitrary, and it has not been investigated in the sensitivity analysis. It could be interesting to provide an explanation or to indicate that it could be investigated in future work, as it may have an impact on cluster stability (despite the re-plan limits) as well as computational and data transmission load.
The clustering strategies based on complexity indicators use events that have occurred in the past ten minutes, while the position-based strategy only uses the current position. While the ten-minute window sounds reasonable to gather the safety events, one could wonder why the position-based strategy does not also use a similar window to evaluate the traffic density. Smoothing the density would perhaps limit the recursive effect reported on lines 190-194, with the current positions of the blue aircraft interfering with the clustering. This point could be worth investigating.
It is indicated that the result of the observation is a simple 2D vector (line 108). It may be worth briefly explaining the content of this vector (coordinates of either the aircraft positions, conflicts or intrusions?).
The Ward clutter distance is defined as a squared Euclidian distance, so the value of 4000 should correspond to 63 meters rather than 100 meters (line 118). This should be clarified (no cue found in the sensitivity analysis).
It is indicated that the cluster in the lower 25th percentile is classified as low-density (line 145), while the sensitivity analysis concludes instead that the 75th percentile provides the lowest number of intrusions per flight. This should be clarified.
It is asserted that there are usually fewer conflicts than intrusions (line 187). This may seem counter-intuitive, and thus, a rationale would be welcome to clarify whether it is a general statement or if it is simply an observation of the particular network and traffic of the first example scenario.
The conflict resolution uses a protected radius of 32 meters (line 279), referring to ICAO annex 10 GNSS performance requirements. A short rationale should be added to explain the link between the chosen value and the ICAO reference.
It is indicated that each simulation scenario runs for 2 hours. This duration depends on the computer’s performance, which could be indicated to help the reader understand whether the computational cost is high (or not). Also the actual duration of the scenario (in real time) should be indicated, assuming that a minimum duration is probably required to obtain stable results.
The results are clearly presented and their interpretation leaves not much doubt, even if the statistical significance is not tested.
In order to ease the reading, the discussion could be better organized. First, the safety aspects could be addressed, and the paragraphs relevant to hypotheses H1, H2, and H3 could be grouped, followed by the efficiency and clustering metrics.
Typos are noticed on lines 6, 34, 432, 433, 481, 492. Also, note that reference [31] is now published (DOI missing).
The paper proposes a tactical traffic management approach for emerging air mobility operations in urban airspace and evaluates its impacts in terms of safety and efficiency through simulation. The method is based on the identification of airspace hotspots through clustering analysis of aggregate flow data followed by the generation of rerouting recommendations to avoid these hotspots. Overall, the methodological approach and results are well-presented and the paper is well-written. Below are minor comments and suggestions to further enhance the paper’s clarity and readability.
- Throughout the paper, the authors use the terms "separation management", "traffic management" and "airspace sectorization" interchangeably to describe the proposed method. If the main objective of the method is to manage aggregate traffic flows, without necessarily solving conflicts between individual 4D trajectories or defining airspace sectors, I believe the term "traffic management" (or "demand-capacity balancing") looks more appropriate to describe the scope of the research.
- How is the protection zone in Figure 1 defined? It is not presented in the text.
- In Section 3.2.4, it is important to clearly state and provide a foundation for the separation distance criteria considered. I assume it is 32 m based on "horizontal protected radius of 32 metres".
- In Section 3.2.4, it is stated that "The drones in this work use a tactical speed-based conflict resolution algorithm from [31] to solve conflicts in constrained airspace." I suggest clarifying whether this is integrated with the proposed rerouting strategy or if these tactical conflict management approaches are treated independently.
- On page 4, line 118, it is stated that "This work sets a cluster distance of 4000, which is about 90 metres (3 times the minimum separation distance of drones)." This needs further explanation. Moreover, is the same cluster distance applied in the three clustering strategies?
- Figure 4 is not very clear. Do the blue arrows represent the trajectory of a single flight or do they indicate positions for different flights? The polygon lines in different colors in panels (b)-(d) are also unclear. Do these polygons represent the clusters identified? What do the different colors indicate? For instance, in panel (b), why are there two red polygons? I recommend providing a more detailed explanation of this figure in the text to clarify these aspects. I also suggest increasing the width of the polygon lines for better visualization.
- The hypotheses in Section 3.1 have been assessed and discussed based on the box plots of simulation results. Formally presenting the statistical analysis results for hypothesis testing is recommended.
- In Figure 10, the distance percentage and replans increase with the demand levels for the intrusion-based clustering strategy. However, the opposite is observed for the conflict-based and position-based clustering strategies. This seems counterintuitive. Do the authors have any insights on what might be driving these different behaviors?
- In Section 5, the authors discuss the pros and cons of the different clustering strategies. I suggest adding a clear statement of the recommended approach for traffic management based on the results obtained.
- On page 16, line 433, "has a both a high percent" appears to be a typo.
The manuscript presents a method for managing urban drone traffic using decentralized, dynamic clustering strategies. The proposed system uses current position, conflict, and intrusion data to create real-time airspace sectors with varying travel costs to reduce local traffic density and complexity. I have the following comments/ questions for the authors regarding this work, which would require minor revisions. Unfortunately, the manuscript misses a comparison of the proposed methodology with any approaches (centralized / decentralized) in the literature, which may require re-evaluation. Introduction:
Page 1, line22: I understand that flying over buildings might be inefficient but for privacy concerns, I think flying between buildings would risk a greater violation as compared to flying over buildings. Moreover, the effect of noise based on the type of aircraft would also be a concern.
Page 3 line 98: the authors should provide some explanation on how 10 seconds is chosen. Is based on the computational requirements of the methodology or is it a suitable time based on some experiments? I think this time should also depend on the characteristics of the aircraft such as speed. Methodology:
Is there a possibility where the clusters overlap?
Replanning is allowed once every 30 seconds, with a 50% probability of following the new plan. What is the basis of this time duration, and how would this be affected by the density of traffic?
Figure 5, page 8: how does the dynamic management methods show advantage in this case – it seems that now the red drone must perform conflict avoidance from two flows of blue drones instead of one in the baseline case.
Experimental design:
How representative is Rotterdam airspace model for other urban environments with different geographical and architectural features? How were the seeds selected for the experiments. And do they adequately cover the variability in the traffic scenarios?
Results:
Figure 8: the figure show traffic demand v/s conflicts per flight. Does it mean conflict per drone? In other words, for a traffic of 100 drones, there would be on average 1.5 conflicts per drone. Isn’t that significantly high?
Further, what are the operational traffic levels? I ask this since the methods show almost similar performance level (figure 8 a) for almost all traffic demand levels.
Are the number of replans based on the requests made or executed number of new plans (since it is a probability)?
How does this methodology compare to the existing centralized or other decentralized methodologies?
Thank you very much for the helpful and insightful comments. Most changes from the original submission are highlighted in yellow. Typos are not highlighted unless the sentence changed significantly.
The paper investigates drone traffic flying over streets of a city, where [conflicts between] drones create obstacles for other drones – a very natural conflict avoidance strategy (flying over streets didn’t look natural to me). Several ways of creating the obstacles are studied, and tradeoffs between safety and efficiency (as well as other KPIs) are evaluated. The topic is interesting, and the technical part is solid. I failed to follow the logic why the drones should follow existing roads (see MAJOR COMMENT) – an assumption that is first made, but then lifted in the experiments (still, lifted only to an extent: few "roads" are added – bridges and along a river).
We have attempted to clarify why we are flying above the existing road network. Please refer to the updated line 23. We will also answer this more in detail in your other comments related to this.
I’d suggest that the restriction to fly over roads should be highlighted in the title and abstract.
The title and abstract of the article now contain a reference to constrained airspace.
There’s a typo ("with in" instead of "within") already in the abstract, which is probably not acceptable (pun intended).
This has been fixed.
"Ground transportation within urban areas contributes to increased congestion, which not only wors- ens air quality due to more vehicles on the road but also results in economic losses [1]"
I think the transportation creates congestion, not just contributes to it (no transportation – no congestion,,right?).
Why using "not only…but also"? Why not just enumerating: worsens… and results?
"A potential alternative is to transfer part of ground transportation to the air, as it has the potential to be more beneficial for the environment [2, 3]."
Alternative to what?
potential potential – is it pun intended?
"This interest has led to several government-led research initiatives for drone operations in urban areas [4, 5, 6, 7]."
Which interest?
led led – again;-)
The first paragraph of the introduction has been updated accordingly (refer to line 13).
I couldn’t follow the ideas in this paragraph.
"In major urban areas with tall built-up environment, flying between buildings may be necessary, as it could be inefficient to fly above the tallest buildings. " I’m not sure I follow the logic. Tallest may be 100m, but there may be 3-5m buildings side-by-side, why would you go down to fly between them? In fact, if you have different-height buildings on different sides of the road, you probably won’t go down to the shortest building height, in order to fly between buildings
Thank you for this comment. We have attempted to clarify this in the third paragraph of the introduction (line 23). The intention was not to state that aircraft should always ensure that they are between buildings. The statement has been rephrased to state aircraft may need to fly above the existing road network. Either because of very tall buildings or because of potential regulations. It could be possible that urban air regulators require aircraft to fly above the road network, as that tends to be public property, even in areas with relatively low building.
Moreover, due to potential privacy violations, flying above buildings may be discouraged." Hmm, I’d rather say that flying past my window is a stronger privacy violation (and visual pollution)
We have removed the privacy argument from the introduction.
"These aircraft will need to operate in a very constrained environment, in which they cannot travel in a straight line to their destinations but will instead stay above the existing road network." Road network seems too restrictive. Maybe sometimes you’d fly over a road, but using roads only will create the same kind of congestion in the air that you’re trying to avoid on the ground, won’t it? One good thing with UAM is that the drones may fly anywhere, distributing the traffic and avoiding the congestion (of course there are restricted areas, but they should be minimized to keep the traffic efficient and safe).
That is a fair point. However, We do not yet think it is a given that aircraft will always be able to follow open paths. Moreover, if we are able to have safe and efficient traffic management in a constrained airspace, then it should be possible in a more open airspace. So constrained airspace would be the worst case. We have reworded the title, introduction and abstract to state that this is specifically focused on constrained airspace.
"This constrained environment greatly limits the manoeuvrability of aircraft, as they will not be able to perform heading changes to solve any potential conflicts with other aircraft. " Exactly, this supports my point above. Your sentence below also does: "Additionally, constrained airspace forces aircraft trajectories to converge at intersections, it makes it a difficult problem to mitigate, especially in a decentralised system." (however it’s not clear what you mean by intersections)
Please refer to the previous response. We have clarified that it means the intersections of the network (see line 53).
In the experiments, you also add bridges and roads over water – I feel this supports my point that flying over roads is too restrictive as well.
We added the bridges and roads over water, since the work specifically focuses on constrained airspace. Currently, the regulations of the Netherlands do not allow for drones to fly over the river (https://map.godrone.nl/). Therefore, making predefined trajectories would make air traffic more predictable and potentially acceptable (refer to line 269).
dynamic (other aircraft) and static obstacles (buildings and geofences) -> dynamic (other aircraft) and static (buildings and geofences) obstacles ?
These urban environments, These aircraft Which these?
They concluded – The project concluded?
The introduction has been updated to clarify these comments. Refer to line 22 and the paragraphs starting in line 23 and 34.
"In a completely decentralised system without any additional constraints, drones will prefer the shortest path to their destination." Drones prefer such paths in any system
That is correct. Line 46 has been updated per this comment.
"Traffic complexity attempts to describe the disorder of the airspace" Maybe "in the airspace"? It’s traffic disorder, not airspace disorder, right?. Since you rightly refer to Metropolis Ii project, it’d be nice to mind the difference between airspace and traffic in it – the better the airspace is managed, the easier it is to manage traffic in it.
Line 49 has been updated per this comment.
Maybe you could link to the unpublished manuscript 19? Why do you need sectors in UTM? In ATM, low-complexity sectors are needed for humans (and sectorless ATM is researched). In fact, I didn’t find where in the paper you do sectors over a city… Still, in the Conclusion, you mentioned sectors again.
Apologies, The bibtex references were a bit outdated. The paper has been already published, so you can refer to the updated reference in the bibliography. We were wrongly using zones and sectors interchangeably. I did not mean them in the same sense as traditional ATM. Therefore, I have updated the paper and removed the word "sectors" when not applicable. Zones refer to areas with high or low density categorisations.
"density of the observed statistic" density of statistic? Is it the probability density of the random variable?
Thank you, this was unclear. We have updated the sentence in line 58. It was meant to say the linear density of the observation (conflict, intrusion, or position).
It’d be nice to see some videos of how your solution works. I didn’t find videos in the supporting material ref 23 (are they the gifs? could be nice to have them immediately available, without the need to download the whole archive)
That is a good idea. We have made the gifs available without
needing to download the archive. While the project is in the
reviewing stages, the repository is available in the temporary link.
Please let us know if it becomes unavailable, as temporary links
are regularly changed by the university. They are in a zip file
called position_heat_map_animations.zip We have also
created a short youtube video with a demo.
4000 what?
This is the Ward cluster distance and is a parameter that must be set in the algorithm. The units are in meters squared when working with Cartesian data (it is a variance). It is the parameter to decide if nearby clusters should be merged. We have reworded the sentences describing it (see line 128).
Please refer to equation 2.
summing the streets – summing the length of the streets?
Yes, refer to line 150 for the updated sentence.
Eq(1). A long street may only touch a convex polygon, incorrectly resulting in a low density value. I’d suggest to sum only the street lengths *inside* the polygon
That is an interesting suggestion. Currently, We assume that any street intersecting would get a label. However, since it is applied to all the three cluster cases, it will not greatly affect the comparative result. Additionally, we did not want to start going into street level for this work, as there are also some streets that are inside polygons but do not actually have any observations. We have added this in the Conclusion for further research (see line 542).
Why categorizing the clusters? It’d look more natural if each cluster simply had cost proportional to its density
At the start of this work, We tried to give more granular cost multipliers. However, We were unable to find the correct proportions that gave significant results. So for this initial research, we decided to keep it with two types of categories (high and low). We added it in the Conclusion that this is a potential improvement (see line 546).
"The longer an aircraft is in the air, the more chance it has of encountering another aircraft." Well, this depends on which density airspace it flies through
That is true, We meant to say it in general terms. However, it does not add any value so the sentence has been removed.
"After the airspace has been classified," Do you classify the airspace? I thought you categorized the clusters (which I thought wasn’t needed)
We were using them interchangeably. For consistency, We are now only using "categorisation".
"This is so that not all aircraft replan at the same time" This is done to ensure that not all aircraft… ? Actually I’d love to see simple examples (real or synthetic) where such unfortunate common replanning happens – will be very instructive (and add value to your efforts of avoiding it)!
Thank you. Other reviewers have also pointed this out. We performed further study on these limits, since they are not in the sensitivity analysis. It seems that because the replans per flight are already quite low (Figure 10), the limits do not make a significant effect. The main thing we noticed was that these limits speed up the simulation time, since aircraft do not need to check for new plans every 10 seconds. However, this is not the intention, so we have reran the simulations without these limits.
Another difference can be seen in the replans per flight. They actually got lower for all cases. In the updated simulations, the aircraft do not have any limitations on finding a new plan, so now they are able to iteratively find a plan. Without the limits, the aircraft continually replan. Sometimes that means undoing a plan and going back to the original plan. This results in less true replans per flight.
Fig3. The reds are not convex, maybe don’t use Cluster in their names.
We have updated the name to be called. Conflict generation area and conflict generation route.
Fig 9. (or another fig): Please show the convex polygons (on a real instance, and refer to it from Fig2).
That is a good idea. Please refer to Figure 12 for an example cluster map. We have added images showing snapshots of the clusters at one single time step during the simulation for the three strategies. Note that this snapshot will change significantly at the next time step (see the cluster temporal stability and percent of clustered airspace).
In the end of the paper, the contribution of an author is Eriting (sic). I first thought it was a clever combination of Editing and Writing. However, this is likely not the case because the parentheses explain that it’s Review and Editing, just as for another author, who has Writing (Review and Editing) in the same place (the authors seem to have identical contributions, except for the Eriting in place of Writing – that’s why I thought Eriting was the intended spelling)
This has been fixed.
The large file size may be not needed (think of compressing hi res images)
We have compressed the images. Hopefully it is easier to load.
Thank you for taking the time to read this paper thoroughly and providing helpful comments. When applicable, I will refer to a highlighted changes in the article.
First it should be noted that the approach is in fact hybrid, as it requires as a first step the centralized real-time observation of the drone fleet positions (and safety events). This is indeed clearly indicated through reference [12]. The originality of the approach is that once the clusters have been centrally defined and transmitted to all aircraft, the path determination and the separation are performed by each aircraft individually (the latter using a speed-based resolution algorithm).
It is correct that the initial step of observing the drones is synthesized and transmitted by a centralised actor. However, we chose to label the overall system as decentralised for the following two reasons. First, similar to how airspace design and rules are typically established by a central agent, our approach requires a centralised observation phase. Second, once the clusters are defined, the agents independently determine their new paths. By defining our approach as decentralised, we emphasize the decentralised nature of the drone decision-making. This would be similar to how Google maps provides the high traffic areas, but they do not decide which route cars take.
The clustering is performed every 10 seconds (line 98). The choice for the value of this update rate seems to be quite arbitrary and it is not investigated in the sensitivity analysis. It could be interesting to provide an explanation or to indicate that it could be investigated in future work, as it may have an impact on clusters stability (despite the re-plan limits) as well as computational and data transmission load.
The 10-second update rate was selected based on previous similar works [12][19], which demonstrated results with the same update rates. However, in these works, the choice is also rather arbitrary. To address this concern, we have added a discussion item in the paper acknowledging that it requires further study (see line 548).
The clustering strategies based on complexity indicators use events that have occurred in the past ten minutes, while the position based strategy only use the current position. While the ten minutes window sounds reasonable to gather the safety events, one could wonder why the position based strategy does not also use a similar window to evaluate the traffic density. Smoothing the density would perhaps limit the recursive effect reported on lines 190-194, with the current positions of the blue aircraft interfering with the clustering. This point could be worth investigating.
That is an interesting point. However, I think using a time window for the density would make it more of a complexity indicator, as it would highlight areas where aircraft tend to converge in the airspace. Nevertheless, it could be worth investigating. We have added a discussion item to highlight this idea for future research (see line 530).
It is indicated that the result of the observation is a simple 2D vector (line 108). It may be worth briefly explaining the content of this vector (coordinates of either the aircraft positions, conflicts or intrusions?).
Further explanation on the observation vector has been added (see line 116) and equation 1.
The Ward cluster distance is defined as a squared Euclidian distance, so that the value of 4000 should correspond to 63 meters, rather than 100 meters (line 118). This should be clarified (no cue found in the sensitivity analysis).
Thanks for pointing this out. It is actually defined as half of the squared Euclidean distance, so that is about 90 metres. We have added an equation to the paper to clarify it (see equation 2). The ward cluster distance can be implemented in different yet similar ways. Some implementations do not divide by two, but some do. We have confirmed that the sci-kit learn implementation does contain the 1/2 factor (link). We have also clarified the meaning of the Ward cluster distance in line 128.
It is indicated that the cluster in the lower 25th percentile are classified as low-density (line 145), while the sensitivity analysis concludes instead that the 75th percentile provides the lowest number of intrusions per flight. This should be clarified.
This is indeed confusing. We meant to say that the 25th percentile is classified as low density, which means that it does not receive an additional cost multiplier. The other 75 percent would have an additional multiplier. This is the number that is plotted in the sensitivity analysis and was incorrectly labelled. We have updated the sensitivity analysis to match the article.
It is asserted that there are usually fewer conflicts than intrusions (line 187). This may seem counter-intuitive, and thus a rationale would be welcome to clarify whether it is a general statement or if it is simply an observation on the particular network and traffic of the first example scenario.
Thanks for finding this error. It meant to say that there are usually fewer intrusions than conflicts (see line 204). Ideally, a conflict is solved before it becomes an intrusion.
The conflict resolution uses a protected radius of 32 meters (line 279), referring to ICAO annex 10 GNSS performance requirements. A short rationale should be added to explain the link between the chosen value and the ICAO reference.
We have added a short explanation as to why this 32 metres is chosen (see line 310).
It is indicated that each simulation scenario runs for 2 hours. This duration depends on the computer performance which could be indicated to help the reader understand whether the computational cost is high (or not). Also the actual duration of the scenario (in real time) should be indicated, assuming that a minimum duration is probably required to obtain stable results.
This has been clarified. The simulated time of the scenario is 2 hours. However, the real time needed to simulate 2 hours is less than that because these are fast-time simulations. Clarifying statements have been added in line 328.
The results are clearly presented and their interpretation leaves not much doubt, even if the statistical significance is not tested.
We have added statistical testing, please refer to the Appendix. Note that we had to increase the number of random seeds from 5 to 20 for statistical significance.
In order to ease the reading, the discussion could be better organized. First the safety aspects could be addressed, grouping the paragraphs relevant to hypotheses H1, H2 and H3, then the efficiency and clustering metrics.
Thanks for this comment. This was also a point of discussion between the authors during the writing phase. One draft did have the discussion structured as you suggested. However, it was difficult to keep the separation, which is to discuss safety aspects in the safety section and efficiency metrics in the efficiency sections. We have modified the discussion, so hopefully it is now easier to read.
Typos are noticed on lines 6, 34, 432, 433, 481, 492. Also note that reference [31] is now published (DOI missing).
Thank you, We realized it was an old bibtex database. We have updated the reference and have fixed the typos.
Thank you very much for the helpful and insightful comments. I will respond to them below and refer to highlighted parts of the paper.
Throughout the paper, the authors use the terms "separation management", "traffic management" and "airspace sectorization" interchangeably to describe the proposed method. If the main objective of the method is to manage aggregate traffic flows, without necessarily solving conflicts between individual 4D trajectories or defining airspace sectors, I believe the term "traffic management" (or "demand-capacity balancing") looks more appropriate to describe the scope of the research.
The paper has been modified and now only refers to this concept as "traffic management". It has also been highlighted in the title.
How is the protection zone in Figure 1 defined? It is not presented in the text. In Section 3.2.4, it is important to clearly state and provide a foundation for the separation distance criteria considered. I assume it is 32 m based on "horizontal protected radius of 32 metres".
More information has been added in line 90 relating to Figure 1. Moreover, we have added more information relating to the separation distance starting in line 310.
In Section 3.2.4, it is stated that "The drones in this work use a tactical speed-based conflict resolution algorithm from [31] to solve conflicts in constrained airspace." I suggest clarifying whether this is integrated with the proposed rerouting strategy or if these tactical conflict management approaches are treated independently.
The tactical conflict resolution algorithm is independent of the dynamic traffic management method. This has been clarified in line 313.
On page 4, line 118, it is stated that "This work sets a cluster distance of 4000, which is about 90 metres (3 times the minimum separation distance of drones)." This needs further explanation. Moreover, is the same cluster distance applied in the three clustering strategies?
We have clarified the meaning of the cluster distance. Also, the reference to the separation distance has been removed, because it is not relevant. Please refer to the explanation starting on line 128.
Figure 4 is not very clear. Do the blue arrows represent the trajectory of a single flight or do they indicate positions for different flights? The polygon lines in different colors in panels (b)-(d) are also unclear. Do these polygons represent the clusters identified? What do the different colors indicate? For instance, in panel (b), why are there two red polygons? I recommend providing a more detailed explanation of this figure in the text to clarify these aspects. I also suggest increasing the width of the polygon lines for better visualization.
Figures 4 and 5 have been clarified. Note that the arrows represent individual aircraft. The polygons have been removed as they did not provide useful information for the figures.
The hypotheses in Section 3.1 have been assessed and discussed based on the box plots of simulation results. Formally presenting the statistical analysis results for hypothesis testing is recommended.
The appendix now includes statistical testing. Note that this required additional (from 5 to 20) experiment repetitions to achieve statistical significance.
In Figure 10, the distance percentage and replans increase with the demand levels for the intrusion-based clustering strategy. However, the opposite is observed for the conflict-based and position-based clustering strategies. This seems counterintuitive. Do the authors have any insights on what might be driving these different behaviours?
This is because of the low amount of intrusion events observed at low demand levels. This means that there are not many clusters and aircraft are not forced to replan. This point has been stated in line 494.
In Section 5, the authors discuss the pros and cons of the different clustering strategies. I suggest adding a clear statement of the recommended approach for traffic management based on the results obtained.
We wanted to steer away from giving a complete recommendation as the method still needs further research. However, we have attempted to clarify that the conflict-based strategy was the most successful in line 525.
On page 16, line 433, "has a both a high percent" appears to be a typo.
Thank you, this has been fixed.
Thank you for the helpful comments. Whenever relevant, we will refer to the updated changes in the text. Most changes appear highlighted in the article.
Page 3 line 98: the authors should provide some explanation on how 10 seconds is chosen. Is based on the computational requirements of the methodology or is it a suitable time based on some experiments? I think this time should also depend on the characteristics of the aircraft such as speed.
We have clarified that it was taken from previous work (see line 106). However, we realise that this needs further research. Therefore, it has been added to the Conclusion in line 548 as a point of further research.
Is there a possibility where the clusters overlap?
It is very possible that clusters intersect and share the same street. The method assigns the street to the cluster in which its largest segment is contained (see line 152).
Replanning is allowed once every 30 seconds, with a 50% probability of following the new plan. What is the basis of this time duration, and how would this be affected by the density of traffic?
This was initially a method to ensure that not all aircraft replanned at the same time. However, it was noticed that the replans per flight are quite low. Therefore, we made new experiments without such limits and noticed that these limit did not change much. It did show one interesting change. The replans per flight actually got lower for all cases. In the updated simulations, the aircraft do not have any limitations on finding a new plan, so now they are able to iteratively find a plan. Without the limits, the aircraft continually replan. Sometimes that means undoing a plan and going back to the original plan. This results in less true replans per flight.
Figure 5, page 8: how does the dynamic management methods show advantage in this case – it seems that now the red drone must perform conflict avoidance from two flows of blue drones instead of one in the baseline case.
That is correct. However, the goal of the example scenarios was to focus on the benefits to the blue aircraft. The role of the red aircraft in both scenarios is only to generate problem areas. In fact, the red aircraft are not allowed to replan in the example scenario 2. This has been stated in line 216.
How representative is Rotterdam airspace model for other urban environments with different geographical and architectural features?
One way to describe a street graph is with the bearing entropy (link). The Rotterdam network has a bearing entropy of 3.566 which is similar to Paris. At the moment, this has not been highlighted in the paper.
How were the seeds selected for the experiments. And do they adequately cover the variability in the traffic scenarios?
The random seeds were randomly selected with the python random library. This has been clarified in line 325. Moreover, we have added 15 more random seeds to ensure we cover the variability of the scenarios.
Figure 8: the figure show traffic demand v/s conflicts per flight. Does it mean conflict per drone? In other words, for a traffic of 100 drones, there would be on average 1.5 conflicts per drone. Isn’t that significantly high?
Yes it is conflict per drone. In this work, we do not consider the absolute values of conflicts and intrusions. We are more interested in the relative differences between the concepts. Although we chose a separation distance of 32 metres, this may not what is used in reality. In fact, a lower separation distance would lead to lower conflicts and intrusions. Additionally, in tactical conflict resolution, conflicts are a main way to communicate with other drones. So conflicts in themselves are not inherently bad. Please refer to line 339.
Further, what are the operational traffic levels? I ask this since the methods show almost similar performance level (figure 8 a) for almost all traffic demand levels.
The traffic levels are currently shown in terms of number of
aircraft in the air. However, in the supporting documentation,
they are shown in terms of take-offs per minute. Note that in
general, the take-offs per minute scale with the demand level. At
the lowest demand level, there are about 10 take-offs per minute,
while there are around 50 in the highest demand level. You can see
this plot in the following temporary link.
Please let us know if it becomes unavailable, as temporary links
are regularly changed by the university. Please refer to the
main_experiment_box_plots.zip file.
Are the number of replans based on the requests made or executed number of new plans (since it is a probability)?
Note that we have removed the probability and time limits. The results show only the executed replans per flight. In practice, the drones request many more replans during the simulation. However, many times the plan changes before they are executed. The supporting documentation also shows the number of requested replans per flight. This also been clarified in line 355.
How does this methodology compare to the existing centralized or other decentralized methodologies?
Indeed, this is an interesting question. This requires further research and has been added in line 534.
Most of my comments have been addressed, except for specifying that the paper deals with drones above roads:
"constrained urban airspace" is more general than "drones flying above roads", so having the former in the title instead of the latter imho oversells the paper’s scope
Some revisions keep the text ambiguous. For instance, you added "of the network" in line 53. Which network? The previous time the word "network" appeared was on line 29, which is too far to remember. Moreover, in line 53, the "network" comes out of the blue together with the "intersections" (your revision was in response to my question about what you meant by intersections). I feel that for you, "constrained airspace" = "above road network", while the latter is a special case of the former. Please proofread the paper to avoid such misunderstandings.
"The street layout of Rotterdam contains some additional constraints due to the limited number of bridges that connect south to north." -> constrainTs
Which additional constraints? What are the non-additional constraints? Your one and only constraint is to fly over roads, isn’t it?
"To address this, several new drone "bridges" have been proposed, as this work focuses on navigating constrained airspace" Run your experiments without the added bridges: as you argue, you can fly only over existing roads
I understand that adding shortcuts (new "roads") improves things, but adding the best shortcuts in a network is an interesting research topic in itself. Your results in this paper should not depend on a poor choice of shortcuts (or maybe you were smart and your shortcuts are very good – still, your results should not depend on shortcuts)
"As current regulations in the Netherlands do not permit drone operations," Did you mean to say over water? In your response, you say, "Currently, the regulations of the Netherlands do not allow for drones to fly over the river."
Thank you for changing the text to "Drones will always prefer the shortest path to their destination when there are no additional constraints". But my comment still applies: drones will prefer shortest paths even if there are additional constraints.
Also, additional to which? What are the non-additional constraints?
The link has expired (not your fault, I understand), but the video is very nice – consider linking to it from the paper.
Thank you for your helpful follow-up comments. Most changes from the original submission are highlighted in yellow. Typos are not highlighted unless the sentence changed significantly.
Most of my comments have been addressed, except for specifying that the paper deals with drones above roads: "constrained urban airspace" is more general than "drones flying above roads", so having the former in the title instead of the latter imho oversells the paper’s scope.
That is a fair point. We do not want to mislead the reader, therefore, in the abstract we have tried to reword it to make it clear that we consider constrained airspace as following a virtual network. This also how we have defined it in previous works, like Metropolis II.
Some revisions keep the text ambiguous. For instance, you added "of the network" in line 53. Which network? The previous time the word "network" appeared is on line 29 – too far to remember. Moreover, in line 53, the "network" comes out of the blue together with the "intersections" (your revision was in response to my question what you meant by intersections). I feel that for you "constrained airspace" = "above road network", while imho the latter is a special case of the former. Please proofread the paper to avoid such misunderstandings.
We have gone through the paper and tried to clean up the terminology. When we refer to the network in the air, we now call it a virtual network. This also means referring to the airspace segments as edges instead of streets. Also, we have added a figure in the Introduction that illustrates a virtual network so that it is clear for the reader what we mean by intersections.
We also agree that in general, "constrained airspace" is not always "above road network". We have now tried to make it clear that for our case we define it as such. Please refer to the abstract and the paragraphs starting in lines 23 and 32 of the introduction.
"The street layout of Rotterdam contains some additional constrains due to the limited number of bridges that connect south to north."
constrainTs
Which additional constraints? What are the non-additional constraints? Your one and only constraint is to fly over roads, isn’t it?
Please refer to the updated paragraph starting in line 263. We have removed this sentence and tried to clarify that when aircraft fly over land, the virtual network aligns with the street network and when over water, they fly along predetermined routes.
"To address this, several new drone "bridges" have been proposed, as this work focuses on navigating constrained airspace"
Run your experiments without the added bridges: as you argue, you can fly only only over existing roads
I understand that adding shortcuts (new "roads") improves things, but adding the best shortcuts in a network is an interesting research topic in itself. Your results in this paper should not depend on a poor choice of the shortcuts (or maybe you were smart and your shortcuts are very good – still, you results should not depend on shortcuts)
That is a fair concern. However, removing the drone bridges would only leave three links between north and south and a one-way network may no longer be strongly-connected. We have gone through the paper to make the terminology clearer. Refer to the changes in the Abstract, Introduction and in Section 3.2.1.
You are correct that the method should be independent of the virtual network. Therefore, we have made some additional sensitivity experiments in the airspace of Vienna (from Metropolis II). This airspace does not contain any shortcuts through water. The results are fairly comparable to what we saw in Rotterdam, with about 25 percent less intrusions and around 7 percent more distance travelled when using the conflict-based strategy. We will upload the sensitivity analysis to the submittal in case the supporting dataset does not work. Here is an updated link to the supporting dataset.
"As current regulations in the Netherlands do not permit drone operations,"
Did you mean to say over water? In your response, you say
"Currently, the regulations of the Netherlands do not allow for drones to fly over the river"
Yes apologies, that is what we meant. We have reorganized section 3.2.1 to address this issue.
Thank you for changing the text to
"Drones will always prefer the shortest path to their destination when there are no additional constraints"
but my comment still applies: drones will prefer shortest paths even if there are additional constraints.
Also, additional to which? What are the non-additional constraints?
That is correct, the sentence has been removed from the introduction to clean up the terminology of constrained airspace and virtual networks.
The link has expired (not your fault, I understand), but the video is very nice – consider linking to it from the paper?
That is a good idea, thank you. We will link the video (line 601).