Previously assigned by ATC routes - problems

Dear Navigraph team,

Only recently I discovered “previously assigned by ATC” routes and I was wondering how you get these routes and whether you do any quality checks? I noticed that reclearing an aircraft on a non standard SID leads to this suddenly being suggested as standard and valid routing. Something I find very odd and not great at all because these routings are often only to avoid overload and solely up to ATC.
Ideally vatsim atc could work wiht you to implement (event based) standard routing in like a virtual RAD but the current system is really not ideal.


1 Like

Such a system is already in the works.

The routes are obtained by regularly downloading the VATSIM online users data file. Routes that were cleared or amended by an online ATC prior to departure are added to the database.

The logic is that such “non-standard” routes shouldn’t be the norm, since the system prioritizes the more common routes over the less common ones. Please provide the departure/destination and route you saw that was incorrect and I can look to see if the logic can be improved.

VATSIM cleared routes are only suggested by default if no better route sources are available (i.e. the only routes SimBrief has are those that other users have previously used, which I think you’ll agree is an even less perfect system than using VATSIM ATC-cleared routes).

Once the new system is in place, VATSIM FIRs will be able to add their own preferred routes to the database, which will override these automatic suggestions.

Are you a member of a VATSIM FIR/ACC? If you’d like, I can contact you when this system is ready for testing.

Best regards,

that is great to hear!

  • LOWW LOWI suggested OSPEN ABRUK SETAL NANIT BRENO (I assume a controller colleague has missclicked and chosen another STAR)
  • EDDM LOWW KIRDI MEDEL BARUG (only for load managament in rare cases, invalid and particularly annoying because it creates head on conflicts with every westbound departure out of LOWW)
  • LOWW EDDM any of the ATC assigned (actually, all but the first) are wrong.

The problem is in my opinion that these changes can happen by accident (misclicking) or are used to spread the load on a downstream sector in rare cases, not somethign we want to happen every day. What might also be of interest is that while I can edit the route for my airspace to conform to required routings, I have no idea about the airspaces around me. So what I instruct the pilot to fly/reroute might not be correct for the next airspace but would still count as “edited” and therefore “suggested by ATC”.

I am not entirely sure how this could be fixed best, maybe ignoring STAR changes?

Yes, I am from vACC Austria and we’d very happy to test! We have a free route airspace with quite a few routings that cause frequent headaches for controllers, pilots and route finders alike.


any interest in having a similar way for PilotEdge to submit preferred routings in the future?



Ok fair enough, but none of the routes you mentioned are suggested by default from what I can see. LOWW-LOWI, EDDM-LOWW, and LOWW-EDDM all have IFPS compliant routes as the default first suggestion. I see the following:


So none of the routes you mentioned are used by default (though they may appear further down the list of routes, in my opinion that isn’t necessarily a bad thing). My concern is making sure the number 1 route is correct, since that’s the one that is chosen by default and is what 99% of pilots will use. There are many city pairs that don’t even have a good route to suggest by default right now, those are the ones I’d most like to improve.

SimBrief just sees the final route that the flight departed with. It can’t distinguish between what portions, if any, were amended by ATC. That data isn’t included in the VATSIM data file unfortunately.

I still think the benefits of including these routes outweigh the downsides. In most cases, including them will be an improvement over not including them, especially since these misclicks or offloading routes shouldn’t be as common as the standard routes, and won’t normally be suggested first.

Just to clarify, the upcoming system isn’t VATSIM specific. Any SimBrief users (or perhaps only those with permission, at least initially) will be able to submit routes through a dedicated website section. PilotEdge users will also be welcome to submit routes if they’d like of course.

Best regards,

But then I have to ask myself, why even implement a system for these routes which never come first?

I really don’t see a benefit in publishing them because you cannot distinguish between what happened to the route and how it affects it. It is common practcie for example that the SID is confirmed by ATC in the flightplan. This will add SID_name/RWY eg RUPET2C/29 to the flightplan. This alone consitutes a change for vatsim that is significant enough to be picked up by your system.

I do not see a benefit in this system if they are not shown as #1, because as you suggest nobody uses anything else and this woudl void any benefit they would have. But on the other hand they can do a lot of damage, are unmoderated and have a high error rate (by normal standards).

Also “previously assigned by ATC” suggests a false validity that is misleading and not accurate at all.

The system ignores these.

Because pre-verified IFPS compliant routes are only available for a minority of city pairs in Europe. For flights that don’t have pre-validated routes to suggest by default, what would you prefer SimBrief suggest? A route that was at least looked at and assigned by an actual controller on the VATSIM network, or some random route another SimBrief user happened to use, that may or may not be any good?

Surely you can’t be suggesting that you’d prefer the second option…?

Anyways, I’ll let you know once the new routes system is available for testing. Hopefully it won’t be too long :slight_smile:

what about noise abatement SIDs with different end points? IRGOT instead of RUPET. And even if the SID does nto change, is the rest of the route suddenly marked “assigned by ATC”?

While this is in theory certainly true, not so much in practice. Even if not just changing SID/STAR marks the route as valid, it’s not like ATC will check the whole route. Just because an edit happened does not mean it’s valid. As a matter of fact, ATC reroutes in the air are not according to RAD, they are according to what’s necessary - which is really not what you need on the ground/ before hand.

So yeah, I really do not see much benefit in the system at the moment, especially if Eurocontrol validated routes exist - as in all the cases presented above.

that would be very much appreciated, thanks! Do you want official contact info/ discord or just this thread?

This is great news and in my opinion long overdue, at VATSIM Middle East & North Africa, we already have an existing database of routes for most FIRs using AIPs and existing procedures to comply with regional routing restrictions and ATFM procedures.

Please feel free to contact me, I can help in providing those data.


Mubarak Ahmed
Operations Director, ATC Department
Middle East & North Africa

The system, where Simbrief simply offers the most used routes, is far from ideal as many as in MANY pilots do not do their own route planning, but blindly take whatever is offered to you. With many new pilots perhaps due to the (new) MSFS, the risc of having many routes made without checking aginst Eurocontrol, gives rise to the problem. Sitting in Denmark we see a lot of fraffic flying from eg. EKCH to EGPH via a LANGO sid and into Germany instead of the more direct route via an ODN sid and over the North Sea.
Naturally it is up to the pilot to deside the route - and he/she can easily check the route by looking at the chart provided, but rarely this is done. I appreciate the efford of Navigraph to supply the community with an excellent tool, but I would like to see Navigraph be more alert to how this tool is used. So perhaps a series of videos focussing on this subject was an idea. Hopefully the possibility of adding routes based on atc prefference by FIR is not far away.