How SnakeGrid solves the problems of scale factors and distortion relating to long, linear engineering projects

How do you solve the problems that scale factors cause engineering projects when they are inherent to map projections? The following article explores the problem and explains just how SnakeGrid could make all the difference on your project.

Back to Knowledgebase HOW IT WORKS

The problem

Traditional map projections, such as national mapping grids, contain distortions, either in distances, angles or areas. All maps preserve one aspect at the expense of another. There is also height to consider, the higher you go the greater the distance between two points even though you are above the same point on the earth (concentric circles). The result of these two effects is that information measured on the map differs form that in the real world.

If we consider distances for example, what this means is that the distance measured between two points on the map is not the same as the distance in the real world. Consequently, anything drawn in reference to this map will be a different size in the real world.

The two are linked by the scale factor, which is a function of where you are on the map and the height above the ellipsoid.

The larger the area you’re trying to cover, the greater this scale factor distortion. For example, in the UK the national grid is a Transverse Mercator projection with scale factors of around 400ppm due to the projection alone. The global UTM series of projections has similar levels of distortion. This level of distortion is incompatible with the accuracy required for engineering projects which are typically stated as 1:50,000 or 20ppm.

The consequence of this is that if the project uses mapping /survey data that is presented in a national mapping system, or a UTM projection, what is drawn in the design space will not be what is constructed on in the real world. Things will either be a different size or, if you retain the size, they will be in a different place affecting how they align with existing features/assets.

If you design in a scaled coordinate system, you cannot build what has been designed.

How do you solve this problem?

A project’s coordinate system is the foundation of the project. The mapping needs a coordinate system/projection designed for its intended use. Navigation for instance requires a wide area of coverage to allow users to travel from place to place. Whereas engineering projects need low distortion highly accurate maps over more targeted areas. But what do you do when your project gets above a few km’s in size? Or you have significant height change on your project?

How do you balance these two competing elements? Some traditional approaches are listed below, as you can see each one has a compromise associated with it, be it lack of continuity, higher distortion or only working in specific cases.

Table notes

Projects requires certain characteristics to work. It may not always be possible to cover the project area.
Multiple zones make this possible but increase complexity. Zones base on height changes are hard to identify for the user and therefore increase risk.
Scale change between design space and the real world makes the implementation of this complex.

So you can have a different site grid every few kilometres along the project but you might have to change coordinate systems half way through a railway curve design.

Or you can try a standard projection so that it covers your project as well as it can, and minimises the distortion, However, these will not work in all cases. For instance, there is no conventional map projection that will cover the rail route from London to Edinburgh with negligible distortion

The SnakeGrid approach

SnakeGrid provides a single continuous near zero distortion coordinate system that can extend for hundreds of kilometres.

Along the whole length of the route, we aim to keep the maximum scale factor distortion less than 20 parts per million, no matter how the height changes, and this will hold for several kilometres on either side. In general, we achieve much better than this with rmse values of 5ppm or less not uncommon. This low level of distortion is generally less than the practical survey accuracy, and so in effect the grid can be considered as distortion-free.

We do this by developing a set of algorithms that projects the curved surface of the Earth in such a way that the line of true scale follows a generalised trend line through the project. We then do the same in height to follow the generalised profile of the route. A bespoke projection that winds it way along the route following the changes in elevation to minimise the distortion. The result is a smooth sinuous corridor where the scale factor is close to 1.

All the benefits of a low distortion coordinate system with no compromise on access.

The benefits

Seamless coordinate system

Surveyors and engineers only have one set of control and one set of CRS parameters throughout the whole project
No change in scale factors or grid zones
Designers can designer freely across the whole project without coordination issues created by multiple zones or CRS systems

Zero distortion

Design space matches the real world
Designs are constructed as they were drawn
Contractors workflows are simplified reducing risk
Setting out procedures for engineers are made simpler

Access and software

As easy to access as a standard projection with the benefits of low levels of distortion
One system throughout the projects removes the decisions about which zone to work in
Easy to transfer between different packages

Reduced risk and lower costs

Simplified workflows between project phases and partners
Lower levels of rework due to incorrect scale factors or grid zones being used
Easily relatable to external data sets making decision making and design coordination simple

