Skip to content
Tom Kralidis edited this page May 27, 2015 · 2 revisions

SOUTH ORIENTATED TRANSVERSE MERCATOR (TMSO)

This page is a place for discussion of the South Orientated Transverse Mercator projection. It is hoped that the discussion here will lead to an implementation of this projection in PROJ.

Status Note: TMSO support has now been added to PROJ.4 4.8.0 and GDAL/OGR 1.8.0, see notes at bottom!*

WHERE IS TMSO USED?

TMSO is the standard national projection for South Africa, Lesotho, Swaziland, Namibia and Zimbabwe. Botswana uses Universal Transverse Mercator (UTM) as the standard, but also publishes some maps using TMSO. Namibia is slightly different from its neighbours, because it uses a false northing where the other countries do not and also uses the German Legal Metre instead of the International Metre.

A DESCRIPTION OF THE PROJECTION

The TMSO projection is a special case of the ellipsoidal Transverse Mercator (TM), developed from an ellipsoidal model of the Earth. The ellipsoidal Transverse Mercator is sometimes referred to as the Gauss-Krüger or Gauss conformal projection. The projection is conformal meaning that shape and angle are preserved at the expense of distance and area.

The origin of the co-ordinate system lies at the intersection of the equator and the central meridian. The Y-axis lies on the equator and increases positively in a westerly direction while the X-axis lies on the central meridian and increases positively in a southerly direction. The central meridian is the ONLY line of longitude that is a straight line on the map and the equator is the ONLY line of latitude that is a straight line on the map. This means that distortion increases with increasing distance from the central meridian and the equator. The UTM projection uses a scale factor to balance the distortion effects, but in South Africa the scale factor always has a value of one. It is thus necessary to limit the distance from the central meridian and the width of the map. It is standard practice to use each odd numbered parallel (15, 17, 19, 21, 23, 25, 27, 29, 31 and 33) as a central meridian. It is also standard practice not to apply false eastings and northings, even though the large distance from the equator yields large values for the X co-ordinate.

The important difference between TMSO and Transverse Mercator is the orientation of the axes. The orientation is contrary to the normal mathematical usage and especially since TM provides false eastings and northings to deal with otherwise large negative numbers some people have regarded South Africans and their neighbours as mad.

ARE USERS OF TMSO MAD?

Gerald Evenden, the originator of PROJ, made the following delightful comments (1).

"Without me having to dig out my references, is the sign of the northing increasing in a positive manner as the latitude increases southerly? Logical use of TM would dictate that the normal TM projection is used with a false northing sufficiently far south to make the "zone" of interest still positive in the northing values. To do otherwise is most illogical, to say the least. Also: "westing?" Is that positive also? My, my, I'm getting the idea that being "down under" has drained all the blood from the head to the other end. But the Aussies don't seem to have this problem."

The creator of TMSO may very well have been mad, but usage of this projection is well entrenched across several southern African countries and is unlikely to be superseded any time soon. It is therefore desirable that PROJ support TMSO.

CURRENT PRACTICE

Some proprietary software systems that originated in South Africa support TMSO, see (2) and (3) for examples. For the rest that do not offer support for TMSO, it is common for practitioners to use standard TM with a scale factor of one and zero false eastings and northings. This yields co-ordinate values identical to TMSO, except that both ordinates have opposite sign.

RELEVANT EPSG CODES

It should first be noted that South Africa has had two official national grids. Prior to 1999 the official national grid was based on the Cape Datum. This datum was referenced to the Modified Clarke 1880 ellipsoid and had its origin point at Buffelsfontein, near Port Elizabeth. This system is variously known as the Cape Datum or LO system. On 1 January 1999 a new national grid became official and this is based on the WGS84 ellipsoid with the co-ordinates of the Hartebeesthoek radio astronomy telescope used as the origin of this system. This new system is known as the Hartebeesthoek94 Datum. Although the new system became official in 1999, eleven years later data using the Cape datum are still being exchanged amongst practitioners. Remembering that ten different central meridians are used with two different datums one will quickly appreciate the complexities encountered due to there being twenty different co-ordinate systems in use in South Africa. These are twenty distinct co-ordinate systems and data cannot be transformed between two adjacent central meridians by simply adding a false easting.

For the Cape datum, odd numbered EPSG codes from 22275 to 22293 are used for the odd numbered central meridians from 15 degrees east to 33 degrees east. For the Hartebeesthoek94 datum, consecutive EPSG codes are used from 2046 to 2055.

