Hi BW
I think it's "C" but with some caveats. Here's how I understand it:
I think the 2 points to note are
1. The difference between a “database overlay” and a “published overlay”
If the overlay is published, then it is a normal published procedure. The fact it’s called “overlay” is informational – it tells you it is not a native RNAV procedure and that it follows a conventional procedure. This is important information because in the event of an RNAV failure, the pilot knows there is a conventional back-up.
A published overlay should not be confused with the database depiction of a conventional radio procedure (ie. a “database overlay”). The latter is purely advisory for most GA operators (I know little about the case of getting operational approval to fly database overlays) and any conflict between the database overlay and the radio procedure must be resolved by following the published radio procedure, as FE Hoppy says.
2. The naming of the procedure
From an ATC clearance point of view, the procedure is uniquely specified by the published name in RTF and database designator in the case of FPL transmissions (ie. Norevenich Seven Echo and NOR 7E respectively)
If, in the case of a conventional procedure and published overlay, the procedure name is the same, then the pilot may elect which to fly. One would expect the differences to be trivial from an ATC point of view – which they are in the case of the NOR7E and that the use of either alternative complies with the separation and terrain/airspace rules to which traffic is worked. It’s a bit like a Cat A/B vs Cat C/D depiction on an approach – ATC don’t always necessarily know which one you’ll fly and it doesn’t matter to them.
One reason for the difference is that the conventional leg from LV to 7.2d is an “FD” Path-Terminator (fix to DME distance) which is not an RNAV type – ie if used in an database overlay, many FMS would not support it other than as a “Pilot Nav” leg. It is more desirable to use a Track-to-Fix path-terminator (TF), which is what has been done in the published overlay.
It’s actually a sensible solution when there are reasons not to have distinct RNAV procedures (perhaps traffic complexity or just the hassle of design and environmental consultation?). What ATC are saying is “we are happy that the Overlay we’ve published is sufficiently similar to the conventional version that the two are identical for our purposes. However, for pilot purposes, the published overlay may be preferable and we’ve tweaked it to make it a better procedure than a ‘straight’ database coding of the conventional one”. There is also likely to be an improvement in track accuracy and consistency for considerations such as noise abatement.
brgds
421C