Skip to content
LidarKit

What is a CRS in LiDAR data?

The metadata that decides whether your coordinates mean anything at all.

A point in a LAS file might read 542318.27, 5740921.88, 43.19. Three numbers. Where is that?

Unanswerable without more information. The numbers are a position within some system of measurement, and until you know which system, they locate nothing. That system is thecoordinate reference system — the CRS — and it is the piece of metadata most likely to be missing, wrong, or quietly ignored.

A wrong CRS is a uniquely awkward kind of error, becausethe file still opens and still looks correct. The points sit in the right relationship to each other; the building is still next to the road. Nothing is visibly broken until the cloud is combined with something else, and then it is in a field two kilometres away, or three hundred metres underground.

What a CRS actually specifies

Three things, and separating them explains most of the confusion:

  • A reference surface — the ellipsoid, a smooth mathematical approximation of the Earth's shape, defined by its size and flattening.
  • A datum — where that ellipsoid sits relative to the actual planet. Two datums can use the same ellipsoid and still place the same coordinate metres apart.
  • A projection, for projected systems — the rule for flattening the curved surface onto a plane.

Geographic and projected

GeographicProjected
CoordinatesLatitude, longitudeEasting, northing
UnitsDegreesMetres, or feet
SurfaceThe ellipsoid itselfA plane
Distance between pointsRequires spherical mathsOrdinary arithmetic
CoverageThe whole EarthOne zone, with distortion growing outside it
Typical values51.5074, −0.1278542318.27, 5740921.88

Point clouds are almost always projected, and the reason is practical. LiDAR data is measured in metres, and you want to compute distances, areas and volumes with it. In a geographic system a degree of latitude is a fixed distance but a degree of longitude shrinks toward the poles, so the same angular step covers different ground depending on where you are. Worse for point clouds specifically: the scale and offset thatstore coordinates as integerswould be expressing degrees, so a scale of 0.001 — a millimetre in a projected system — would be about 100 metres of longitude.

If you open a cloud and the coordinates look like−0.1278 rather than a six-figure easting, it is in a geographic CRS, and it is worth asking why.

UTM, the usual answer

Most projected systems for survey work are Transverse Mercator variants, and Universal Transverse Mercator is the most common. UTM divides the world into sixty six-degree-wide zones, each with its own projection tuned so distortion stays small within it. Coordinates are metres from the zone's origin.

The practical consequence is the zone boundary. Two adjacent survey areas can fall in different zones, and their coordinates will be wildly different despite being a few kilometres apart. Merging them requires reprojecting one — which is a real transformation of every point, not a metadata edit.

EPSG codes

Describing a CRS in prose is unreliable: "British National Grid" and "OSGB 1936 / British National Grid" may or may not be the same thing to a given piece of software. EPSG codes solve this by numbering entries in a public registry, so a code is an exact reference rather than a name that needs interpreting.

CodeSystemWhere you meet it
EPSG:4326WGS 84, latitude and longitudeGPS, the default for "just give me coordinates"
EPSG:3857WGS 84 / Pseudo-MercatorWeb map tiles. Not for measurement.
EPSG:326nnWGS 84 / UTM zone nn NorthThe common projected choice worldwide
EPSG:327nnWGS 84 / UTM zone nn SouthAs above, southern hemisphere
EPSG:27700OSGB36 / British National GridUK survey data
EPSG:4979WGS 84, three-dimensionalWhere an ellipsoidal height is part of the system

Note that EPSG:3857 is a presentation system. It is fine for drawing a map and wrong for measuring one, because its scale distortion grows substantially with latitude.

The vertical datum, which causes most of the trouble

Horizontal CRS problems are common and usually obvious — the data lands in the wrong place. Vertical datum problems are less common, less obvious, and considerably more expensive.

There are two ways to express a height, and they are not the same:

  • Ellipsoidal height — distance above the reference ellipsoid. This is what GNSS measures directly. It is geometrically clean and has no physical meaning: water does not flow downhill with respect to an ellipsoid.
  • Orthometric height — distance above thegeoid, the equipotential surface that approximates mean sea level. This is what "height above sea level" means, what national height systems use, and what behaves correctly for anything involving water.

The gap between them is the geoid separation, and it is not small. Globally it ranges from roughly −100 to +85 metres, varying smoothly across a country. So the same physical point can be recorded as 43.19 m or as 88.4 m depending purely on which datum was used, with no error and no ambiguity in either number.

Two consequences worth internalising. First, a point cloud whose heights are ellipsoidal and a terrain model whose heights are orthometric will disagree by tens of metres, and nothing in either file will complain. Second, because the separation varies gradually across a region, a mismatch does not look like a constant offset — it looks like a gentle tilt, which is much easier to mistake for a genuine surveying error.

Converting between them requires a geoid model for the area. It is a real computation, not a constant, and it is one of the most common sources of serious error in elevation work.

Where the CRS lives in a LAS file

In a LAS file the CRS is stored in avariable length record with the user ID LASF_Projection. Which record depends on the version:

Record IDContentsUsed by
34735GeoTIFF key directory — the CRS as numeric keysLAS 1.0–1.3, and 1.4 with legacy point formats
34736GeoTIFF double parametersValues referenced by the key directory
34737GeoTIFF ASCII parametersText referenced by the key directory
2112OGC coordinate system WKT — the CRS as a text descriptionLAS 1.4; required with point formats 6–10
2111OGC math transform WKTRare

Bit 4 of the header's global encoding field declares which is authoritative. If set, the WKT record governs; if clear, the GeoTIFF keys do. A file can legitimately carry both — and can therefore carry two CRS definitions that disagree, with one bit deciding which one readers should believe. When a file has been through several tools, that bit is not always right.

All of this lives in the header area at the start of the file, before any point data, which is why it can be read essentially instantly.Inspect a LAS or LAZ file's coordinate system — from disk or by URL — and it will report which record the CRS came from, show the WKT, and say when a file contains both kinds and they do not agree.

How CRS metadata gets lost

The most important thing to know here is thatlosing a CRS is easy and silent.

The specific trap for LAZ conversion: the straightforward way to build a LAZ writer is to hand the points to a compression library and let it write the file, and several such libraries rewrite the header anddiscard every user VLR — includingLASF_Projection. The output opens perfectly, contains every point, and has no coordinate system. Nothing reports an error.

This site's LAZ to LAS andLAS to LAZ converters assemble the LAZ container directly rather than delegating it, specifically so that VLRs and EVLRs survive the round trip — a property the test suite checks byte for byte. How it works covers the mechanism.

Other routine ways a CRS goes missing:

  • Text intermediates. Exporting to XYZ or CSV drops every piece of metadata the format cannot express, which is all of it.
  • Local scanner coordinates. A terrestrial scan starts in the scanner's own frame with no CRS, correctly. It becomes a problem only when someone assumes otherwise —E57 files routinely and legitimately have no CRS at all.
  • Assumed defaults. Software that silently assumes WGS 84 for an unlabelled file produces confident, wrong georeferencing.

Symptoms and causes

SymptomLikely cause
Cloud appears near 0,0 off West AfricaProjected coordinates being read as degrees
Cloud is in the right country, a few hundred metres outDatum mismatch — right projection, wrong datum
Cloud is in a completely different part of the countryWrong UTM zone, or wrong grid entirely
Horizontally perfect, vertically out by tens of metresEllipsoidal versus orthometric heights
Vertical error that varies gradually across the siteGeoid separation, applied as a constant or not at all
Coordinates are small numbers near zeroA local or scanner coordinate system, not georeferenced
Two tools disagree about the CRS of one fileBoth a WKT and GeoTIFF keys present, disagreeing

Good practice

  • Check the CRS before starting, not after. It takes seconds in the inspector and saves rework.
  • Record the vertical datum explicitly, in writing, alongside the horizontal one. It is the piece most often left implicit and most costly to get wrong.
  • Prefer EPSG codes to names in any specification or handover note.
  • Verify after every conversion. Inspect the output, not just the input — this is exactly where a CRS disappears.
  • Do not invent a CRS for a file that has none. An honestly unreferenced cloud is recoverable; one confidently labelled with a guess is worse than the problem it solved.

Frequently asked questions

What is a CRS?
A coordinate reference system is the definition that turns three numbers into a place on the Earth. It specifies the shape and size of the reference surface, where that surface sits relative to the planet, and — for projected systems — how the curved surface was flattened onto a plane. Without it, a coordinate is just arithmetic.
What is the difference between a projected and a geographic CRS?
A geographic CRS uses angles — latitude and longitude on an ellipsoid — so distances cannot be computed with ordinary arithmetic and a degree of longitude shrinks toward the poles. A projected CRS uses linear units, usually metres, on a flat plane, so distances and areas work normally within its zone. Point clouds are almost always in a projected CRS.
What is an EPSG code?
A number identifying an entry in a public registry of coordinate reference systems, originally compiled by the European Petroleum Survey Group. EPSG:4326 is WGS 84 in latitude and longitude; EPSG:3857 is the Web Mercator used by web maps. A code is a complete, unambiguous reference to one system, which is why software prefers it to a name.
Why does my point cloud appear in the wrong place?
Usually one of three things: the file has no CRS metadata and the software guessed, the file declares the wrong CRS, or the coordinates are in a local system with no relation to the Earth at all. All three look identical when the file is opened on its own, and only become visible when the data is combined with something else.
What is a vertical datum, and why does it matter?
It is the surface that heights are measured from, and it is defined separately from the horizontal system. An ellipsoidal height is measured from a smooth mathematical ellipsoid; an orthometric height is measured from the geoid, which approximates mean sea level. The two differ by tens of metres in most of the world, so mixing them produces errors far larger than any survey tolerance.
Where is the CRS stored in a LAS file?
In a variable length record with the user ID LASF_Projection. Older files use GeoTIFF keys — records 34735, 34736 and 34737 — while LAS 1.4 files generally carry an OGC WKT string in record 2112. Bit 4 of the header's global encoding field states which of the two is authoritative when a file contains both.
Can I check the CRS of a LAS file without opening the points?
Yes. The coordinate system lives in the header area at the start of the file, so it can be read without touching the point records. The LAS inspector on this site reads it from a local file or from a URL, and reports which record the CRS came from and whether the file contradicts itself.