ST_OrderingEquals

What is ST_OrderingEquals?

ST_OrderingEquals is a PostGIS spatial predicate that returns true when two geometries are exactly the same and their points are stored in the same order. Unlike ST_Equals, which is topology-based, this function is strictly representational.

ST_OrderingEquals(geometry geomA, geometry geomB) → boolean

When would you use ST_OrderingEquals?

Use ST_OrderingEquals when the direction of a linestring matters — for example, checking that two digitized road alignments match vertex-for-vertex in the same order, or detecting whether an edit reversed a linestring's winding. It is also handy for testing round-trip serialization where the exact representation must survive.

1SELECT a.id, b.id
2FROM candidate_roads a
3JOIN reference_roads b ON ST_OrderingEquals(a.geom, b.geom);

FAQs

How is ST_OrderingEquals different from ST_Equals?

ST_Equals is topological: LINESTRING(0 0, 1 1) equals LINESTRING(1 1, 0 0) because they describe the same set of points. ST_OrderingEquals is order-sensitive, so reversing vertices yields false. Use ST_OrderingEquals when direction or exact vertex sequence is part of your data model.

Do the coordinates have to match exactly?

Yes — comparisons are exact. Even a sub-millimetre perturbation caused by floating-point round-tripping will return false. If you need tolerance, snap both inputs to a common grid with ST_SnapToGrid first.

Does ST_OrderingEquals consider Z and M?

Yes. The comparison includes any Z and M coordinates that the geometries carry. Make sure both inputs have the same dimensionality (XY, XYZ, XYM, or XYZM) or the result will always be false.

Is it index-accelerated?

The planner applies a bounding-box equality filter (~=) before the exact comparison, so a GiST index speeds up candidate selection. The exact comparison itself is very cheap — it short-circuits on the first mismatch in the coordinate sequence.