A Map Is Evidence, Not an Answer: Building Ghost Shore for 1850s Bengaluru

Submission for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

What if an old map could help us investigate the city we walk through today?

Imagine looking at a map from the 1850s. You notice a label, a strange outline, or a patch of hatching. You wonder whether it represents a water body, an old tank, or a landscape feature that no longer exists.

It's tempting to jump straight to the answer.

But a historical map is not ground truth. A plausible interpretation is not a verified discovery. And an AI assistant that sounds confident can make the gap between the two even harder to see.

That is the problem behind Ghost Shore.

Ghost Shore is an evidence-first historical map explorer for a c.1854 Plan of Bangalore. It combines a feature catalog, a source-grounded research assistant, and a field expedition companion designed to take research beyond the screen.

The central idea is simple:

AI should help us ask better questions about the real world—not manufacture certainty.

Project: Ghost Shore on GitHub

Live demo: https://ghost-shore-r449.onrender.com

Why build this?

Historical maps are fascinating because they show us a different version of a place we think we know.

But comparing an old map with a modern city involves several difficult questions:

• What does the historical document actually show?
• How reliable is its alignment with modern geography?
• Which interpretations are supported by evidence?
• What additional sources or observations would help us investigate them?

I wanted to build a tool that keeps those questions visible instead of hiding uncertainty behind an attractive visualization.

Ghost Shore does not claim to have discovered a vanished lake, reconstructed a lost landscape, or proved that a historical feature survives today. Its three cataloged candidates remain marked pending_human_review.

That distinction is intentional.

What I built

1. An interactive historical map explorer

The frontend uses vanilla HTML, CSS, and JavaScript, with a lightweight Python backend.

The viewer is designed around image-pixel coordinates rather than pretending that every point on an old map can be placed accurately on a modern street map.

The original historical scan is currently excluded from the public repository while its redistribution rights are being verified. Consequently, a fresh deployment or clone may not have access to the scan. The repository documents this limitation rather than substituting an invented historical image.

2. A catalog that preserves uncertainty

Ghost Shore stores candidate features in JSON and validates their structure against a JSON schema.

Each candidate can carry its own evidence, provenance, uncertainty, and review status. The catalog supports searching, filtering, and inspecting individual candidate dossiers.

A label printed on a historical map is an observation about a document. It is not, by itself, proof of a feature's exact identity, extent, or present-day existence.

That difference matters when building tools for historical research.

3. An AI research assistant with explicit limits

The assistant is designed to work with a candidate record and source excerpts supplied to it.

Its documented validation checks include rejecting unsupported verbatim claims, unsupplied coordinates and URLs, and claims that a feature has disappeared. These are safeguards, not a guarantee that every possible error or misleading interpretation will be caught.

The project has two paths:

• Mock mode: deterministic, offline behavior that does not require a model API request.
• Live mode: an implemented integration with Thinking Machines Tinker, intended to use a language model.

An important limitation: I have not verified successful live inference end to end. The web interface uses the mock path by default, so a response shown there must not be mistaken for a live model-generated result. I have not trained or fine-tuned a model.

I prefer to make that limitation explicit rather than claim an AI capability I haven't demonstrated.

4. Touch Grass: taking research outside

The field expedition companion connects desk research with structured observations in the real world.

It includes:

• A 12-item observation checklist.
• Browser-local notes saved using localStorage.
• A printable field worksheet.
• Safety guidance for daylight observations from public places.

The checklist covers topography, visible surface infrastructure, ecological and heritage indicators, and questions that may need further archival research.

The safety rules are part of the design: stay on public paths, never trespass, and never enter storm drains, canal beds, construction sites, or dangerous terrain.

Most importantly, an observation is not proof. A depression in a street, an unusual road name, or a visible drain cannot independently establish that a particular historical feature existed there.

The goal is to gather better questions and observations—not to force a discovery.

The uncomfortable engineering decision: don't fake precision

I experimented with georeferencing the historical sheet using ground control points.

The recorded trial had an RMSE of approximately 87.63 metres. The candidate regions also lie outside the area covered by those control points, meaning their locations would require extrapolation.

That makes a confident modern map overlay difficult to justify.

