For geospatial applications, to understand where you are, and what is around you, there is a requirement to have a representation of your location and the location (or relative position) of other nearby objects. In this post we will look at the format in which your position is received from a GPS or other location sensor, how it can be converted to a format consistent with other data sources and how that position can be used in a 3D environment (which could subsequently be used for visualisation, for example).
This blog is written to give an overview of the conversion process of Latitude and Longitude positions to Cartesian coordinates that can be used in a 3D gaming engine. It is not going to go into the maths of how the conversion from geodetic to planar systems works or the related aspects of accuracy and precision. A future blog will address these in general, with specific references to the situation in the UK.
Location Sensor on the Device
Getting the location on a mobile device is a bit more than just turning on the GPS. Location information requested from the location sensor can be derived from the mobile cell your device is currently in, nearby Wi-Fi networks or, satellite positioning systems (such as GPS or GLONASS). There are pros (accuracy, speed of obtaining a fix etc) and cons (battery life, accuracy) of each type. I will assume we are getting a satellite fix for the rest of this post and commonly refer to that as GPS.
GPS gives positions in the World Geodetic System (WGS84) as this provides a unique location (co-ordinate) for any point on the planet. Valid GPS values are between -180 to +180 longitude and -90 to +90 latitude. Let’s have a look at an example, our office is at 3 Wellgreen Lane, Stirling in Scotland and when I request a value from a GPS sensor, I get:
This has represented our position in three parts: latitude, longitude and altitude with an associated horizontal accuracy.
Geodetic and Projected Cartesian Coordinates
The maths required to work with geodetic coordinates such as WGS84 is difficult because you are not working on a plane. Specifically there are issues relating to convergence as you get nearer to the poles. At the equator a box 1 degree latitude by 1 degree of longitude is essentially square. As you get nearer to the poles, convergence of the longitude lines occurs and your “box” changes shape. More details can be found here.
For mapping, measurement and visualisation systems, it makes sense to convert geodetic coordinates to a planar projection. In the UK we have a well defined coordinate system (projection) defined by the Ordnance Survey and commonly referred to as the National Grid or OSGB. This is also handy as the points of interest feeds and spatial data we use in the UK are mostly published using positions on OSGB.
It is fairly easy to find examples of conversion from WSG84 coordinates to OSGB coordinates, Moveable Type have a handy online converter to show the process. When we put in the values taken from the GPS sensor at our office in, it converts our position to OSGB:
An OSGB representation of the position of our office could be (given the caveats in the introduction above):
Planar Cartesian projected (eg OSGB) positions are easy to understand because a local, relative frame of reference represents the number of meters from an origin. The OSGB origin is somewhere southwest of Land’s End in the Atlantic Ocean. So our position says we are 279736m (280km) East and 693100 (693km) North of this origin position.
3D World Coordinates in a 3D Gaming Engine
We use Vector3 structure to represent positions within our 3D system. This position is taken from the OSGB location where X is the Eastings, Y is Altitude, Z is Northings. The location of our office would be represented as:
This allows us to make use of the same origin as OSGB and makes the logic simpler to understand.
Summary: WSG to Vector3
We’ve seen a worked example of the position of our office in Stirling in the three different coordinate systems we use. Below is the summary.