Ability to get VATCAN Code from URL

[cptalpdeniz]

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]

This is an improvement, for your information.

[rpuig2001]

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]

Should the implementation rather create predefined TTOTs instead of CTOTs?

[rpuig2001]

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]

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]

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]

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]

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]

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]

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]

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