Hi All,
A a couple of weeks ago I made this topic:
And by popular request here’s part 2 with how we add Fixes, VORs and NDBs.
Fixes
Adding fixes is fairly simple. First we find a reliable data source. I’ll be using this one:
This PDF has all the fixes in the Australian Airspace in effect as of the 7th of November. For reference, the ones with the black lines next to them are new in this cycle. I’ll be adding ABVOG. The data is as follows:
The waypoint name is ABVOG, the latitude is 374021S and the longitude is 1443916E.
Now I open up the Fixes file. It looks like this.
There’s more. A lot more. But you get the idea. This file is like a massive table. Where each curly bracket is a row, each value is a cell and each element is a header. Sorta like this…
Latitude | Name | Longitude |
---|---|---|
0 | 0000N | 0 |
0 | 0001E | 1 |
And so on…
Now, since everything needs to be in aphabetical order in accordance with the fix names, I first search to see if there’s a duplicate. There’s not. Now I search for ABVO and get these results:
Since G comes before M and N it’ll go above these two sets. So I create a new row and enter the elements like so:
Now I enter the fix name. Now, you’ll notice the coordinates are in the wrong format, so I convert them using http://www.earthpoint.us/Convert.aspx. It spits out -37.6725000, 144.6544444 so that’s what I put in the latitude and longitude fields respectively, after simplifying them down to 6 decimal places (or less in the case of the latitude).
And viola! After saving that fix and having the change merged into the central GitHub repo it will come out in the next push. However, I have to be careful. When I create the merge request (technically called a Pull Request or PR) I ensure that I note that the PR is not to be merged until after the October Navigation Push as otherwise the fixes will appear in IF before they ‘appear’ in real life.
VORs
Next is VHF Omni-Directional Range Beacons, otherwise known as VORs.
First, I’ll find one that’s missing. In all honesty, I couldn’t, so I’ve temporarily removed the Mildura (MIA) VOR from the database on my laptop.
First thing as always is to gather information. I’ll be using SkyVector, on the VFR Chart the VOR looks like this:
And currently the VOR file looks like this:
Of course there is more. It’s also in alphabetical order based on names.
Once again, imagine the database (JSON) as a table like so:
Name | Identifier | Latitude | Longitude | Elevation | Frequency | Reception Range | Slaved Variation |
---|---|---|---|---|---|---|---|
MILAS BODRUM | BDR | 37.252166667 | 27.668222222 | 33 | 11670 | 130 | 4 |
And so on…
The blank line is where we’re going to add the Mildura VOR. First we add a set of curly brackets and put in the keys (in red) like so:
Now we add the values we can see on SkyVector:
I find the coordinates, which in this case are -34.225194444, 142.077269444. So I input this as well.
Now add the reception range and magnetic (slaved) variation and viola! A VOR is added.
NDBs
Adding NDBs is very similar to adding VORs, with similar keys. Here’s what the file looks like before editing:
The blank line is where the VOR we are adding will go. Again, it’s alphabetized based on names.
We’ll be adding the MB NDB in Melbourne, Australia. Again, it is in IF already, I’ve removed it from the JSON so I can re-add it for demo purposes.
First we again gather info from SkyVector like so:
First we add the curly brackets, keys and values from SkyVector like so:
Then right clicking on the spot where the NDB is in SkyVector we can also get the coordinates, which after converting the format to decimal using www.earthpoint.us/Convert.aspx we can add as seen here:
Now using one of the various elevation finders we add the elevation, and using enroute charts you can look up the reception range like so:
And that’s it - that NDB is now (re)added!
Thanks for reading and congrats if you made it this far!