The Hilbert curve is a continuous fractal that visits every cell of a 2ⁿ × 2ⁿ grid exactly once — and does it while keeping neighbours in 1-D close in 2-D. That's why spatial databases (PostGIS, SQLite R*-Tree, Bing Maps quadkeys, MongoDB geohash indexes) sort records along a Hilbert order: a range scan of consecutive rows on disk gives you a compact 2-D region, not a random splatter.
Both directions use only bitwise operations. The order-n curve is defined recursively: the four 2×2 quadrants (bottom-left, top-left, top-right, bottom-right) are each an order-n − 1 curve, with the bottom-left rotated one way and the bottom-right rotated the other so the four sub-curves stitch together into a single continuous path. The elegant Hamilton-Ross scheme reads two bits of d at a time from the most significant end, decides which quadrant, translates (x, y) into it, and rotates+reflects the local coordinate frame according to a compact lookup — the whole conversion is O(n) with no floating-point math. On this page every cell you see went through exactly that loop; hover any cell and the sidebar shows the same d that a spatial index would store.
A geospatial query like "return all points near (lat, lon) within R" is a 2-D range query; disks and B-tree indexes love 1-D range queries. If the coordinates get flattened to a 1-D key that groups nearby 2-D points together, the range query becomes a small number of narrow 1-D scans. A raster Z-order (Morton) key is fast to compute but has ugly seams where nearby cells jump to distant keys; the Hilbert curve has no seams — every step moves to a 4-neighbour — so its clustering ratio is measurably tighter, at the cost of a slightly more complex mapping. Google S2, Bing Maps quadkeys, GeoWave, and PostgreSQL's Hilbert R-tree bulk-loader all use variants of this curve.