Frequently asked questions

Each grid is created using a software program called SnakeMaker, working from a set of seed points that defines the route in plan and height. The output of this process is a parameter file that expresses all the essential information about the grid, and which can be read by all the software applications associated with SnakeGrid.

 

Find out  how to commission a SnakeGrid.

The software has been designed to be used anywhere in the world, on any large engineering project – such as railways, highways, and pipelines. It has been adopted on most significant rail routes in the UK, and most engineering and survey companies working in this sector use it at some stage.

We have a set of standard licensing terms and conditions that we issue whenever a new SnakeGrid is commissioned. Broadly, when we issue a parameter file to a client this gives usage rights in perpetuity, to the client and to any of their own clients and customers. We also give copies of SnakeGrid PointWise, without restriction on the number of copies and without charge.

So if you commission a SnakeGrid you are assured that you will have access to the grid in perpetuity, without further charges.

Apart from SnakeGrid PointWise, there are separate licensing arrangements for other software products. See our Software pages for details.

Yes, we have arrangements with many companies, including Topcon, Trimble, Leica, Atlas and Track Access Surveys. So if you’re interested in joining them, get in touch and we’ll take it from there.

The datum is defined by the original control survey.

Although a national mapping system may have been used in preliminary work such as route planning, the high accuracy control work for the project would normally be carried out using GNSS. This measures vectors in the WGS84 coordinate system, so what matters is the datum of the higher level control.

In the UK, for instance, it is probably the case that the starting point for the control was Ordnance Survey Active Stations, which are in the ETRS89 datum. So the coordinate system in use for Crossrail (for example) is XRail09, but more formally might be referred to as SnakeGrid XRail09 on the ETRS89 datum

Essentially, SnakeGrid can be used in association with any datum that uses the GRS80 ellipsoid or an equivalent – which really means any modern satellite-based datum such as ETRS89, NAD83, GDA94, etc.

See our Technical Zone for information on the version history of SnakeGrid, and the definitive statement on which is the current one.

Remember that there is a version number for the SnakeGrid algorithms, but also a version number for the SnakeGrid PointWise software, although generally we keep these synchronised. Other “host” software will have its own version history, but will incorporate a specific set of SnakeGrid algorithms.

Parameter files for version 2 and version 3 can’t be read by software such as SnakeGrid PointWise or SnakeGrid Transformer, and they can’t be used in conjunction with third party software.

You need to replace the v2 or v3 parameter file with an “ASA” file (Alternative SnakeGrid Algorithm). This may already exist, but otherwise contact us to ask about commissioning one. There aren’t many old v2 or v3 ones left that we’ve not created an ASA file for, but there are one or two out there.

It’s best just to write and ask, if you’ve not been able to find out from colleagues. Or if you’re not sure of the exact extents of an existing grid, or are trying to work out if it will be valid on a branch line or a neighbouring highway, for example, that was not part of the original design.

Give us as much information about the project as you can, as there are places where more than one SnakeGrid overlap, each covering a different extent. We’ll let you know if something already exists and can usually help to put you in touch with the people who originally commissioned it.

Most major manufacturers of GNSS equipment, such as Trimble, Topcon and Leica support the use of SnakeGrid, and several software companies also have the algorithms integrated into their packages. See the section on our partners for more information.

In most cases the third party software reads the SnakeGrid parameter file directly, but Leica equipment requires an intermediate step of preparing a separate parameter file in a different format. Contact your Leica supplier directly to ask about this.

All we’re doing with the seed points is defining a broad corridor, several kilometres wide, in which the scale factor distortion will be close to zero. It doesn’t really matter if this corridor moves a few metres one way or another – it will still encompass your project.

Similarly in height, we’re defining the level at which the scale factor is unity: above or below this by a few tens of metres the distortion will be very low.

Once the SnakeGrid has been defined then its definition is fixed, and its use will be consistent with whatever coordinate accuracy is required.

No.

With conventional coordinate systems there will be a scale factor corresponding to the projection, which is derived from an appropriate algorithm, and a scale factor corresponding to the effect of height on horizontal distance. With SnakeGrid, provided that you are within the zone of applicability, then the scale factor distortion from both these sources combined will be less than 20 parts per million, and so for conventional engineering survey accuracy it can be ignored.

 

No.

Give us the coordinates of each branch separately, and we’ll fit a grid that encompasses both branches. We need the original coordinates as we need to test that the distortion is within the acceptable limits where it will actually be used.

When a SnakeGrid is delivered it is accompanied by a report that describes where it can be used, what level of distortion can be expected, details of links to other grids, test values, and so on.

Nowadays we produce a map showing the level of distortion across the whole area of the project, like the example below for EGAB06. We can also do this retrospectively for older grids. Just get in touch if you need one for a grid you’ve commissioned in the past.

 

See the details of how to commission a grid at SnakeGrid for your project.

