Adding SIDS to amsterdam

[nielsvdweide]

Before i am going to start with adding SIDS we need to think about certain things:

• Which sids do we add? At the moment wind direction does not change, so only sids for the runway used for take-off could be added, but i think in the future variable wind will be implemented, which asks for more sids to be added. Also the use of certain letters and numbers like: "LEKKO 1S Departure" which depends on the runway you're departing from.
• Some sids use a certain distance and a radial from a beacon instead of a fix itself. Any thoughts on how to add these (maybe by implementing fixes) into the sid?

I'm going to start with EHAM soon, just wanted to see if anyone has some thoughts about this. Especially the first point because of #221, #68 and #169. If i think of something else i will add this here.

/ cc: @glangford @MaicomMR @harp71 @tedrek

[glangford]

Which sids do we add?

It's up to you for EHAM, but until variable wind is implemented it might be easier to add just a subset of SIDS. We can always add more later.

Some sids use a certain distance and a radial from a beacon instead of a fix itself. Any thoughts on how to add these (maybe by implementing fixes) into the sid?

I am learning this just now. @culebron also points out in #224 - "...when I tried adding SIDs for SBGL, I saw there are several problems: some departures suggest just doing 180deg turn after initial climb, and there's no fix to stick to."

Some KLAX SIDs have radar vectors in the middle of them. Who knew? :smile:

Some possibilities:

• pick a subset of SIDS with only defined fixes
• tweak the SID for simulation so that it isn't followed precisely, but still captures the spirit of it without interfering with other traffic
• add a "virtual fix" so the SID works as written; it could be named specially and not painted on screen if that makes sense. For example, any virtual fix names could start with an underscore, and the canvas drawing code could ignore them.

What do you think?

p.s. Should we have SIDs painted on the canvas in the background? Or do we leave that out by design just to make it more challenging?

[culebron]

Virtual fixes seem a simple solution. Encoding the real instructions seems too much to just superficially simulate aircraft behaviour. Hidden fixes are good enough to make it fly controllably.

[nielsvdweide]

It's up to you for EHAM, but until variable wind is implemented it might be easier to add just a subset of SIDS.

What do you think of this: Add each SID but with the name of the departure runway in it. So for example: SID LEKKO 18C or SID LEKKO 24 This way it is always clear what SID they are flying and of which runway the aircraft will depart. It's certainly more clear than LEKKO 1S or LEKKO 2B which indicates the same departure for a different runway.

So what I suggest is adding sids with the departure runway behind it. Like this: SID LEKKO 18C

Some possibilities:

• pick a subset of SIDS with only defined fixes
• tweak the SID for simulation so that it isn't followed precisely, but still captures the spirit of it without interfering with other traffic

I will try to add most of the sids, usually rnav sids can be implemented really easy. I will tweak the sid for simulation, and try to maintain the general traffic flow without interfering arriving traffic.

• add a "virtual fix" so the SID works as written; it could be named specially and not painted on screen if that makes sense. For example, any virtual fix names could start with an underscore, and the canvas drawing code could ignore them.

This sounds really good! If you could do something in the code to create virtual fixes that would be awesome :)

[glangford]

What do you think of this: Add each SID but with the name of the departure runway in it.

Having a SID name (or a fix) with a space in it doesn't work with command entry. Space is used as a separator in parsing.

For North American SIDS, as far as I know there is a just a version number tacked on to the end. So if a SID is updated, they add one to the version number. So there is no loss in just dropping it for simplicity.

It sounds like for Europe (and elsewhere) there can be a suffix which has meaning. So we have two choices; stay with the current naming without a space (eg. LEKKO1S) or add the runway.

I'm not sure which is best, but I would suggest keeping the number of SIDS small to start. Maximum 6 or 7?

[glangford]

This sounds really good! If you could do something in the code to create virtual fixes that would be awesome :)

Can do. (Before you add any virtual fixes, with turn anticipation some SIDS may not need them. If a sharp turn is needed after takeoff for example, a virtual fix may or may not be necessary.)

[nielsvdweide]

I'm trying to start working on Amsterdam later this evening! Just wanted to point out some things I'm thinking about to improve gameplay

[culebron]

By the way, SIDs don't necessarily work for one runway. They often times work for all of them, but skipping some intermediate points. Here's an example:

Maybe it's better to chain them somehow? Like:

sids = [
{fixes: [runway('rw28'), '_b0', '_b1']},
{fixes: [runway('rw33'), '_b2', '_b1']},
{name: 'sid1', fixes: ['a1', 'a2'], next: ['_sid2', '_sid3']},
{name: '_sid2', fixes: ['a3','a4']},
{name: '_sid3', fixes: ['a5','a6']}
]

And naming sid1 will choose the best route between a given runway and departure heading. Example: r/w28 => sids[0] => sid1 => sid3.

