"No altitude assigned" message

[erikquinn]

from @panther2 on v3.2.0:

I have tested EDDM, EDDT and EDDF as well as EGLL departures:
Athough clearing departing planes with
id taxi
id caf
id to
I get a "no altitude assigned" message.

It works as expected at KSFO. I did not test other airports.
Is the functionality in any way limited in the environment?
Or have I encountered a bug?

[erikquinn]

@panther2 I'm not seeing this issue. Could you verify that there is indeed a problem? When I follow the above steps at EDDM, they take off normally for me.

[panther2]

That's strange.

I just went to
https://atc-release.herokuapp.com/
changed to EDDM
and repeated the above steps again.
Again "no altitude assigned"

Works fine at KSFO. At KSFO the indication on the strip changes from for example MOLEN7 to MOLEN7.ENI after the caf command. This does not happen at EDDM, either. For example OLASO does not change to OLASO.OLASO

I cannot assign SID's, either. When entering sid TULSI for example the answer is
"unable, the TULSI departure not valid from Runway 26L"

It works perfectly on https://zlsa.github.io/atc/
Here OLASO changes to OLASO.OLASO after caf.

I have now also tested it using a different notebook with ChromeOS.
I am seeing the same issue here, too.

[n8rzz]

I can reproduce this on release and dev with EDDM. Super quick guess is this stems from all the work I did on n8rzz#53. Some parts of it I have reverted as part of n8rzz#114 because of some incorrect assumptions I made.

Still digging.

[eliuuk]

It actually should not become OLASO.OLASO anyways, the .blah is for a transition name, normally

…

On 13 Dec 2016, 22:01 +0000, ***@***.*** ***@***.***>, wrote: That's strange. I just went to https://atc-release.herokuapp.com/ changed to EDDM and repeated the above steps again. Again "no altitude assigned" Works fine at KSFO. At KSFO the indication on the strip changes from for example MOLEN7 to MOLEN7.ENI after the caf command. This does not happen at EDDM, either. For example OLASO does not change to OLASO.OLASO It works perfecty on https://zlsa.github.io/atc/ Here OLASO changes to OLASO.OLASO after caf. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#760 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ASgmWAuQLsDSCbQ0atfakBTW9rtCb9Zaks5rHxWigaJpZM4LMRC8).

[erikquinn]

yeah, sorry you're completely right. I accidentally went to zlsa.github.io/atc. I'm a dummy! This issue is definitely valid.

[panther2]

Thanks for your confirmation.

[n8rzz]

tracked this into runSID and it is failing silently here:

if (!standardRouteModel.hasFixName(this.rwy_dep)) {
    return ['fail', `unable, the ${standardRouteModel.name} departure not valid from Runway ${this.rwy_dep}`];
}

the routeModel is not picking up the rwy segments. _exitCollection is empty even though rwy is not. hmmmm

[n8rzz]

ah hah, these routes don't have either one of exitPoints or entryPoints. They are defined with only rwy and body. Thus, the relevant code from `StandardRouteModel':

    /**
     * Determine if the `standardRoute` is a sid or a star and build the entry/exit collections
     * with the correct data.
     *
     * STARS will have `entryPoints` defined so `rwy` becomes the `_exitCollection`
     * SIDS will have `exitPoints` defined so `rwy` becomes the `_entryCollection`
     *
     * @for StandardRouteModel
     * @method _buildEntryAndExitCollections
     * @param standardRoute
     * @private
     */
    _buildEntryAndExitCollections(standardRoute) {
        if (_has(standardRoute, 'entryPoints')) {
            this._entryCollection = this._buildSegmentCollection(standardRoute.entryPoints);
            this._exitCollection = this._buildSegmentCollection(standardRoute.rwy);
        } else if (_has(standardRoute, 'exitPoints')) {
            this._entryCollection = this._buildSegmentCollection(standardRoute.rwy);
            this._exitCollection = this._buildSegmentCollection(standardRoute.exitPoints);
        }
    }

never sets an entryCollection (which should be rwy in this case). so when you run caf the sidCollection thinks that only body fixes exist.

@erikquinn should this airport have exitPoints defined as part of the SID? Or are these routes completely valid with just rwy and body?

[panther2]

Just to remember: This issue occured to me on EDDM, EDDT and EDDF as well as EGLL ... and I did not test others except KSFO (that is working as expected).

[n8rzz]

yep, and all 4 of those airports define their sids with only rwy and body segments.

depending on what @erikquinn has to say about which direction to go here, this should be an easy(ish) fix.

[n8rzz]

at the very least there should be tests for this case.

[n8rzz]

PR app spun up at: https://atc-dev-pr-198.herokuapp.com/

no changes yet, but this is where they will be first when I have something.

[n8rzz]

@panther2 @indianbhaji @erikquinn so I pushed a temp fix, looks like that was definitely the problem here.

Take a look at the link above and give it a twirl.

[erikquinn]

As it's implemented, all SIDs MUST have at least one exitPoint, and all STARs MUST have at least one entryPoint. This could be changed, as sometimes it doesn't make 100% sense (for example, all SIDs at german airports end at only one fix, and they have separate procedures that link up to various airways and such). So the appropriate (immediate) solution is to add exitPoints to those procedures.

Tests for this would indeed be great, and it might also be worth expanding upon the checkFixes() (I think it's called) method by abstracting these sorts of tasks, and running a bunch of verifications on the setup of the airport file to ensure contributors aren't doing things that aren't allowable for reasons like this they aren't necessarily familiar with. Since airports are the single thing that are most often created/edited by new contributors, some expansion on these to throw more warnings guiding them toward a correctly done airport file would be a great improvement. Created n8rzz#199 for this.

The linked atc-dev-pr-198 app appears to resolve the problem.

[panther2]

@n8rzz
I confirm it works as expected for me. Thank you!

[erikquinn]

Resolved by #755. Closing.