The 24 NM diameter (!) of each of the SIX Overlapping PJE’s in the screenshot below gives the initial impression the entire area should perhaps be avoided, however the associated NOTAM for each clearly stated the drop zones are conical.

Avoiding the promulgated cones of such drop zone conglomerations would be far easier — and relatively safer — if the cones lateral extents were accurately depicted on the SD chart.

Any argument that such areas are simply best avoided does nothing for those pilots who have aircraft permanently based within the lateral extents of massive volumes of such NOTAM’d airspace, when compared to, for example, the efficiency by which SD facilitates the navigation of a complex controlled airspace corridor.

That articles or personnel *may* fall outside the drop zone cone, as I vaguely recall a recent argument went in favour of the current cylindrical depiction on SD’s Facebook discussion — fails to recognise that ultimate responsibility for navigation rests with the PIC, and in this respect SD is merely a tool for facilitating such decisions by the PIC.

In the same vein that flying right up to the lateral limit of controlled airspace might be considered poor airmanship, flying in close proximity to the lateral extent of a NOTAM’d drop zone might also be considered bad airmanship. In the case of former, the margin by which a pilot does so is clearly evident to a pilot utilising SD, whereas in the latter, a pilot using SD may only ‘eyeball it’.

I'm sure the response will be that the 'area of affect' as coded in the NOTAM is just a circle of x nm centred on point y. It's only the free-form text that describes the 'conical' shape of the actual NOTAM. It would be nigh-on impossible to parse this reliably I would expect.

Andy, thanks. After reviewing https://en.wikipedia.org/wiki/NOTAM#Example I do now finally see what Tim was talking about, when I raised the topic some time back: the limitation of the codification possible in a NOTAM's Q) field.

Nevertheless, two points:

The following NOTAM, for Manchester Airport today, has an effective radius of 5NM without 'by default' a 10NM diameter ring being depicted – so SD does already implement some sort of filtering in the 'depiction engine' as it only appears in SD in textual form:

Q) EGTT/QLXXX/IV/M/A/000/999/5321N00217W005

B) FROM: 20/03/23 16:40C) TO: 20/06/20 23:59

E) TWY DELTA UNLIT DIVERTED CENTRELINE BETWEEN HOLDING POINTS D2 TO

D3 AND P4 TO D3 DUE WIP. FOLLOW ME SERVICE IN DAYLIGHT HOURS

PROVIDED UPON REQUEST FROM CREW OR ATC. FOLLOW ME PROVIDED FOR ALL

MOVEMENTS IN HN AND LVP CONDITIONS.

What's to stop SD using a little Regex to extricate the finer detail from the NOTAM E) 'free-text' field – particularly when this info is so frequently provided in very consistent form, at least within national boundaries? In the case of those few PJE NOTAMS using a different phraseology in the free-text field E), then continued use of the current depiction would of course suffice.

I appreciate there'd be some work involved, however I can't help feeling it would make a worthy contribution to flight safety by further assisting in enhancing pilot SA; especially as PJE zones occupy a not-so-inconsiderable extent of airspace, and often during those days on which the weather is forecast to be particularly good for VFR/VMC ops: SD's target market as I understand.

Andy, thanks. After reviewing https://en.wikipedia.org/wiki/NOTAM#Example I do now finally see what Tim was talking about, when I raised the topic some time back: the limitation of the codification possible in a NOTAM's Q) field.

Nevertheless, two points:

The following NOTAM, for Manchester Airport today, has an effective radius of 5NM without 'by default' a 10NM diameter ring being depicted – so SD does already implement some sort of filtering in the 'depiction engine' as it only appears in SD in textual form:

Q) EGTT/QLXXX/IV/M/A/000/999/5321N00217W005

B) FROM: 20/03/23 16:40C) TO: 20/06/20 23:59

E) TWY DELTA UNLIT DIVERTED CENTRELINE BETWEEN HOLDING POINTS D2 TO

D3 AND P4 TO D3 DUE WIP. FOLLOW ME SERVICE IN DAYLIGHT HOURS

PROVIDED UPON REQUEST FROM CREW OR ATC. FOLLOW ME PROVIDED FOR ALL

MOVEMENTS IN HN AND LVP CONDITIONS.

