Sanborn fire insurance maps are used by researchers to see how cities and places have changed over time. While some have been digitized as PDFs, only a subset of those have been georeferenced to a specific location. That lack of georeferencing makes the process of using Sanborn maps cumbersome and slow, and it impedes researchers who use georeferenced Sanborn maps as inputs. This tooling aims to help with that.
How it works: a multi-modal model processes an image of a Sanborn map sheet and extracts street names, rail line names, and house numbers as JSON. That JSON is fed to a deterministic pipeline, which attempts to match it to the correct streets or rail lines in the current city and then performs many layers of validation.
As far as I am aware, the best performing automated approach to this prior to now placed 14% of sheets, using an object detection model (https://www.tandfonline.com/doi/full/10.1080/15420353.2025.2...). This approach places more than 70%, and those placements generally score well against manual human placements: median difference of 5.5 m, with only 11% more than 15 m different. The output generally looks decent on a map.
- ~75% of sheets across the 77 Chicago volumes I have run
- Placement rate varies a lot by volume, from 2% to 97% (2% for a volume of grain elevators in Chicago)
- 64% on a Cleveland volume, run with Chicago-tuned settings
It is not perfect. Some sheets are slightly misaligned, some boundaries between sheets are jagged, and sometimes sheets are placed incorrectly. It (unsurprisingly) struggles where the city grid has changed significantly since the map was drawn (highways destroying neighborhoods, water being filled in, streets removed) and on sheets that are mostly parks or water. It works best on clean grids.
Ideally as open source models improve, this will be possible to run locally. I tried Qwen 3.5, Gemma 4, Minicpm-v4.5 but those did not perform well on this task. It currently supports the OpenAI/Anthropic APIs or shelling out to Claude Code/Codex/OpenCode. I was able to process the available, digitized Chicago volumes within a month using a Claude Code ($200) and OpenAI ($100) subscription.
Adam Cox's OldInsuranceMaps.net is where the human placements I score against come from and his site is the best way for people to contribute to the community. I view autogeoref as a possible assistive tool for researchers who want a way to speed up their georeferencing.
Interesting bit from the repo: there is an agent's plan (presumably unintentionally) checked in two days ago as part of a rewrite from the Vercel AI SDK to pi-agent-core (https://github.com/cloudflare/cloudflare-os/blob/main/plans/...). That plan states "The project is in early alpha — minor behavioral regressions are acceptable and will be fixed as discovered.".
Yeah, I checked that in intentionally. I've started checking in plans under `plans/` so that people can see the plan during code review, and also so I can refer to it when I prompt agents about things related to the plan. My usual process for using AI is I first tell it what I want and have it write out a plan. I then review the plan, make comments, and go back and forth until I like it. Then I ask it to implement. I find this makes the final code output much easier to review -- it's almost always very close to what I want on the first try.
The project is indeed in early stages. That's mentioned in the readme as well.
The reason I had to tell the agent this explicitly is because Fable's original plan called for an overly careful process involving a 2-3 day "spike" to test and derisk. It also wanted to write an elaborate test harness that would run every message through both the old and new paths and compare the results to ensure feature parity. It was way too cautious. I knew that the conversion would actually work fine. And, in fact, it did: the conversion actually fixed more bugs than it introduced.
This is a great write up. I buy the argument against the dark factory approach, but I would be curious to hear if their process has changed at all with Fable/GPT-5.6. I believe the keynote this is based on (www.youtube.com/watch?v=Ib5GBkD555M) was given while Fable was still banned and GPT-5.6 had not yet been released. Has HumanLayer found they still need to follow as deliberate of a pre-work planning process as before? Or do they find that Fable/GPT-5.6 are able to do more with slightly less handholding?
i did a write up on fable while it was out - it can do big refactors, but it does not know what to change without human steering. For that, you need humans to know what to ask for.
---
Sanborn fire insurance maps are used by researchers to see how cities and places have changed over time. While some have been digitized as PDFs, only a subset of those have been georeferenced to a specific location. That lack of georeferencing makes the process of using Sanborn maps cumbersome and slow, and it impedes researchers who use georeferenced Sanborn maps as inputs. This tooling aims to help with that.
How it works: a multi-modal model processes an image of a Sanborn map sheet and extracts street names, rail line names, and house numbers as JSON. That JSON is fed to a deterministic pipeline, which attempts to match it to the correct streets or rail lines in the current city and then performs many layers of validation.
As far as I am aware, the best performing automated approach to this prior to now placed 14% of sheets, using an object detection model (https://www.tandfonline.com/doi/full/10.1080/15420353.2025.2...). This approach places more than 70%, and those placements generally score well against manual human placements: median difference of 5.5 m, with only 11% more than 15 m different. The output generally looks decent on a map.
- ~75% of sheets across the 77 Chicago volumes I have run
- Placement rate varies a lot by volume, from 2% to 97% (2% for a volume of grain elevators in Chicago)
- 64% on a Cleveland volume, run with Chicago-tuned settings
It is not perfect. Some sheets are slightly misaligned, some boundaries between sheets are jagged, and sometimes sheets are placed incorrectly. It (unsurprisingly) struggles where the city grid has changed significantly since the map was drawn (highways destroying neighborhoods, water being filled in, streets removed) and on sheets that are mostly parks or water. It works best on clean grids.
Ideally as open source models improve, this will be possible to run locally. I tried Qwen 3.5, Gemma 4, Minicpm-v4.5 but those did not perform well on this task. It currently supports the OpenAI/Anthropic APIs or shelling out to Claude Code/Codex/OpenCode. I was able to process the available, digitized Chicago volumes within a month using a Claude Code ($200) and OpenAI ($100) subscription.
A small town is cheap to run. `https://github.com/matt-hendrick/autogeoref/tree/main/config...` is a single 14-sheet 1948 volume for Staunton, IL. For that small town, the pipeline placed 11 of 12 sheets with 19 model calls.
Adam Cox's OldInsuranceMaps.net is where the human placements I score against come from and his site is the best way for people to contribute to the community. I view autogeoref as a possible assistive tool for researchers who want a way to speed up their georeferencing.