Coordinate Reference Systems in OCRIS

All survey coordinates stored in the OCRIS database are linked to a coordinate reference system code, or CoordSys for short. A CoordSys code encapsulates all the geodetic metadata that may be required to correctly interpret a set of coordinates. The system uses these metadata to calculate a comprehensive coordinate suite, comprising both geographic and projected coordinates and – where applicable – local grid coordinates.

The CoordSys codes used in the OCRIS Database Toolbox are divided into four categories, including one that applies specifically to downhole surveys. These are:

• Geographic Coordinate Reference Systems  (latitude/longitude)
• Projected Coordinate Reference Systems (UTM)
• Local Grid Coordinate System (e.g. exploration or mine grid)
• Magnetic North Reference System (used for downhole surveys only)

---

Geographic Coordinate Reference Systems

A Geographic Coordinate Reference System is one in which coordinates are expressed as latitude and longitude, measured in degrees. Longitude is positive in the eastern hemisphere and negative in the western hemisphere, while latitude is positive in the northern hemisphere and negative in the southern hemisphere.

This type of CRS is always based on a specific geodetic datum. In fact, the CoordSys code used for the CRS is often the same as the datum code. However, keep in mind that the CoordSys code is different from a datum in the sense that more than one CoordSys code can reference the same datum code.

All coordinate reference system definitions in OCRIS make provision for an optional value for the geoid height, N (see section xxx). This value is only used in cases where a given coordinate conversion path involves a change from one geodetic datum to another. In the Australian context, this would include conversions from AGD84 to GDA94 or from AMG84 to MGA94. The formulae used for this calculation are based on ellipsoidal height; however, the height value supplied with survey coordinates is usually the orthometric height (RL). Specifying the value of N therefore enables the system to perform the conversion from orthometric height to ellipsoidal height and vice versa.

The geoid height can vary considerably over a relatively small area; therefore it is often difficult to provide a meaningful value for N. In such cases, the value should simply be set to zero. Leaving the value at zero will not have a significant effect on the accuracy of the calculations; nevertheless, in the interest of being thorough, an approximate value should be provided whenever possible.

The value of SRID is entirely optional. This parameter relates to advanced functionality supported by spatial data types in SQL Server®. Spatial data types play an essential role in the OCRIS database; however, the SRID parameter is never used directly by the OCRIS application. Advanced users may find this parameter useful when developing queries that leverage some of the special features of the spatial data types.

---

Project Coordinate Reference Systems

A Projected Coordinate Reference System is one in which coordinates are expressed as easting and northing, measured in metres. Easting increases from west to east, while northing increases from south to north.

This type of CRS combines a given geodetic datum with a specific TM projection. In the example shown below, the code "MGA94-51" has been chosen to represent the UTM zone 51 south implementation for the Map Grid of Australia 1994 (MGA94). MGA is based on the GDA94  datum.

See xxx for a discussion of the N parameter.

---

Local Grid Coordinate Reference Systems

Local Grid Coordinate Reference Systems are often used for exploration or mining projects, where the origin or orientation of the underlying map grid (i.e. the official survey grid based on a TM projection) is changed to create a simplified, more convenient reference system.

In its most basic form, a local grid may simply represent a "shortened" version of coordinates, where a constant value has been subtracted from the map grid coordinate in order to simplify their use. In other cases, the local grid may have been rotated slightly in order to be better aligned with the strike of an ore body. Whatever the case may be, a local grid is always defined in terms of a translation and rotation with reference to the underlying map grid.

The basic parameters for the local grid are the same as for a projected reference system. The local grid is always based on a projection, which in turn is based on a geodetic datum.

The definition of the local grid itself can be entered in one of two ways:

1. By entering the map grid and local grid coordinates of two control points
2. By entering the map grid and local grid coordinates of one control point, plus a rotation angle and scale factor

An example of the first option is shown below.

In this example, the local grid was devised by simply subtracting a constant value of 550,000 metres from the easting and 6,280,000 metres from the northing, while the height reference level was raised by 120 metres.

Based on these parameters, OCRIS will calculate the rotation angle and scale factor required for the transformation calculations.

An example of the second option is shown below. In this case, the rotation angle and scale factor are already known; therefore, only one control point is required to complete the definition.

The rotation angle is given in degrees clockwise from north. In this example, a bearing of 0° according to the local grid corresponds to a bearing of 30° based on the UTM map grid.

---

Reporting Options

All geometric coordinates and associated reference data in the OCRIS database are stored in metres, with easting increasing from west to east and northing increasing from south to north.

Geographic coordinates are stored in decimal degrees, with longitude positive in the eastern hemisphere and negative in the western hemisphere, while latitude is positive in the northern hemisphere and negative in the southern hemisphere.

In cases where local conventions differ from the international standard, reporting parameters stored along with the CRS definition could be used to customise query results in a way that would appear more familiar to the end user. This could be done by using a combination of appropriate reporting options and dynamic SQL.

Note that these parameters are not used by OCRIS in any way. It merely provides a mechanism for the data administrator to implement customised reporting procedures in a generic way.