What's to stop SD using a little Regex to extricate the finer detail from the NOTAM E) 'free-text' field – particularly when this info is so frequently provided in very consistent form, at least within national boundaries? In the case of those few PJE NOTAMS using a different phraseology in the free-text field E), then continued use of the current depiction would of course suffice.

I appreciate there'd be some work involved, however I can't help feeling it would make a worthy contribution to flight safety by further assisting in enhancing pilot SA; especially as PJE zones occupy a not-so-inconsiderable extent of airspace, and often during those days on which the weather is forecast to be particularly good for VFR/VMC ops: SD's target market as I understand.

Hamish

Aside from the complexity of actually coding it to cater for misprints, lack of standard english and missing info, surely the point of depicting the NOTAM on the chart is to draw your attention to reading it, not to absolutely define it?

There could be other information in there which would be missed if it became a common practice to assume that all NOTAM circles drawn on the chart are a) correct b) all you have to worry about, and doing what you suggest nudges the users one step towards behaving like that.

grahamb, Your point about 'misprints, lack of standard english and missing info' could be adequately handled by the current 'standard depiction'. It is my firm impression however, that the NOTAM'd description of PJE zones of conical form is very much standardised, at least in the UK; and that ought to make the machine translation into graphical form of a significant number of PJE drop zones very much more straightforward.

That in turn, might even encourage other jurisdictions 'guilty' of issuing poorly worded NOTAMS to up their game. Especially as the NOTAM system itself has come under considerable flak in recent times including at least one high profile NTSB incident report: https://en.wikipedia.org/wiki/NOTAM#Criticism This in fact suggest to me that it's the issuance of poor quality/ non-standardised NOTAMS that should be tackled, rather than waiting until the next incident in which the wording of a NOTAM is deemed a contributing factor. But I digress...

In your second point, you appear to be implying that we should also be checking the accurate plotting of all NOTAMS already depicted graphically. Beyond a gross error check, I leave it to the software. After all, this task is exactly what the computer does best – otherwise, why delegate it to any extent to a graphical NOTAM plotting tool? Even UK CAA/NATS long ago came out in favour of using moving maps as a tool for substantially improve SA in avoiding airspace, so why should a drop zone – a temporary airspace as it is, already with a reasonable but significant safety margin built in – be considered any different in the accuracy by which it is depicted?

We can (by-and-large) train people to avoid doing the stupid, but lazy types, well trained or otherwise, will eventually return to flight planning in a lazy fashion. SD can never prevent that, but it would be great to see it improved upon in areas pertaining to its primary function: facilitating and improving SA. It can only takes a small distraction to loose SA in a busy aviation environment – especially so for the less experienced pilot – however getting one's SA back once lost (what, or who ever may be the cause) is made substantially less daunting, if not child's play, by having accurate, easily interpreted visual data immediately to view, as SD so well provides.

grahamb, Your point about 'misprints, lack of standard english and missing info' could be adequately handled by the current 'standard depiction'. It is my firm impression however, that the NOTAM'd description of PJE zones of conical form is very much standardised, at least in the UK; and that ought to make the machine translation into graphical form of a significant number of PJE drop zones very much more straightforward.

That in turn, might even encourage other jurisdictions 'guilty' of issuing poorly worded NOTAMS to up their game. Especially as the NOTAM system itself has come under considerable flak in recent times including at least one high profile NTSB incident report: https://en.wikipedia.org/wiki/NOTAM#Criticism This in fact suggest to me that it's the issuance of poor quality/ non-standardised NOTAMS that should be tackled, rather than waiting until the next incident in which the wording of a NOTAM is deemed a contributing factor. But I digress...

In your second point, you appear to be implying that we should also be checking the accurate plotting of all NOTAMS already depicted graphically. Beyond a gross error check, I leave it to the software. After all, this task is exactly what the computer does best – otherwise, why delegate it to any extent to a graphical NOTAM plotting tool? Even UK CAA/NATS long ago came out in favour of using moving maps as a tool for substantially improve SA in avoiding airspace, so why should a drop zone – a temporary airspace as it is, already with a reasonable but significant safety margin built in – be considered any different in the accuracy by which it is depicted?

