Services
What we can build with your data
The capabilities the OKLocate team built to launch a fast spatial intelligence layer are the same ones that produce data, applications and analysis over other datasets, including the ones that never leave an enterprise.
Every one of these is something we did for ourselves first, with the figures published elsewhere on this site. We are always happy to talk through what you are trying to launch and whether we can get you there faster and cheaper than building it twice.
Deploying an open-source geospatial stack
Open models and open tile formats, running in production rather than in a notebook.
4
open-source models and formats in the pipeline, every licence verified at its source: Clay v1.5, SAM 2, PMTiles, MapLibre GL
How we tackled it ourselves
Everything OKLocate serves runs on one: Clay v1.5 and SAM 2 for the imagery work, PMTiles for the tile archives, MapLibre GL on the client. Four open-source projects carrying production traffic at the edge, every licence verified at its source rather than from memory. The gap we had to close was never capability. These projects are excellent and none of them ships as a service, so the expensive part is the operating, the version pinning and the failure modes nobody documents.
Spatial data consolidation and reconciliation
Many sources describing the same place, made to agree on one parcel, one projection and a stated vintage.
6
documented ways a spatial join returns a confident wrong answer without raising an error
How we tackled it ourselves
We reconciled 11 public sources onto a single record per property, each field traced back to where it came from: USDA NAIP, state LiDAR, Overture Maps building footprints, FEMA USA Structures, the FEMA National Flood Hazard Layer, the USDOT National Address Database, Census ACS, FHFA house prices, DOE LEAD energy costs and two county assessor address files. Eight different formats between them. Volume is not what makes this hard. Six of the failures we hit returned a plausible number and raised no error at all, including two State Plane zones that matched houses 1.82 million feet away and reported a clean zero, and a compound CRS with no EPSG code whose points passed through untransformed.
Clay embeddings for aerial and satellite imagery
Earth-observation foundation models run over imagery, as vectors you can search and cluster.
34,661
houses judged by people to measure the pool detector, with precision, recall and threshold published separately for each boundary type
How we tackled it ourselves
We run Clay v1.5 over USDA NAIP aerial imagery to produce per-property embeddings, then use them to find the rest of a pattern from a handful of examples. What sits on top is measured the way everything here is measured: the pool detector reports 97.2% precision against real parcel boundaries and 97.8% against drawn lots at a stricter threshold, each hand-checked on its own label set, out of 34,661 houses judged by people.
NAIP aerial imagery and LiDAR point cloud processing
Raw LAS and LAZ tiles and USDA NAIP imagery turned into per-property measurements, and kept serviceable afterwards.
675
counties whose LiDAR is processed into 74 measured columns per house
How we tackled it ourselves
We process USDA NAIP aerial imagery at 30 cm and state LiDAR programmes — the Illinois Height Modernization Program among them — into 74 measured columns per house across 413 counties. The surprises were all in the data rather than the algorithms: a 23 GB county archive nested its LAS files one level deeper than the fetcher read, an index archive held two shapefiles where only one matched anything, and building height turned out to have two regimes rather than one. Where the survey classifies building points the height is measured and lands 97.5 to 98.7% within 5 ft; where it does not we derive it from the last return, and on a single-return flight that same method drifts into canopy at 72 to 73.7%. Nothing errored in either case, so the column carries a bldg_src flag saying which regime produced it.
Spatial queries over large datasets
DuckDB, Parquet and Apache Iceberg over hundreds of millions of rows, without a warehouse bill.
36,088,633
houses scored and queryable across 689 counties, on open formats throughout
How we tackled it ourselves
Our 17.4 million houses sit in partitioned Parquet with an Iceberg catalog over them and are queried in place. A filter on one county reads about six files and 200 KB, because each file's column statistics prune the rest before any data is touched. We measured that rather than assuming it, which also told us where it does NOT hold: a single-address lookup in a one-row-group file reads megabytes to return one row.
Hosting large geospatial datasets for performance
PMTiles and Parquet archives served by range request from the edge, at a flat cost and no egress charge.
11
open datasets reconciled, arriving in 8 different formats
How we tackled it ourselves
Our base map is one 8.8 GB archive. A client reads the bytes it needs out of it by range request rather than downloading anything, answered from the nearest of hundreds of edge locations. That is why map loads can be priced flat and why egress is $0, and it is also why a dropped Content-Range header renders a blank map with no error anywhere, which is the kind of thing you learn by running it.
How this works
1
Tell us the problem
The geography, the decision you are trying to make, and what you have tried. Not a requirements document.
2
We scope it honestly
Including when the answer is that our self-serve products already cover it, or that we are the wrong people for it.
3
You keep what we build
Data delivered under an engagement carries storage rights. Nothing upstream of us forbids it, so nothing here does either.
Start a conversation
No form and no discovery call to book a discovery call. Say what you are trying to work out and roughly what scale, and you will get a real answer about whether this is worth doing.