Instead of displaying precise-looking latitude and longitude coordinates, Ghost Shore keeps the candidate geometry in the source image's pixel space.

This is not a solved georeferencing problem. It is a deliberate decision not to present uncertain results as accurate ones.

Sometimes the most useful feature in a research tool is the claim it refuses to make.

What I learned about AI guardrails

A validator can help constrain what an assistant says, but it cannot make the underlying sources trustworthy.

A statement may appear verbatim in a source excerpt and still be used out of context. A source itself may be incomplete or mistaken.

That is why I see the validator as one layer of a research workflow, not an automatic truth detector.

The deterministic mock mode is useful here, too: it allows the offline behavior and validation rules to be exercised without depending on a live model request. The live integration still needs an end-to-end verification.

How it is built

• Frontend: HTML, CSS and vanilla JavaScript.
• Backend: Python standard-library HTTP server.
• Data: JSON feature catalog and JSON Schema validation.
• Image tooling: Pillow.
• Tests: Python unittest.
• AI integration: an offline mock path and an implemented, not yet end-to-end-verified, Tinker integration.

The repository is open source under the MIT license for its code and documentation. The historical scan is a separate asset whose redistribution rights are still being checked.

What changed during challenge week?

Ghost Shore existed before this challenge week, and I want to be transparent about that.

During this week, I focused on preparing the project for public evaluation, reviewing its documentation and limitations, and working toward a deployable demonstration. This is not a claim that the entire project was created from scratch during the challenge.

The challenge has also pushed me to think beyond whether an application runs: can another person understand its limits, inspect its evidence, and use it responsibly?

Try it and contribute

Repository: https://github.com/ohm-7643/ghost-shore-

The repository includes setup instructions, the feature catalog, schema validation, and the offline assistant example. Full map-viewer functionality requires a lawfully reusable copy of the historical scan at the documented path.

Live demo: https://ghost-shore-r449.onrender.com

Contributions that would help include archival sources, better-supported control points, human review of candidate features, tests for the validator, and improvements to the accessibility and usability of the field worksheet.

What's next?

1. Verify the live AI integration end to end.
2. Improve georeferencing with additional and held-out control points.
3. Build a more explicit human-review workflow for candidate features.
4. Resolve the scan's redistribution rights or find a suitable reusable source.
5. Test the field worksheet in actual use and improve it based on feedback.

One question for you

If you were building an AI tool around uncertain historical evidence, where would you make it say “I don't know” most clearly—and how would you do that without making the tool useless?

I'd love to hear how other developers approach uncertainty, provenance, and responsible AI in real-world projects.

Comments

[zrycsbpuss5d]

Bài viết này chạm đúng vào một vấn đề cốt lõi mà ít người nói ra: bản đồ lịch sử không phải là "ground truth" — chúng là sản phẩm của quyền lực, giới hạn công nghệ, và định kiến của người vẽ. Cách bạn xử lý "Ghost Shore" bằng cách cross-reference giữa bản đồ thuộc địa, ghi chép hành chính, và dữ liệu địa hình hiện tại là approach đúng chuẩn.

Một điểm thực tế từ kinh nghiệm làm GIS historical: projection mismatch là killer. Bản đồ thập niên 1850 thường dùng local datum (Everest 1830 cho India) trong khi dữ liệu hiện tại là WGS84. Nếu không reproject đúng cách, sai số có thể lên tới hàng trăm mét — đủ để "dời" cả một dòng sông hoặc bờ biển. Bạn có nhắc đến quy trình transform nào không?

Cũng thấy thú vị cách bạn dùng open-source toolchain thay vì ArcGIS. GDAL/OGR + QGIS + Python scripts cho batch processing là stack vững chắc, nhưng khâu manual QA/QC vẫn tốn 70% effort. Có فكر nào để semi-automate việc flag các feature conflict giữa các nguồn không? (ví dụ: bờ biển trên bản đồ 1854 không khớp với contour 5m từ DEM hiện tại)

Tham gia Hacktoberfest với project này là move thông minh — historical GIS cần nhiều contributor hơn, đặc biệt là PS: the tool I meant is on labagent .tech