We can (by-and-large) train people to avoid doing the stupid, but lazy types, well trained or otherwise, will eventually return to flight planning in a lazy fashion. SD can never prevent that, but it would be great to see it improved upon in areas pertaining to its primary function: facilitating and improving SA. It can only takes a small distraction to loose SA in a busy aviation environment – especially so for the less experienced pilot – however getting one's SA back once lost (what, or who ever may be the cause) is made substantially less daunting, if not child's play, by having accurate, easily interpreted visual data immediately to view, as SD so well provides.

It's a well known fact that the 'radius of influence' on the Q line may not actually be that of the affected area itself. I regularly encounter people who glance at the chart and think that they can't breach the plotted area, when in fact they can.

I still maintain that a through self-brief of the NOTAM text should be carried out. Just looking at circles on the chart and assuming you can't go in is lazy, inefficient and poor airmanship. Having said that, as regards PJE's like this, it's a fail-safe method of depiction. If it were coded to reflect reality, and for some reason, e.g a poorly worded NOTAM that slipped through the parser and left out a step, someone might infringe with serious consequences

If the PJE layer cake is so obvious to you, why is it causing you a problem that its depiction is simplified?

Please ignore the last line of my posting above, it is unnecessarily confrontational, and not intended to be rude. For some reason I'm unable to edit it out.

Thanks. No offence taken - I'm very happy to debate the detail and justification. Time permitting, a fundamental part of good two crew CRM is about discussing options – and in the comfort of this forum we have plenty of time.

> It's a well known fact that the 'radius of influence' on the Q line may not actually be that of the affected area itself.

Quite; as in, 'Quite surprising when one first discovers just how sloppy the NOTAM system codification is in many respects, isn't it?'.

> I regularly encounter people who glance at the chart and think that they can't breach the plotted area, when in fact they can.

This only further highlights how behind the times and dysfunctional the NOTAM system itself has become. i.e. The inability of the NOTAM system to accurate codify 3D airspace should be seen as shortcoming that needs rectifying, not something we should accept 'because that's the way its always been'; especially in view of recent incidents highlighting the overall poor usability of the NOTAM system.

> I still maintain that a through self-brief of the NOTAM text should be carried out.

I'm not suggesting otherwise.

However, now lets just up the time pressure your under to do that thorough self-brief, such that you're able to reliably recall the useful details at the appropriate moment in flight: Lets say you're engaged in commercial GA jet ops doing four flights a day with a one hour turn-around time or less between flights, in and out of multiple, often unfamiliar or infrequently visited international locations, with variable quality aviation english spoken by the local Radio/FISO. Under those circumstance, any accurate mapping tool you can lay your hands helps improve flight safety immensely, for everyone's sake, by freeing up mental capacity to deal with anything else that may come at you, out of the blue.

> Just looking at circles on the chart and assuming you can't go in is lazy, inefficient and poor airmanship.

Also, 'Quite'. But wouldn't your confidence in your position relative to and whilst inside this 'hazardous airspace' be much improved if it were accurately plotted on SD – just like it currently is, relative to all the other avoid/danger/restricted/controlled airspace for which we happily rely on SD having accurate data to depict.

> Having said that, as regards PJE's like this, it's a fail-safe method of depiction.

And if that's the best that can be done, fine, this would continue to be the fail-safe depiction method.

> If it were coded to reflect reality, and for some reason, e.g a poorly worded NOTAM that slipped through the parser and left out a step, someone might infringe with serious consequences

Correct me if I'm wrong, but I can't see a problem in creating a fail-safe parser: it could simply be that two data points per layer (radius and altitude) are required up to the level specified in the Q) field – and if either or both radius or altitude wasn't present in any data-pair, then that layer, or the entire 'cake' defaults to the failsafe depiction. But as mentioned earlier, it is my firm belief that the description for PJE cones is coded very consistently, at least in the UK, so the even more conservative approach would be to simply test the free text description for the existence of the entire group of characters defining the cone dimensions.

Do you have any evidence that these cones are actually created to a strong specification? If they were, we could conceivably implement a parser, but all my experience tells me they are almost certainly not. That means the parser would need to be forgiving, which means it's open to getting it wrong if the person writing the NOTAM deviates from the spec or makes a typo.

Coupled with the fact that it's only the UK that publishes such NOTAM, and even then not many in a given year (I can't see any right now) and the points Graham has raised, it isn't something that's anywhere near the top of our priority list.