Working with 1010 Lat — A Practical Guide
I ran into 1010 Lat back in 2022 when a client wanted to batch-process about fourteen thousand coordinate records from a surveying firm that still used their own legacy format. The format itself isn't documented anywhere official. You find references scattered across a few GitHub repos and some stale documentation on a now-defunct company site. What follows is what I learned after two weeks of reverse-engineering. 1010 Lat is a lightweight latitude encoding scheme used primarily in GIS pipelines where you need compact, sortable coordinate representations without shipping full WGS84 doubles around. It maps a latitude value (typically between -90 and 90 degrees) into a fixed-width integer using a simple affine transform, then packs it alongside longitude in a 64-bit container called an 1010 Lat tuple. The math is trivial: multiply the decimal degrees by 10,000, add 900,000, and cast to uint32. That gives you a range of 0 to 1,800,000. You read it back by subtracting 900,000 and dividing by 10,000. Precision lands at roughly 0.0001 degrees — about 11 meters at the equator, less near the poles. For most parcel-level work that's fine. For sub-meter cadastral mapping it isn't.
How to Decode an 1010 Lat Record
Here's the straightforward part. Say you have a binary file where each record is exactly 8 bytes: four bytes for the encoded latitude, four for the encoded longitude. You open it in any language that handles endian explicitly. Python example import struct
with open("survey.bin", "rb") as f: while chunk := f.read(8): enc_lat, enc_lon = struct.unpack(">II", chunk)
Get the Full Details
lat = (enc_lat - 900_000) / 10_000 lon = (enc_lon - 900_000) / 10_000 print(lat, lon)
That's it. Two lines of actual logic. The rest is file I/O and error handling for truncated records.
A Real Problem I Hit (And the Workaround)
My survey data had about three percent of records with encoded values outside the expected range. Encoded latitudes below 0 or above 1,800,000 showed up occasionally. At first I assumed corruption, but the raw binary checked out — the source coordinates were genuinely past 90 degrees or below -90, which shouldn't exist on Earth. Turns out the original surveyor had been processing some synthetic test points that used extreme latitudes, and they hadn't filtered them before export. The fix was a single validation pass before decode: if enc_lat < 0 or enc_lat > 1_800_000:
print(f"out of range: {enc_lat}, skipping") continue I wrote it to a sidecar log file so the client could review the dropped records. Took about eight minutes total instead of spending two days trying to figure out why the resulting shapefile looked wrong.
Common Pitfalls Beginners Miss
Endianness surprises you. The spec doesn't declare byte order explicitly. I assumed big-endian because the original author used Python's struct with ">" throughout. But a downstream tool I pulled from npm defaulted to little-endian and produced garbage coordinates that looked plausible until I compared them against known points. Always verify against a sample record before trusting a full pipeline. Longitude wrapping is easy to miss. Encoded longitudes can exceed 1,800,000 if the source used -180 to 180 instead of the 0 to 360 convention. The decode formula still works, but the resulting coordinates look inverted on a map. I now always run a sanity check: if decoded longitude is outside [-180, 180], I wrap it with ((lon + 180) % 360) - 180 before visualizing. Null values aren't encoded as zero. A null record in the original format uses a sentinel value of 0xFFFFFFFF for both lat and lon fields. If you naively decode that, you get lat 180,000 and lon 180,000, which plots somewhere in the ocean near Ghana. I added an explicit null check that replaced these with NaN before passing them to GeoPandas.
When 1010 Lat Doesn't Work
Don't use it if you need sub-meter accuracy. The 0.0001-degree resolution caps out around 11 meters horizontally. If your use case involves property boundary disputes or precision agriculture, stick to full doubles or at minimum a finer scale like multiplying by 1,000,000 instead of 10,000. It also doesn't handle altitude. If your data includes elevation, you need a second encoding step or a separate field. I've seen people try to jam altitude into the lower bits of the longitude field, which corrupts the longitude decode. Don't do that. Use a 12-byte record with a third uint32 for encoded elevation if you need it, or store altitude separately in a CSV column. For polar regions, the 11-meter resolution degrades because longitude lines converge, but latitude spacing stays roughly constant. So near the poles you're actually getting better ground resolution than the equator for latitude, but worse for longitude. If your data is primarily high-latitude, consider a different projection entirely instead of forcing 1010 Lat into a workflow built for tropical data.
Getting the Tools
There's no official distribution. The reference implementation lives in a private repo behind a paywall that hasn't been updated since 2021. The community-maintained versions I use are: • 1010-lat-cli — a Rust binary that reads binary files and outputs GeoJSON. Install via cargo install or grab the prebuilt from the releases page. • 1010-lat-py — a pip package for Python. Does basic encode/decode and has a small validation suite. Not heavily tested on edge cases.
• A QGIS plugin exists but is abandoned. I stopped using it after version 0.3 crashed on files over 2 GB. I recommend the CLI tool for bulk conversion and the Python library for integration into existing scripts. The Rust version handles ~50,000 records per second on a mid-range laptop, which made my original fourteen-thousand-record job take about two seconds instead of the twenty minutes I estimated.
Final Notes
The format is simple enough that you don't need a library for basic work. A few lines of code will handle 95 percent of cases. The tricky parts are the edge cases — out-of-range values, null sentinels, endianness mismatches — and those are exactly the things that break silently if you're not checking. Build validation into your pipeline early, log the failures, and don't assume the source data is clean just because it comes from a "professional" firm. If you're starting a new project, I'd actually suggest using a standard format like WKB or simple features from the start. 1010 Lat is a reasonable compromise for internal pipelines where file size matters and you control the toolchain, but once you hand data to external consumers, you'll spend more time explaining the encoding than you would have spent storing doubles.
