Why Altitude Angel have invested in building the necessary real-time data processing technology for one of aviation’s most important international systems, and why other big names in the business often get this wrong.
The consequences of less accurate – but common – NOTAM data processing are potentially very severe, particularly in the context of ongoing talks in the UK and around the world, requiring citizens to use ‘safety apps’ and giving new enforcement powers to police officers. Any enforcement or regulatory activity based on inaccurate data could, in many scenarios, give an officer the impression a flight is operating in an illegal area when in fact it is not. Any drone pilot making a decision about where to fly using such inaccurate data is increasingly likely to find themselves at odds with the law, potentially increasing the risk to people on the ground or in the air.
On April 18th, 2018, a large Temporary Flight Restriction (TFR) is going to become active over London. When companies process this data and it appears in maps and data feeds relied upon by drones and drone operators, it’s crucial this data is processed accurately. However, as we’ll show in this post, it’s not uncommon – especially in the drone ecosystem – to find that most companies don’t take the right steps to process the data correctly.
First, if you don’t already know much about NOTAMs, you should read our brief explainer on what a NOTAM is. We’ve also dotted-in some extra detail on the technology we’ve built specifically to extra the most accurate interpretation of the shape described by the NOTAM, which is often the step that most companies skip out on. Why? Because (for some) its hard to do accurately and correctly, especially via automation.
As data becomes a fundamental requirement for accurate (and safer) air navigation with the increasing use of drones, especially with beyond visual-line-of-sight at stake, it’s time to start raising the bar in the drone (or ‘UTM’) sector, because depending on inaccurate data is not just inconvenient, it’s potentially very, very dangerous.
What is a NOTAM?
NOTAM is an abbreviation for Notices to Airmen, a written notification issued to pilots before a flight, advising them of circumstances relating to the state of flying. NOTAMs are important because they communicate changes to the circumstances affecting flight in a particular volume of airspace, which pilots need to check before the fly. The challenge with NOTAMs is that they are predominantly words describing three-dimensional shapes.
NOTAMs do actually contain a small section of structured data which can be easily ‘understood’ by a computer program tasked with the job of drawing shapes. The structured data also includes the timing that the change comes into effect, too.
The problem is that this structured data is very low precision – the shape over the ground is a circle whose radius must be in whole nautical miles and the centre is described as a latitude/longitude, but only in degrees and minutes (meaning it could be inaccurate up to 1 kilometre over London).
Let’s look at how our automated precision NOTAM-reader works, in the context of this very large TFR coming into effect over London in a few days’ time.
Processing NOTAM data – the easy (far less accurate – but more common way)
In the case of the forthcoming NOTAM over London, the structured data (or ‘Q line’, as it is known) is contained in the NOTAM as follows:
Q) EGTT/QRTCA/IV/BO/W/000/025/5128N00012W011
When processed by a computer, it describes a circle with radius of 11 nautical miles, centred at coordinates 5128N00012. It’s easier if we draw that for you, to help you visualise the shape that is described by that line of structured data:
That large, blue circle over London is the shape described by the ‘Q’ (machine-readble) line in the NOTAM. It’s like the shell of a coconut: you have to crack it open to get at the good part inside, and that’s essentially the part we do next (and it’s the part that most other companies operating in a similar space to us don’t go on to complete, or complete well).
Plotting NOTAM data accurately (the best way, but far less common)
To combat the lack of precision in the machine-readable ‘Q’ line, there is another part of the NOTAM which is called the ‘E line’. This E-line is unstructured, free text. As you can imagine, there is no common standard for how one goes about describing a shape or a particular set of restrictions and conditions that apply to it in an unstructured chunk of text data.
Let’s look at the (much lengthier, but more detailed) E-line for the same NOTAM:
|
In this block of text, the parts we are really interested in here are quite difficult to find to the naked eye. But, our sophisticated ‘machine-learning’ algorithms have already spotted the important part:
|
The take-away here is, the E-line describes a shape that is absolutely not a cylinder, as described by the Q-line. Let’s take a look at what our NOTAM processing engine has actually gone on to draw, automatically:
Quite a difference, right?
In fact, if we run a geospatial comparison between the shape most companies show (described by the Q-line), and the shape we show you (described by the ‘hard-for-a-computer-to-read’ E-line), the area shaded in blue (below) is the area you are misinformed that the restriction applies to:
That's 554 million square metres of airspace you are actually allowed to fly in, which you'd otherwise not know if we didn't go to such extreme lengths to make our data the most accurate available.
There are large fines (not to mention potentially serious consequences for others on the ground or in the air) for flying in restricted airspace and a NOTAM could be published at any time, so always check our app, or embed our data into your solution, before you fly!
A NOTAM should form part of any digital safety or enforcement solution and so an enforcement officer that uses tools or apps that use the far-less accurate mechanism for processing this data is going to be under the assumption you’re flying illegally, when in fact, you might not be. That’s one reason that we work so hard to ensure this data is accurate.
If you’re wondering how you can incorporate our accurate data into your own drone app, drone hardware or navigation solution, you can get started easily using our Developer Portal. We build our APIs with ease-of-use and data standardisation in mind, so you can be assured that the data will be as easy for your developers to incorporate as it is accurate!
|