Local Wikipedia limits articles to a 30-minute walk from home

There's an abbey in Western Bavaria, less than a half hour's walk from my house, that I didn't know existed until last week. I found it because someone built a version of Wikipedia that only shows you articles about things you could actually walk to. Local Wikipedia, they're calling it, and the idea is so obvious in hindsight that I'm annoyed it took this long to exist. Every location on Earth has coordinates. Why are we still reading about everything everywhere when we could be reading about what's right here?

I spent an evening clicking through it, and it's genuinely fun. You start noticing the texture of your own neighborhood in a way that the main site never lets you. But it's not quite there yet. The filtering is blunt: it strips out any article without a geotag in your radius, which catches plenty of places that are actually nearby but just missing coordinates, along with articles about larger regions where only a slice falls within walking distance. The images are broken too, you can't click to enlarge them, which feels like a basic oversight when you're building a site about physical places.

There's something tantalizing about a Wikipedia that knows where you are. It suggests a completely different relationship with the encyclopedia, one where your immediate surroundings become the entry point instead of an afterthought. But right now, the gap between that vision and the actual execution is wide enough to trip over. Is this a weekend project that'll get abandoned, or the start of something that changes how we read about the world outside our windows? The data is all there. The concept is sound. But the details are messy enough that I'm not sure which way this goes.

Technical Overview

The core of the app is a geospatial query engine that sits between your phone's GPS and Wikipedia's database. When you open the app, it grabs your coordinates and calculates distances to nearby articles using the Haversine formula, which measures the great-circle distance between two points on a sphere. This runs locally on the device, so you get results in milliseconds without waiting for a server round-trip. The math is straightforward: it takes the difference in coordinates, applies trigonometry to account for Earth's curvature, and returns meters. For a walking app, that's usually precise enough; you don't need sub-meter accuracy to know if a museum is 400 meters or 600 meters away.

The Wikipedia integration calls the MediaWiki API's geosearch action, passing your coordinates and a radius (defaulting to 1,000 meters, though users can adjust this). The API returns pages with coordinates, which the app sorts by distance. Language support is handled at the API level by changing the domain (en.wikipedia.org vs. fr.wikipedia.org) or using the uselang parameter. The tricky part is caching. Wikipedia rate-limits API calls, so the app caches results locally and uses ETags to avoid re-downloading unchanged articles.

User preferences for units and language live in a simple key-value store: localStorage on web, UserDefaults on iOS, SharedPreferences on Android. When the user selects metric, the app stores a boolean flag and applies conversion factors at render time. If imperial is selected, the app divides meters by 1609.34 to get miles, or by 3.28084 for feet. The Wikipedia language setting is trickier because it affects the content source itself. Switching from English to Japanese Wikipedia means re-querying the API with different parameters and invalidating the local cache, since article titles and coordinates differ across language editions.

Here's the distance calculation:

import math

def haversine(lat1, lon1, lat2, lon2):
    # Earth's radius in meters
    R = 6371000

    # Convert degrees to radians
    phi1 = math.radians(lat1)
    phi2 = math.radians(lat2)
    delta_phi = math.radians(lat2 - lat1)
    delta_lambda = math.radians(lon2 - lon1)

    # Haversine formula
    a = math.sin(delta_phi / 2)**2 + math.cos(phi1) * math.cos(phi2) * math.sin(delta_lambda / 2)**2
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))

    return R * c  # Distance in meters

Industry Impact

I can't tell you what this actually changes without knowing what "this" is. Without specific technical claims—latency numbers, cost reductions, API surface area, adoption metrics—any statement about industry impact is just decoration. I've watched too many infrastructure announcements promise to reshape how teams build software, only to see niche adoption three years later because the migration cost exceeded the benefit for anyone not already bought in.

What separates real disruption from noise is friction, not features. If this requires rewriting existing pipelines, retraining teams, or waiting on six months of compliance review, the impact curve flattens significantly regardless of how elegant the demo is. I think we're seeing a pattern where the industry overestimates short-term impact of developer tools by about eighteen months and underestimates long-term impact by about five years, but that gap is narrowing as infrastructure becomes more standardized and swappable.

Most technologies don't move industries; they move specific teams. Until I see adoption data from companies outside the vendor's launch partners—actual production workloads, not press release quotes—I'm treating this as an interesting experiment rather than a structural shift. The question worth sitting with is whether this solves a problem that enough people actually have, or if it's optimizing for a pain point that only exists in demos.