MantisBT

View Revisions: Issue #291 All Revisions ] Back to Issue ]
Summary 0000291: Allow to predefine departure and landing runway
Revision 2017-07-10 00:48 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clearance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

f) OPTIONAL: check the LastFlightPlan.txt for RWdeparture# and RWarrival# and read the values into the flight plan window. This would allow to add the runways automatically from the EFASS NG export for even more convenience.

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-10 00:38 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clearance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

f) The fields should be automatically deleted everytime a new flight plan is filed. Also no need to store them in the last flight plan.

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-10 00:37 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clearance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data) [please take care of upper case and leading zeros, like 8L or 08L]
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

f) The fields should be automatically deleted everytime a new flight plan is filed.

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-09 23:52 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clearance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

f) The fields should be automatically deleted everytime a new flight plan is filed.

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-09 23:50 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clearance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-09 23:50 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clerance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the SID
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the STAR
- if the entered runway is not valid or empty, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.


Revision 2017-07-09 23:47 by AdvMichael
Additional Information SUGGESTION FOR IMPLEMENTATION (I could do a even more detailed specification, if you want):

a) the runways can be entered in the flight planning next to the Airports
Of course a dropdown menu with all runways after parsing the airport data would be the most convenient solution. However, for the beginning also manual entering of the runways would be alright. Just make sure to force them upper case.

b) Entering the runways for departure and arrival is fully optional. If the fields are left blank, the plugin will detect the runways as it did up to now.

c) In addition to the flight plan, it should be possible to change the preselected runways also after filing the flight plan, as wind directions may change. This should be done in the same dialog box, where you can ask for flight level changes or skip waypoints. Changing the runways should be only possible until:
- DEPARTURE: until the clerance is requested
- ARRIVAL: until ATC informs "expect XXX Approach on runway YYY". The function should not allow to change the runway when already in the Approach.

d) Handling for departure:
- when requesting the clearance, the plugin will check, if a runway was selected
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the SID
- if the entered runway is not valid, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

e) Handling for arrival
- when approaching the Airport the plugin will check, if an airport was manually selected for landing
- then check, if the runway is valid (available in aiport data)
- take this runway and calculate the STAR
- if the entered runway is not valid, use the function as it was up to now
- OPTIONAL: if the tail wind exceeds XXX knots (I could prepare a table, for simplification based on the aircraft weight), then the plugin should take the preselected runway but in opposite direction.
- basically still allow the runway change as it was up to now

So basically we actually need the fields for selecting or entering the runways. Then the existing routine for choosing the runway just additionally needs to look first, if a runway was manually entered, check it against available runways and take it. If not, just use the exisiting procedure. Checking for high tails winds would be an optional Feature, but not absolutely neccessary.

This should be optional, so if no runway data is entered, everything sould work as it is now.




Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker