FS Scenery

Grid Datums


Grid Datum Problems



The problem of duplicate grids first cropped up during the design of the VFR England and Wales scenery for FS98. In fact it was halfway through this project that a second Latitude/Longitude grid first appeared - but this was only discovered some time later when various scenery elements would not match up. It was never fully solved then and a truly definitive solution is not yet in sight.

WGS84 and GPS

The second grid appeared with the introduction of GPS. As this maps in 3D it produced a spherical model quite different to the established Lat/Long graticule on Earth and so a second Lat/Long/Altitude graticule was created for it. This grid will vary from the established Greenwich Grid because it is locked in position and so it will map continental plate drift - the Greenwich grid cannot do this (not impartially anyway).

GPS moved into aviation very quickly and aviation was quick enough to realise that its data had to be altered for GPS values rather than Greenwich Lat/Long. The aviation standard used is called WGS84 and this is being applied worldwide. As each airport comes up for inspection it is surveyed with GPS to WGS84 standard and the airfield plans and approach plates are revised. In the UK most of this work is now complete and the WGS84 database is available from the CAA.

The airfield data started to change in the UK AIP about halfway into the build of our FS98 UK scenery and that is where the problems began. To put them in a nutshell:

All aviation data is now printed in WGS84 format. As FS98 and later all use Jeppesen data this means that all the airfields in FS are also positioned relative to WGS84 Lat/Long.

The Greenwich and WGS84 Lat/Long grids are not synchronised - they are offset in the UK by about 300ft. Not only that but the offset is not fixed - it varies across the UK. (WGS84 grid is slightly south of west around Lands End but slightly north of west at the tip of Scotland).

Although the aviation world has rapidly embraced WGS84 the ground cartographical services like Ordnance Survey will take much more time to readjust their data - OS still use a grid called OSGB36 linked to Greenwich. If you use non aviation charts to obtain Lat/Long values for scenery elements you are likely to get Greenwich grid values. Obviously the same applies if you use OS grid co-ordinates.


Does it matter?

Yes and no. FS is also in a slight mess because their aviation data is WGS84 but the world coastlines and land data are still relative to Greenwich. For most airports this is not a problem - unless they are adjacent to the coastline. In such cases the local coastline has been fudged to fit the airport.

If you build a scenery item very close to an airfield using none WGS84 chart data for location then you are likely to find it is not located correctly relative to the airport. If you are designing for any photoscenery then it's more serious. If your object shows up in the photo textures then the position mismatch will be very obvious.

More seriously, if you are building an airfield to replace the default FS offering make sure you don't use OS based data. If you do the airfield will not match the VFGM scenery - or any nearby FS navaids.

Have a look at this screenshot:

At the centre of the photo is Ronaldsway airport. It's the default airfield so it has been created with WGS84 data. If I decided to get rid of the default FS coastline (see my other page for this) the yellow line represents the coast that would be generated from WGS84 data and is correct relative to the airfield and navaids in FS2002.

If I used OS data for the rebuild then the coastline would shift east to the green line. It doesn't look a lot but if you are building near default airfields it's quite significant.

How much is the offset? I have (as I write) taken a position from a GPS in both OSGB36 datum and WGS84. The differing Lat/Longs (N54:04:22.4 W004:39:19.8 and N54:04:22.9 W004:39:24.3) show me that one grid is offset by 272.32ft on a bearing of 280˚43'. That's almost twice the width of a standard runway.

Is there a solution?

Not exactly. OS are continuing to use OSGB36 for the moment but will move to a GPS based grid in the future. They will not be using WGS84 (they say it's not accurate enough for them) but will use a grid called GRS80 eventually.

Ideally we should use WGS84 data for everything in FS but this isn't easy just yet. Some solutions:

If you have to use OS co-ordinates these can be converted to WGS84 values (there is a spreadsheet on the OS site you can use).

If you use photo scenery and can see the object you are building then slew to the location and note the Lat/Long readings.

Note: It's more accurate if you set you FS display to degrees, minutes and seconds. To do this add the line:
to the [Main] section of your FS2002.cfg file.

It sounds odd but if you have a GPS don't rely on this for providing very accurate readings. It can give errors greater than if you had used OS values! See the GPS Errors page for an example based on my own experience.


Just to round off the page here is a shot of the same area as above but with part of the coastline rebuilt to WGS84 data.