In this case you need to tell us the name of the existing SnakeGrid that you want to merge into, with details of the point where you want the join to occur. This could be a set of coordinates, but it also helps to give a description – “at Claydon Junction”, for example. The new grid will have the same coordinates and orientation as the existing one at the junction, and the coordinates will generally agree within around 2 mm up to 2 km away, allowing through surveys and computations from one grid to the other.

You can only join at one point – you can’t tie into another grid at the far end, or come back into the first one at a different point.

Choose anything up to 16 characters long, no spaces. Provided that it doesn’t clash with an existing name you can have what you like.

Most people choose names that contain an acronym of the major locations on the route or that describe the project, or use the ELR, and give the year. Examples are XRail09 (for Crossrail), RBEPP12 (Reading, Bath, Exeter, Plymouth, Penzance), DCL_2015 (Didcot to Wolverhampton).

It helps to have something you can pronounce easily – you’ll get fed up referring to WDFJSA2014 after a while.

As indicated above, when you choose a name we make sure that it’s not been used before so that you are assured that each grid has a unique identifier. The exception to that is if you come across a SnakeGrid that has the prefix LOC, followed by the name. This is a SnakeGrid LOCAL, and therefore generated by a user and not by us – hence we can’t guarantee that the name is unique.

You’ll need an ASA file for the area of the junction, which will merge the two grids. ASA files were originally designed to re-create the older v2 and v3 grids, but they are also useful for merging any two grids together in a common parameter file.

Note that when we create an ASA file for an area covered by merged grids, the region of applicability is more restricted than that of the original grids, for the following reason.

The diagram shows a SnakeGrid called “B”, which has been merged into a SnakeGrid called “A” at the junction.

There is an area in the region of the junction where the two grids give the same coordinates within 2 mm (and so the mean is within 1 mm of each). Here it is labelled “A=B”, and it is generally smaller than the area over which each grid is applicable.

Coming away from this, they are no longer equal, and we make a decision about which grid to follow. This is generally dictated by the direction of the underlying trend line or the original track, and effectively uses the nearest one. So in the example above, the AB area merges north into B, and east or west into A. However, there is danger in the north-west and north-east directions, where it would switch from one to the other and so jump by a few millimetres or so. This is not permitted, and so we introduce a “dead zone”, marked X, where the grids are no longer valid.

So if you wanted to use grid A immediately to the north of the junction, you could not do it using the merged file – you would have to go back to the original parameter file that defines A alone. Similarly, of course, you can use this parameter file to get A coordinates in the X zone. Or do the same for B.

So a parameter file covering two or more merged grids has a reduced coverage. They are appropriate for works within a couple of kilometres of the track along any junction, allowing through computation of survey work or continuity of design. They are going to be less appropriate for broad area work that extends for 10 km or so away from the track.

 

Across the lifetime of your project, the savings are potentially huge. Some of the reasons are:

Using SnakeGrid on a project means one grid for all data, enabling the seamless combination of terrestrial survey data, GNSS control surveys, aerial surveys, point clouds, and so on – instead of having lots of separate coordinate systems for different elements of the engineering work, for survey data, for information modelling, and so on.

Integrating the data means easier updating and re-use of data for different phases of a project – “survey once, use many times”. It improves the ease of asset management through having clearly identified coordinate systems for all data, now and for years into the future, and through being able to combine information on fixed assets with topographic survey data, GIS with CAD data – analysing integrated data sets for better decision making.

Having a clearly defined 1:1 relationship between the design and the reality on the ground is also about quality control – no need for potentially expensive misunderstandings as a coordinate system changes in the middle of an engineering design, no need to apply confusing scale factor corrections to survey data.

It depends on your computer and on which grid, but usually it should be capable of processing a million points in about a minute.

Once we’ve got a Purchase Order and a signed licence agreement we can usually create a grid within a few days. In busier periods it might be longer, but we can always prioritise urgent work if we’re given notice that it’s coming up. Just let us know the timescale you need for delivery when you first contact us.

Yes, there are limits beyond which the SnakeGrid algorithms will return an “out of bounds” error – these occur when attempting to use it away from the project for which it was designed.

However, as with any map projection, there are also locations where the algorithms will return an answer but the distortion is beyond the acceptable levels. This is especially the case where there are significant terrain elevation differences a few kilometres away from the route for which the grid was designed.

In both these cases, the locations can be clarified using the distortion map originally supplied with the grid.

It is most likely that you will want the scale factor to be true at the track height rather than at the height of the terrain above the tunnel, so your seed point heights should reflect this. It might involve some estimation if the heights of the track inside the tunnel are not precisely known, but usually an interpolation between end point heights will be sufficient – bear in mind that 5 parts per million of distortion corresponds to a height variation of 32 metres.

The final SnakeGrid report will show a map of the scale factor distortion that is calculated from the terrain height, and so will not precisely reflect the scale factor in the tunnel, but the accompanying statistics on RMS and maximum scale factor distortion will be calculated at the tunnel height.