search

rpuig2001 / CDM

CDM
GNU General Public License v3.0
22 stars 9 forks source link

Ability to get VATCAN Code from URL #99

Closed cptalpdeniz closed 1 year ago

cptalpdeniz commented 1 year ago

As you know right now you need to write VATCAN code to CDMConfig.xml. I was wondering what if this code can be taken from a URL? In this way ATC does not need to find and edit config file all the time. For example a URL that only contains VATCAN string? Example put the following link to CDMConfig.xml and CDM would get the VATCAN code from the URL. This would make it dynamically get the code.: https://raw.githubusercontent.com/TRvACC/CDM_data/main/VATCAN.txt

cptalpdeniz commented 1 year ago

This is an improvement, for your information.

rpuig2001 commented 1 year ago

As VATCAN will not be used anymore, you will be able to set your own url with your own data in the next version. FYI the format will be as follows:

RYR42TQ,1935
RYR35J,1915

Initially cid will not be used as it is one of the main problems for the low-memory usage.

kusterjs commented 1 year ago

Should the implementation rather create predefined TTOTs instead of CTOTs?

rpuig2001 commented 1 year ago

Should the implementation rather create predefined TTOTs instead of CTOTs?

They will be in a new column called Event CTOTs. With a function to pass this "ctot" as CDT.

kusterjs commented 1 year ago

Well if you assume that for such event flights, no further flow measures downstream will be considered, then setting directly the CTOT is ok. I was just thinking about maybe enroute sectors implementing some restrictions. These would be deliberately disregarded with the current implementation, which can be the way of designing it. Maybe then to point this out in the documentation (flight with CTOT from an event list will be "immune" to any other restriction which would normally impose a CTOT). I wouldn't create yet another additional column.

rpuig2001 commented 1 year ago

I'm open for any change or discussion for that.

When adding a CDT, flow restrictions are not taking into consideration. CDT > FLOW > APT departure rate

rpuig2001 commented 1 year ago

For the enroute restrictions I was thinking on a possibility by getting the EET section in the item 18 of a flightplan. Again, any idea for the implementation will super!

kusterjs commented 1 year ago

When adding a CDT, flow restrictions are not taking into consideration. CDT > APT departure rate > FLOW

I would expect exactly the opposite. Because it doesn't make sense to overrule a flow restriction with a (local) airport measure.

As far as I am aware, this is more of a try and error principle. You issue a TTOT (which can be fixed for the airport by a CDT so that other TTOTs are shifted around it) considering all the departure airport restrictions. Then you validate it again any downstream sector restrictions. If there is one, you take the delay to add it on top of your first TTOT and try again if airport and downstream restrictions are respected. You continue this process until no additional delay is required.

kusterjs commented 1 year ago

For the enroute restrictions I was thinking on a possibility by getting the EET section in the item 18 of a flightplan. Again, any idea for the implementation will super!

To work with actual sectors, this might be very difficult. It would be easier than to use waypoints (also for the flow measures). E.g. a restriction would result in a reply like "this flight can be accepted over WYPNT earliest by 1120". The calculation could then be made by using the ExtractedRoute elements, which is basically the trajectory preview you can also display. I'm not sure though how exactly the speed is taken into consideration (especially ground vs. airborne), but the display of the trajectory might help to give some insights here.

rpuig2001 commented 1 year ago

For the enroute restrictions I was thinking on a possibility by getting the EET section in the item 18 of a flightplan. Again, any idea for the implementation will super!

To work with actual sectors, this might be very difficult. It would be easier than to use waypoints (also for the flow measures). E.g. a restriction would result in a reply like "this flight can be accepted over WYPNT earliest by 1120". The calculation could then be made by using the ExtractedRoute elements, which is basically the trajectory preview you can also display. I'm not sure though how exactly the speed is taken into consideration (especially ground vs. airborne), but the display of the trajectory might help to give some insights here.

Moving that to #109

rpuig2001 commented 1 year ago

When adding a CDT, flow restrictions are not taking into consideration. CDT > APT departure rate > FLOW

I would expect exactly the opposite. Because it doesn't make sense to overrule a flow restriction with a (local) airport measure.

As far as I am aware, this is more of a try and error principle. You issue a TTOT (which can be fixed for the airport by a CDT so that other TTOTs are shifted around it) considering all the departure airport restrictions. Then you validate it again any downstream sector restrictions. If there is one, you take the delay to add it on top of your first TTOT and try again if airport and downstream restrictions are respected. You continue this process until no additional delay is required.

Moving that to #110