Skip to content

VRPs.txt

Alice edited this page Sep 18, 2023 · 6 revisions

Data source

VRP stands for "Visual Reference Point" and these are locations / landmarks which stand to help a pilot navigate. Aerodrome VRPs will usually mark the edge of controlled airspace meaning you can have a clearance to leave a control zone via a specific VRP (for example). The data we use for this file can all be found in an aerodrome's textual data. There will usually be a page which outlines all the current VRPs in use. A current example of a VRP page can be found in the Gatwick (EGKK) textual data file on page 25 (Section 13 a)

It's all good knowing where to find the information but how is, for example, an added VRP shown in the textual data? If you have a look at this document here and turn to page 144, you will be able to see the VRP section for Benbecula airport (EGPL). Next to the VRPs you will be able to see a couple of black bars in line with them. This means that, somewhere around here, something has been changed. In this case, the two VRPs have been established and added to the aerodrome's unique textual data for that cycle.

File Structure

For this, we can look at a pre-existing example which is currently being used in the Sector File. Below is the text within the Gatwick (EGKK) VRPs.txt file

  1. *Billingshurst:N051.00.54.000:W000.27.00.000
  2. *Haywards Heath:N051.00.27.000:W000.05.45.996
  3. *Tunbridge Wells:N051.07.59.988:E000.15.54.000
  4. *Dorking:N051.13.36.983:W000.20.06.000
  5. *Guildford:N051.14.21.984:W000.35.05.999
  6. *Handcross:N051.03.10.000:W000.12.08.000

We can see that there are six VRPs currently in use at Gatwick. Each line represents a different VRP and each line should contain two vital pieces of information about the VRP. Those would be the name of the VRP in question and its coordinates. The first line reads "Billingshurst:N051.00.54.000:W000.27.00.000".

  • Billingshurst = VRP name
  • N051.00.54.000:W000.27.00.000 = VRP coordinates in a format the Sector File understands

The coordinates are written in a specific way which is moderately different to how you see them in the airport textual data. In the airport textual data (taken directly from the Gatwick document) the coordinates for Billingshurst are written as follows: 510054N 0002700W

We need to write this in the form of N051.00.54.000:W000.27.00.000 (You can find out about coordinates and how to write coordinates in this way HERE)

Once we have the name of the VRP we are adding and the coordinates of the VRP in the correct format, we can go on to input the two pieces of information into the VRPs.txt file. In order to do this, we write it as follows: Billingshurst:N051.00.54.000:W000.27.00.000, where the name of the VRP and the coordinates are separated by a colon.

To start each new line and therefore information about a different VRP, we use an asterisk. This means that if we were to input the information on Billingshurst and another VRP, Haywards Heath, into the VRPs.txt file it would look like this:

*Billingshurst:N051.00.54.000:W000.27.00.000
*Haywards Heath:N051.00.27.000:W000.05.45.996

  • Every time you add another VRP this process is followed. It should also be noted that the VRPs should be in alphabetical order to keep things looking tidy (It's not vital and not every airport has their VRPs in order, it just makes things look better!).
  • If you need to delete a VRP all you need to do is highlight the corresponding VRP and its coordinates and hit delete!
  • If you need to update a VRP in any way, just edit the current line to the most up to date information and commit this to the branch you are using to fix the issue.

VRP Naming

The following rules should be applied when naming / renaming VRPs:

  1. The following abbreviations should be applied: Station = Stn, Interchange = Int, Roundabout = Rbt
  2. If a VRP name contains a road junction, it should be in the format: [VRP Name] [Ax/Ax] Int, for example: Puckeridge A10/A120. Note the Int qualifier is optional.
  3. If none of the above apply, the VRP name should be EXACTLY as appears in the AIP, unless otherwise specified by a member of the ops team / trusted sector file contributor

Output

All of the information you add / remove from this file will affect the UK.ese file. Why would you want to know this? Well, you will need to test your changes to ensure they all work correctly and as you expect them to. The best way to navigate to the relevant section of the UK.ese file would be to search for the name of another VRP for that airport. This will narrow down the file to (at some point) the lines where the VRPs are described. For this example, we are going to look at how our favourite Billingshurst VRP is represented. Within the UK.ese file, a line that shows a VRP will look like this:

N051.00.54.000:W000.27.00.000:EGKK VRPs:*Billingshurst

This looks slightly different to the way we went about imputing the information into the VRPs.txt file. However, all of the information we provided is there. If we wanted to test changes we made to the VRP, we can simply change the coordinates and/or the name in a 'development' version of the UK.ese file. However if we had to input a completely new VRP, we are going to have to make one of these lines ourselves. It is important that the lines regarding the VRPs are in the correct area of the UK.ese file. There will be a section where all the VRPs for the airport are listed. However, sometimes an airport may not have had the VRPs.txt file and you would have had to make one yourself. This means that there will be no section in the UK.ese file with any VRPs for the aerodrome. Therefore, you will have to make these lines yourself. Simply put, they should follow this order each separated by a colon:

  1. VRP coordinates in the form the Sector File uses.
  2. The ICAO code for the airport followed by VRPs (XXXX VRPs)
  3. *(Name of VRP)

COORDINATES:XXXX VRPs:*(NAME OF VRP)

It is important you test your changes as this will prevent issues in the future regarding them. However, your work may not be permanent as fine details may need to be changed in the future.

After making your changes, ensure you update the CHANGELOG.md in the most recent format within the branch you are using to fix the issue