Add "transition" procedures

[erikquinn]

And transition command to assign aircraft to clear them out of the hold at the end of a STAR (when applicable).

[Alpi-no]

I think it's more of a question to get the hold command integrated in the star command, than this. Because if I'm not mistaken, this command should be something along those lines: c(leared) mabod4k (transition) this includes thedvs command as well!

[erikquinn]

@all

Current plan:

+---------------+-------------------------------------------+
|   Procedure   |      Order of legs of the procedure       |
+---------------+-------------------------------------------+
|         SIDs: |    rwy       -->   body   -->   exitPoint |
+---------------+-------------------------------------------+
|  Transitions: | entryPoint   -->   body   -->      rwy    |
+---------------+-------------------------------------------+
|        STARs: | entryPoint   -->   body   -->      rwy    |
+---------------+-------------------------------------------+
|         IAPs: | entryPoint   -->   body                   |
+---------------+-------------------------------------------+

This is my current thinking. If there's anything with this concept that won't work well with local procedures you'd want to implement for your airport(s), I'm open to suggestions to how better to set this up.

[Alpi-no]

if I'm wrong, please tell me, but as far as I know, IAPs are just the ILS (in game). So why add them as another procedure? Instead I would increase the length of the transition/star to include the go around procedures and before that a line up on the extended centerline of the runway.

[erikquinn]

Currently yeah, but the idea would be to add charted approach procedures like RNAV, GPS, VOR, VOR-A, NDB, custom visual approaches, etc, where they have multiple Initial Approach Fixes that come together to a single final approach course

[erikquinn]

And we don't want to "increase the length of the star", we want to use the same real instrument procedures as they do out there in the real world

[Alpi-no]

the reason why I suggested increasing the length of the STAR is, because in Europe, when you are cleared a transition, you can expect a certain runway and you'll have to type in both at the same time into your FMC. Hence you'll automatically align on the centre axis or RMAV entry fix. If you are not cleared, you'll just follow the path at your designated height and go around. I don't think, IAPs are going to help! I hope, what I just explained, is understandable.

[Alpi-no]

In LOWW I extended the transitions to continue right until the runway for simulation purposes. If it would end, where it should, planes that I don't clear to land, would head somewhere totally different because I don't have a route following the transition, however, because I lengthened the transition, planes that are not cleared on the ILS, will follow the runway axis and ultimately perform the go around procedures

[Alpi-no]

I think the correct phraseology would be AUA99 cleared via the BALAD3N transition expect ILS/RNAV/VOR runway 34. This way the plane knows it's route. Something we can't currently do ingame

[Maverick283]

I belive that since IAP lead directly to the end of an approach they could be treated as if they lead directly to a runway. When you're assigned a IAP you definitely know what you're flying, if not by the IAP itself then by ATC , and most of the time (unless it is an VOR approach) you can expect a certain runway. As for a star, in America they only go to the IAPs, in Europe the go to the beginning of a transition, so I don't think they should go all the way to the runway

[eliuuk]

Depends on the country. Doesn't matter where in Europe, they're all different. In the Netherlands for example, they are all sent to an IAF, at which there are 2 options. During normal day operations, they are vectored in. During night operations, there are 'transitions' that lead on to the IAP. In the UK, 'transitions' do not really exist, as most are vectored in. However, some airlines such as BA do use RNAV approaches, so it may depend on the company too.

Overall, I really think it should be implemented like a lego block system. There should be a way to allow airport creators to specify which order these procedures go in, but I don't know how this would go in js.

For example, the easiest way would be allowing the creator to choose between the following:

STAR ~ Transition ~ IAP, Transition ~ STAR ~ IAP, STAR ~ IAP

Afterall, a transition in the US is completely different to a transition in other parts of the world, like Europe.

[eliuuk]

@erikquinn Shouldn't the end of 'transition' be STAR/rwy in that case?

[Alpi-no]

I think in Europe we have a problem with this system. You can't clear a plane on a certain transition without expecting a certain runway. The game doesn't understand that. For the game the transition (European) is a route for itself. It doesn't connect! That's why I increased it's length right until the runway. This is actually pretty realistic

[eliuuk]

The game doesn't understand that. For the game the transition (European) is a route for itself. It doesn't connect! That's why I increased it's length right until the runway. This is actually pretty realistic

Not all European procedures are like that, however?

[erikquinn]

@erikquinn Shouldn't the end of 'transition' be STAR/rwy in that case?

@indianbhaji A transition in the US is NOT a separate procedure, that's the difference. It's part of the SID/STAR.

So then does any country use the second order you listed above: "transition > STAR > IAP", where the transition is a completely separate procedure from the SID/STAR? Or would it be correct to say that transitions as a standalone procedure only exist after a STAR?

[Alpi-no]

OK. Whatever we do, we have to define some terminology! I think we should call everything a STAR, that is an inbound route coming from the outside. A Transition is a route, that you assign a plane instead of vectoring it to the ILS and the starts in your FIR and ends there. Every route that is not leading you straight to the runway (at the airport, not glideslope) eg the initial approach procedures at EGLL are considered a transition and everything that leads straight to the runway is an IAP. Any thoughts/ideas about this? I would put it in the wiki, so it's easier for people to communicate.

[erikquinn]

A Transition is a route, that you assign a plane instead of vectoring it to the ILS and the starts in your FIR and ends there.

Right. That's what I'm trying to verify above: is it true that a "transition" procedure is only used to connect the end of a STAR to a runway, or can it also be used to connect from an airway to the beginning of a STAR? Because that would make a difference in how it is to be set up in the code.

Every route that is not leading you straight to the runway (at the airport, not glideslope) eg the initial approach procedures at EGLL are considered a transition and everything that leads straight to the runway is an IAP.

That's my intention. So if the answer to my question above is "yes", it would always be flightplan/airways/etc --> STAR --> Transition --> IAP --> landing, unless the airport doesn't have any transitions for example.

[eliuuk]

@erikquinn Correct, and this should work for all airports :p

[Alpi-no]

As far as I know, this is correct! I still think we should write this down for the future - in case we forget :D

[erikquinn]

Okay, thanks guys for the clarification. And yes, it will definitely be added to the wiki and in-repo documentation.

[erikquinn]

The ATC repository is being migrated to it's new home at https://github.com/openscope/openscope, and thus, all issues are being closed. If this is still an issue with the latest version of the sim (accessible at http://www.openscope.co), or is a feature you still think we are lacking, please reopen the issue at the new repo.

Please note that the vast majority of these issues have been copied to the new repository, or else are covered by other issues created there. See the below screenshot for what it looks like when your issue is known in the new repo:

Thank you!

Closing this issue.