On the other hand, every sid has its own code, but they're hard to understand, and you need a document with all sids to figure out the name for a path you want to choose.

[Maverick283]

I agree with @glangford that the "version number" can be dropped.

In the FAA region, one SID name can work for multiple runways ( as the picture posted by @culebron shows above). In England and Germany (and other countries, but those are the one I know for sure) there is only one SID for each runway. So when the active runway changes, the SID changes.

BUT: If the SID has the same name in (lets just call it) Europe, the "destination" of the SID is the same. And in most cases, the path of the SID is the same as well (except for that first bit after takeoff).

So for simulation purposes, the version number can be dropped, if SIDs are defined for multiple runways in the simulation. Using the picture above, if we can give the SID the attribute that it may only be used for runway 09 and 33, we can just drop the version number and make the aircraft give a response like "The assigned SID is not valid for the assigned runway" whenever a bad combination is assigned.

This way we can reduce the SID names to the name only but still make sure variable winds and different active runways will not mess up the whole system.

[nielsvdweide]

I agree that the version number can be dropped, but as soon as we get a variable wind, thus changing departure and arrival runways, we might have a problem with assigning sids and stars as well.

For Amsterdam specifically, please look at these two departures: the Andik 1T takes a different route than the ANDIK 2E.

Therefore i wanted to keep it simple and just call them ANDIK with the runway behind it? Like ANDIK18L or ANDIK06

I will start adding some SIDS later this evening!

[glangford]

This is a good discussion. A couple of observations:

Using the picture above, if we can give the SID the attribute that it may only be used for runway 09 and 33, we can just drop the version number and make the aircraft give a response like "The assigned SID is not valid for the assigned runway" whenever a bad combination is assigned.

At this stage, I would prefer not to be checking SIDs against runways for validity. This would be a bit of a mess for the situations where the SID is valid for multiple runways. While it might be more realistic, it does not really add to the quality of game play and it adds to complexity of the airport definitions.

the Andik 1T takes a different route than the ANDIK 2E.

This is a good example.

I think to start we want to make some simplifying assumptions; we can always make improvements later once we have all played with it and have a chance to evaluate how departures are working:

I suggest:

• leave variable wind for "future considerations"
• no chaining
• implement the subset of SIDs that make sense for the current wind at each airport
• use only a list of fixes and add virtual fixes where necessary; the "game SID" does not have to precisely match the real SID
• target maximum 6-7 for each airport (my opinion only)

I have a slight preference for naming like "ANDIK1T" and "ANDIK2E" rather than tying the SID to a runway in the name (because of the discussion above) - it sounds like we will run into less trouble.

[nielsvdweide]

I'm currently busy with adding SIDS to amsterdam, i've made a couple of new waypoints and i am assuming everyone is using runway 24 for takeoff and runway 18r and runway 18c for landing. All the sids are compatible with the use of runway 24 and even runway 18c/l for departure!

At the moment; this is what it looks like