The impact of the HS2 NTv2 revision was significant. The coordinate system became immediately compatible with virtually all spatially enabled platforms, in particular CAD and GIS. The first benefit was allowing the reprojection of design data to and from the HS2 grid to be undertaken in-situ, which is especially useful for CAD files which will now retain complex geometry.

Perhaps the most significant benefit is the use of reprojection ‘on the fly’ which facilitates the single source of truth. Previously the same piece of geospatial information may have been stored in multiple data containers; one for each of the coordinate systems required, which resulted in significant issues with data conversion and data management. Now a single version of data requires maintenance, and when the geometrical representation is required in an alternate coordinate system the reprojection can be performed automatically within software.

Practical use

A typical survey project associated with a road, railway or pipeline will usually establish a control framework with GNSS. This will give coordinates in a system such as WGS84, ETRS89, ITRF, or similar.

Running these coordinates through a convertor such as SnakeGrid PointWise will put them into the required SnakeGrid system. Or this could be done directly by the software associated with the GNSS, as most major equipment systems (such as Trimble, Topcon and Leica) have the SnakeGrid algorithms programmed in.

You are now in a coordinate system that effectively has a 1:1 relationship with the ground surface. Run a traverse between control points – no need to make any kind of scale factor correction. Design railway alignments in this coordinate system – the same geometry will be set out on the ground. Some users may not even know they’re in something called SnakeGrid coordinates – it’s just a 2D system with no scale error, a bit like a local site grid.

Other users may want to relate this system to other coordinate systems – for example to introduce land ownership data in the national coordinate system or historical records. The integration of SnakeGrid in geospatial enabled software with on the fly reprojections means your highly accurate engineering grid is just as accessible as a traditional wide area map projection.

Using SnakeGrid

Once created we will deliver a parameter file and a report detailing the characteristics of the grid.

GNSS receivers—all major kit manufactures have adopted the SnakeGrid algorithms allowing GNSS receivers to record or set out points using the SnakeGrid coordinate system.
Total stations—the 1 to 1 relationship between the coordinate system and the ground means no more scale corrections required.
In the office the clear and definable link back to a recognised geographic CRS means data from other source can easily be related, whether you are bringing data in to supplement your design / planning drawings, or you are looking to carry our design coordination with a project on a different grid.

More complex cases

Diverging routes

Quite often we are asked to cover minor routes alongside the principal route. Where these are within a few kilometres of the main route, it is usually possible to keep them on the same grid.

However, where they diverge significantly with the second route heading in a different direction, or maybe a series of radial routes from a city centre, we may need a different approach.

In these cases, we will likely need to design multiple SnakeGrid projections before merging them together at a common point. We then deliver a single set of parameters that selects the correct grid depending on the location.

To the end user it appears as just one coordinate system maintaining the low distortion and continuous philosophy that underlies /guides the SnakeGrid approach.

Extending grids

In the cases where projects are extended beyond the original scope it is also possible to apply the same methodology to extend an existing grid. A new grid can be designed and merged to the existing grid to create one continuous coordinate system. As before, we then deliver a single set of parameters that selects the correct grid depending on the location.

To the end user it appears as just one coordinate system maintaining the low distortion and continuous philosophy that underlies /guides the SnakeGrid approach.

Network approach

By utilising this approach entire national network have been covered (NI rail) with a limited number of SnakeGrids all accessed via one set of parameters. Working on the rail in NI, then you are on NIR09 grid, no questions asked.

On the mainland UK, even though the network is much larger / complex, it has been possible to break down national networks into regions which can be covered by single coordinate systems reducing the number of coordinate systems needing to be managed.

A note on datums

The SnakeGrid coordinates (E/N) inherit the datum of the geographic coordinates from which they are derived. Since these geographic coordinates are ultimately derived from GNSS surveys, the GRS80 ellipsoidal parameters are assumed.

In practice, this means that SnakeGrid can be used with any modern datum that is related to WGS84 or ITRF. In Europe this will probably be ETRF89, in the USA it may be NAD83.

To identify your project grid it is important to specify the datum along with the projection, for example SnakeGrid EWR3 on ETRS89/OS Net v.2009.