The Malaysian CRS monster

The issues affect the following coordinate reference systems (CRSs):

• Kertau (RSO) / RSO Malaya (m) (EPSG code 3168) used in the Malay Peninsula;
• Timbalai 1948 / RSO Borneo (m) (EPSG 29873) used in Malaysian Borneo;
• GDM2000 / Peninsula RSO (EPSG 3375), the new standard for the Peninsula;
• GDM2000 / East Malaysia BRSO (EPSG 3376), the new standard for Borneo;

though I will only deal in detail with the first of these.

1. Beware of the impostor:

ArcGIS has a CRS called Kertau RSO Malaya (m) as well as one called Kertau (RSO) RSO Malaya (m) . I hope you spotted the difference! Very similar names for two different things. The second one ("(RSO) RSO") conforms to EPSG 3168. The first one does not: it has a different datum, a different ellipsoid, a different azimuth, and a different false easting; it doesn't conform to anything. (Thanks to Chee Pheng and the folks at WCS Malaysia for checking on this.)

If you are using ArcGIS, be really careful which of these you are using: look for (RSO) RSO in the name. You can check a shapefile by opening the *.prj file in a text editor (eg, Notepad) and looking at the start of the WKT:

• PROJCS["Kertau_ RSO_RSO _Malaya",... good.
• PROJCS["Kertau_RSO_Malaya_Meters"... bad!

2. Two names, one projection

Here the issue is two very different names but referring to the same thing. The Rectified Skew Orthomorphic (RSO) projection is the same as the Hotine Oblique Mercator projection.

In 1569 Geraldus Mercator published his map of the world , wrapping his flat map around the globe so that it touched along the equator; distortion is minimal at the equator but increases as you move away to the north or south. Wrapping the globe with the paper touching along a north-south meridian is a better solution if you live far from the equator: centre your map on the meridian of your choice, producing a Transverse Mercator map. If the area you are mapping doesn't run north-south, you can use any great circle as your centre line, resulting in an Oblique Mercator projection. First used for Switzerland, the Oblique Mercator projection was adapted for Malaysia in the 1940s by Martin Hotine , hence the name "Hotine Oblique Mercator". But Hotine himself named it "Rectified Skew Orthomorphic (RSO)", the term still generally used in Malaysia. See EPSG Guidance Note 7-2 .

The two names are a problem when the projection details are written in Well-Known Text (WKT) format for shapefiles. ArcGIS uses the RSO name, QGIS and R, Hotine Oblique Mercator. The name included in the shapefile from one program is not recognised by another program.

3. The Case of the Missing Gamma

To use the Oblique Mercator projection, you need to specify the latitude and longitude of the centre of the map and the angle of the centre line at the map centre; this is the Azimuth in WKT, +alpha in proj4 notation.

Points are then mapped onto a u-v grid, with u being the distance along the centre line and v the distance from the centre line. In most cases, u = 0 corresponds to the map centre, but Hotine chose to set u = 0 at the point where the centre line crosses the equator, as this simplifies the calculations; this is indicated in WKT by adding _Natural_Origin to the projection name and in proj4 with +no_uoff .

The coordinates on the u-v grid must then be rotated to give the usual x-y grid (this is the "Rectify" bit in RSO). If u = 0 is the map centre, the rotation required is given by the Azimuth. But if u = 0 is at the equator, the rotation is not the same, and needs to be specified: this is "XY_Plane_Rotation" or "rectified_grid_angle" in WKT, +gamma in proj4 lingo. The difference between +alpha and +gamma is only 0.1 degrees, but that corresponds to an error of more than 1 km over the length of the Malay Peninsula.

When QGIS and R save shapefiles, the WKT does not specify "XY_Plane_Rotation" or "rectified_grid_angle".

Update 21 March 2018: However, QGIS saves an extra *.qpj file to the same location as the *.shp file, and this does have the correct parameters and the EPSG codes. When QGIS opens a shapefile it uses the *.qpj file instead of *.prj, so it reads correctly.

When a shapefile is opened in R with rgdal::readOGR , it looks at the *.prj file, and +gamma is simply missing, whether the shapefile comes from QGIS or ArcGIS. If the *.prj file is removed and the *.qpj file renamed to *.prj, +gamma is read correctly.

Since +gamma is only relevant for Malaysian projections, the oversight is understandable (if not forgivable).

So what to do?

Stop using shapefiles!

Use either the GeoPackage format (if you are using QGIS or R) or Geodatabase (for ArcGIS). ArcGIS 10.2.2 or later, QGIS 2.12.2 or later, and recent version of rgdal can read both GeoPackage and Geodatabase input, and the proper CRS parameters are correctly written and read.

Stop using the Kertau RSO Malaya CRS in ArcGIS!

And convert any existing files you have that use it to the proper Kertau (RSO) RSO Malaya CRS. I'm not an ArcGIS user, but it should be possible to write a Python script and do this as a batch job.

Don't manually assign a CRS to an unknown shapefile!

I fear that a lot of trouble has been caused by folks reading a shapefile using Kertau RSO Malaya into QGIS or R, and manually assigning EPSG 3168. This is incorrect, but will be used when the data are saved again. How many shapefiles on your system have gone through this process?

It may still be necessary to manually assign a CRS, but make sure you know what the correct CRS is.

Hat tip : Thanks to Fen and Chee Pheng for information and checking.

Coordinate reference systems are foundational to spatial analysis, anchoring every map and measurement to a defined mathematical model of the Earth's surface. When those definitions are applied inconsistently across software, subtle distortions creep into distance, area, and position calculations. Researchers working with wildlife data, habitat layers, or sampling grids quickly discover that a mismatched CRS can shift a camera-trap location by hundreds of metres or place a transect on the wrong side of a ridge. For ecological and conservation work, such errors compromise density estimation, occupancy modelling, and any analysis that depends on accurate spatial relationships between animals, people, and the landscape.

National mapping agencies often adopt local projections that minimise distortion within their own territory, even when international standards like UTM are widely available. A single UTM zone may be only six degrees wide, which is narrow compared with the longitudinal span of many countries, and zone boundaries fall arbitrarily across the terrain rather than along natural or political edges. Where a country straddles a boundary, users must either accept discontinuity or stitch projections together. Local systems are designed to preserve shape and distance more faithfully across the whole region, which is appealing for cartographic display, regulatory mapping, and long-term archival records held by national survey departments.

Software ecosystems, however, do not always implement every local projection correctly. Datum parameters, transformation grids, and unit conventions can be encoded differently across libraries, and the differences are rarely visible until a project is overlaid against an independent reference. Bug reports and forum threads sometimes acquire memorable nicknames that linger in the community long after the underlying code is fixed. Such "monsters" tend to resurface whenever a new release changes default behaviour, when an operating system updates its projection tables, or when analysts migrate projects between QGIS installations on Windows, macOS, and Linux and find that identical coordinates no longer align between machines.

Bayesian and capture-recapture analyses are particularly sensitive to spatial inputs because movement models, detection functions, and distance-sampling estimators all rely on accurate coordinates. In secr, wiqid, and related R packages, the spatial component often passes through additional processing steps that assume a planar metric surface. A skewed CRS can inflate home-range estimates, distort nearest-neighbour distances between detectors, and bias the posterior distributions produced by MCMC samplers. Even when the statistical model is correctly specified, contaminated inputs propagate through likelihoods, priors, and derived quantities, making diagnostics harder to interpret and chains slower to converge.

Reproducible workflows therefore depend on explicit CRS metadata and on knowing how each tool interprets the codes passed to it. Documenting the EPSG identifier, the datum, and the projection used at every stage of a project allows collaborators to replicate results and to diagnose discrepancies when outputs disagree. Where local projections are necessary, transforming to a common system before any cross-border analysis keeps camera-trap arrays, transect lines, and habitat covariates aligned. Awareness of the underlying mechanics, rather than blind trust in default settings, remains the most reliable defence against the small inconsistencies that can quietly undermine otherwise careful ecological inference.