"sids": { "ANDIK": ["EH005", "EH008", "EH026", "PAM", "ANDIK"], "ARNEM": ["EH005", "EH008", "EH026", "IVLUT", "NYKER", "ARNEM"], "BERGI": ["EH005", "CH", "EH028", "BERGI"], "LEKKO": ["EH005", "NV", "LEKKO"], "GORLO": ["CH", "GORLO"]

Right now i am changing departure destinations to be in line with the standard departure route and adding stars so that arriving traffic will not interfere with the departure traffic.

[Maverick283]

Well, if it is gonna be no tying to runways (which I understand as it really might get messy :/ ) then I think dropping the version number is better then having different SIDs with almost the same name.

While we have the charts laying out before us right now, how is the user gonna know the name of the SID with the version number?

If we drop the version number then we can give the user the rule that the SID has the same name as the waypoint it goes to (as that is usually the case).

Also we can/should then mark the waypoints that have SIDs going towards them by a special color or format or whatever, so that the user can identify the SIDs he has faster. (EDIT: The way they can be identified now looks good as well! Didn't See that yet when I created this comment )

[nielsvdweide]

@glangford Any help on adding STARS to amsterdam as well? I've got the standard code which works for amsterdam (the way it is now). I tried to change some things and copied the way stars are implemented in KLAX but now eham.json doesn't load anymore...

Could you briefly explain how to implement stars?

"arrivals": [ { "radial": 114, "heading": 294, "airlines": [ ["ual", 3], ["aca", 3], ["awe", 3], ["baw", 3], ["klc", 1], ["klm", 5], ["ual", 3] ], "frequency": [3, 6], "altitude": [7000, 9000] },

[glangford]

Could you briefly explain how to implement stars?

Sure ! The main idea is that for each arrival you want to have a radial (that says where the aircraft spawns) and a list of fixes that represent the STAR.

For example:

"fixes":   ["MOVDD", "RISTI", "CEDES"],

Each of the fix names has to exist - if there is a typo, there will be an error logged in the console.

One error that I make all the time is including a trailing comma when it isn't needed.

[nielsvdweide]

@glangford So now i added this line "fixes" and both waypoints exist, but yet it can't load eham.json upon testing it.

{ "radial": 054, "heading": 234, "fixes": ["EEL", "ARTIP"], "airlines": [ ["ual", 3], ["aca", 3], ["awe", 3], ["baw", 3], ["klc", 1], ["klm", 5], ["ual", 3] ], "frequency": [3, 6], "altitude": [7000, 9000] },

[glangford]

Have you checked the console to see if any errors are logged? If there is nothing there, can you commit your changes, push to your repo and I will peek at the file?

[nielsvdweide]

How do i check the console?

[glangford]

Depends on your browser:

Chrome https://developer.chrome.com/devtools/docs/console

Safari The developer menu has to be first enabled; then you can see the console from that menu: http://macs.about.com/od/usingyourmac/qt/safaridevelop.htm

[nielsvdweide]

I get this while trying to load eham.json [Warning] [ WARN ] – "Failed to get assets/airports/eham.json: 200" (modules.js, line 125)

And sorry guys for going major off-topic right here

[glangford]

Ok, that's just a generic error. Two choices:

• get the file working by removing any "fixes" lines; then add the fixes/STARs back in, one at a time to identify the problem.
• commit your changes, push to your repository and I will look at the file there

[nielsvdweide]

I just had one "fixes" line in there, and as soon as i did that it stopped working. If i remove the line it works again... Quite strange. I have a working file in my repo right now if you want to take a look at it?

One of the stars is from radial 054 with fixes EEL and ARTIP

[culebron]

Regarding STARs, I saw one trick that ATCs do in Dubai: they let some planes cut the rectangle pattern in various places, in order to chain them with enough clearances. If we include these virtual fixes (numbered) in STARs for convenience, then they should include all fixes to allow flexible shortcutting to whatever position is needed.

EDIT not all fixes, but several of those after the turn. Fixes just before the turn are not so necessary.

[glangford]

That's the beauty of the new DIRECT command! :smile:

[glangford]

@nielsvdweide - If I add a fixes entry to your file from your repo, it works fine. Two suggestions:

• the SIDs section should be indented; everything is in column 1
• try manually typing the fixes line rather than cut and paste

[glangford]

The SIDS look good :smiley:

[MaicomMR]

Guys I'm sorry about my noob question, but what the meaning of the "cc" abbreviation?

[MaicomMR]

@glangford looks perfect :+1:

[glangford]

what the meaning of the "cc" abbreviation?

"Back in the "Dark Ages" before computers letters were send by snail mail. They were typed on a typewriter. If a copy was to be sent to another person, the writer would type CC and then the name of that person at the bottom of the letter. CC stands for carbon copy. It's a hang-over from the days when carbon paper was used ... the days before photocopy machines." https://ca.answers.yahoo.com/question/index?qid=20061120140451AA58Oho

[MaicomMR]

Thank you, I had sought in other place and none of the answers made sense.

[nielsvdweide]

The SIDS look good :smiley:

They do yeah! Now we just need to add the stars to them!

[glangford]

If you are still stuck, push your broken file to your repo and I will check that.

[nielsvdweide]

I will continue tomorrow! Too late for me now haha :)

[culebron]

It always puzzled me why email copy said "carbon copy", why an exact copy would be carbon (I did have those black copying sheets, but they were named "kopirka", not "karbonka" :)).

[glangford]

The funny thing for me is I don't even think twice about the phrase "carbon copy" because I remember the days when it was used. Imagine the excitement when you could make multiple copies at once (original, yellow which was called "canary", pink). Now that was innovation (please press hard with your ballpoint pen). :laughing:

[nielsvdweide]

@glangford if you have the time please test amsterdam: http://nielsvdweide.github.io/atc/

[glangford]

@nielsvdweide I just did a quick test copy and pasting EHAM into my environment. The new SIDS work great. :+1:

A couple of comments:

• the speeds of the arriving aircraft are all 200 knots, this can be changed by adding "speed": 250, for any or all of the arrivals
• I noticed that your fork of the project says "This branch is 22 commits ahead, 35 commits behind zlsa:gh-pages." So you are missing the changes that would allow you to test everything together with the new code that has been added recently. What you want to do later is pull the changes from @zlsa. For example, I do this sequence:

git fetch upstream
git merge upstream/gh-pages
git push origin gh-pages

"upstream" is the main repository, "origin" is your repository.

[nielsvdweide]

This can be closed