The Schwarzeck datum is used in Namibia and odd numbered EPSG codes from 29371 to 29385 are used for odd numbered central meridians from 11 degrees east to 25 degrees east.

IMPLEMENTATION DETAILS

All that is required to produce co-ordinates in the TMSO projection is to negate both ordinates of the standard TM projection. This may be demonstrated with the proj program.

 $ proj -f %.3f +proj=tmerc +ellps=WGS84 +datum=WGS84 +k_0=1 +lon_0=31 +lat_0=0 +x_0=0 +y_0=0 +units=m
 30.5 -29.5
 -48483.462	-3264793.450

The above example is based on standard TM and hence the easting and nothing co-ordinates are negative. In the example below a negative one multiplier is used to produce TMSO co-ordinates.

 $ proj -f %.3f -m -1 +proj=tmerc +ellps=WGS84 +datum=WGS84 +k_0=1 +lon_0=31 +lat_0=0 +x_0=0 +y_0=0 +units=m
 30.5 -29.5
 48483.462	3264793.450

Note: the axis order of '30.5 -29.5' is 'en' (easting then northing) and 'x,y' whereas the axis order of a TMSO coordinate is 'ws' (westing then southing) and 'y,x'

It should be noted that the same effect could be achieved by using a negative one scale factor, however the current version of PROJ does not allow k<=0. Also note that the multiplier (-m) is only available through the PROJ program and not the PROJ library. Software like QGIS access the library and so the multiplier cannot be used.

Rather than allowing a negative scale factor in PROJ, the use of which is not intuitive, it is proposed that PJ_tmerc.c be extended to handle a new projection: +proj=tmso

See the description extracted from the EPSG database:

http://www.remotesensing.org/geotiff/proj_list/transverse_mercator_south_oriented.html

POTENTIAL PROBLEMS AND SOLUTIONS

In the absence of software that supports TMSO, most practitioners have been using standard TM and have built up large datasets in this projection. It is highly undesirable that someone choosing to embrace the new projection available through PROJ should have to warp all their data to the new projection. Most government raster data is distributed in the proprietary !MrSid format and uses standard TM. A mechanism is required that will allow a user to access a !MrSid image in TM and have the co-ordinates display as TMSO.

ESRI World Files (.wld, .sdw, .tfw, etc) and GDAL Virtual Raster files (.vrt) should provide the mechanism for overriding the georeferencing in a proprietary raster dataset. This is easily done for raster data because the data is just rows and columns with no explicit georeferencing. This may be more difficult for vector data because the geometry is embedded. The current ogr_vrt driver does not provide a multiplier that can be applied to the geometry. What is the best way of handling this? Do we extend the ogr_vrt driver?

OPEN TICKETS

The following tickets for this issue are currently open.

PROJ trac: https://github.com/OSGeo/proj.4/issues/18

GDAL trac: http://trac.osgeo.org/gdal/ticket/2590

THE WAY FORWARD: Treat as an axis orientation issue

For some time there has been a desire to add mechanisms to PROJ.4 to handle alternate axis orientations. That is a mechanism to map x, y and z tuple values to directions other than the default easting and northing via a new directive that would be interpreted in pj_transform() (and invisible to the lower level PROJ.4 projection methods). This might take a form like: +axis=wsu (meaning x=westing, y=southing, z=up). This would make it possible to handle lat/long (as opposed to long/lat) geographic coordinates as +axis=ne instead of the default +axis=en. It should also be able to support the unusual axis orientations of things like the Krovak projection without having to treat them as multiple projection methods.

**DONE! ** : Support for +axis has been implemented in PROJ.4 trunk and will be widely available in the 4.8.0 release. Also, GDAL's OGRSpatialReference class has been updated to support TMSO translation into WKT and proj.4 formats using the axis directive. This will be available in GDAL/OGR 1.8.0. In the meantime those wanting TMSO support can use PROJ.4 and GDAL "from trunk".

BIBLIOGRAPHY

  1. http://lists.maptools.org/pipermail/proj/2000-September/000100.html
  2. http://www.civildesigner.com/
  3. http://www.modelmaker.co.za/
  4. A discussion of the South African datums: http://web.archive.org/web/20080621122748/http://w3sli.wcape.gov.za/SURVEYS/MAPPING/wgs84.htm
  5. A derivation of the TM projection: http://www.dwa.gov.za/iwqs/gauss/gauss.html
  6. A discussion of the Namibian map system: http://www.mme.gov.na/gsn/nam-map-system.htm