zlsa / atc

https://openscope.co/
342 stars 107 forks source link

"No altitude assigned" message #760

Closed erikquinn closed 7 years ago

erikquinn commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

Still digging.

eliuuk commented 7 years ago

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

On 13 Dec 2016, 22:01 +0000, P@nther notifications@github.com, 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 (https://github.com/zlsa/atc/issues/760#issuecomment-266875716), or mute the thread (https://github.com/notifications/unsubscribe-auth/ASgmWAuQLsDSCbQ0atfakBTW9rtCb9Zaks5rHxWigaJpZM4LMRC8).

erikquinn commented 7 years ago

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

panther2 commented 7 years ago

Thanks for your confirmation.

n8rzz commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

n8rzz commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

erikquinn commented 7 years ago

Resolved by #755. Closing.