Closed erikquinn closed 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.
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.
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.
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).
yeah, sorry you're completely right. I accidentally went to zlsa.github.io/atc. I'm a dummy! This issue is definitely valid.
Thanks for your confirmation.
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
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
?
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).
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.
at the very least there should be tests for this case.
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.
@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.
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.
@n8rzz I confirm it works as expected for me. Thank you!
Resolved by #755. Closing.
from @panther2 on v3.2.0: