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
| Geographic | Projected | |
|---|---|---|
| Coordinates | Latitude, longitude | Easting, northing |
| Units | Degrees | Metres, or feet |
| Surface | The ellipsoid itself | A plane |
| Distance between points | Requires spherical maths | Ordinary arithmetic |
| Coverage | The whole Earth | One zone, with distortion growing outside it |
| Typical values | 51.5074, −0.1278 | 542318.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.
| Code | System | Where you meet it |
|---|---|---|
| EPSG:4326 | WGS 84, latitude and longitude | GPS, the default for "just give me coordinates" |
| EPSG:3857 | WGS 84 / Pseudo-Mercator | Web map tiles. Not for measurement. |
| EPSG:326nn | WGS 84 / UTM zone nn North | The common projected choice worldwide |
| EPSG:327nn | WGS 84 / UTM zone nn South | As above, southern hemisphere |
| EPSG:27700 | OSGB36 / British National Grid | UK survey data |
| EPSG:4979 | WGS 84, three-dimensional | Where 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 ID | Contents | Used by |
|---|---|---|
| 34735 | GeoTIFF key directory — the CRS as numeric keys | LAS 1.0–1.3, and 1.4 with legacy point formats |
| 34736 | GeoTIFF double parameters | Values referenced by the key directory |
| 34737 | GeoTIFF ASCII parameters | Text referenced by the key directory |
| 2112 | OGC coordinate system WKT — the CRS as a text description | LAS 1.4; required with point formats 6–10 |
| 2111 | OGC math transform WKT | Rare |
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
| Symptom | Likely cause |
|---|---|
| Cloud appears near 0,0 off West Africa | Projected coordinates being read as degrees |
| Cloud is in the right country, a few hundred metres out | Datum mismatch — right projection, wrong datum |
| Cloud is in a completely different part of the country | Wrong UTM zone, or wrong grid entirely |
| Horizontally perfect, vertically out by tens of metres | Ellipsoidal versus orthometric heights |
| Vertical error that varies gradually across the site | Geoid separation, applied as a constant or not at all |
| Coordinates are small numbers near zero | A local or scanner coordinate system, not georeferenced |
| Two tools disagree about the CRS of one file | Both 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.