RidgeText's Allan Bogh Moves Map Data Out of the LLM Context Window

Why it matters

RidgeText shows a practical pattern for AI products: let the model orchestrate, but keep bulky domain data in application state where it is cheaper, testable, and deterministic.

Allan Bogh, the founder and lead engineer behind RidgeText, has detailed a map-rendering architecture that keeps large GeoJSON payloads out of the language model while still letting users request layered outdoor maps over SMS.

In a June 18th technical post, Bogh describes how RidgeText now answers prompts such as a request for a fire perimeter map with trails overlaid by returning a single composed image. The model decides which layers to ask for. RidgeText's server stores the raw geographic data, renders it against a Mapbox base image, and sends the finished map back through the SMS flow.

That design choice says a lot about the kind of company Bogh is building. RidgeText is an AI outdoor assistant that runs through ordinary SMS and satellite texting, with no native app in the critical path. Bogh's background is in frontend and scalable systems, with RidgeText's about page listing prior engineering work at Walmart Global Tech, Tesla, and Uber. The product's premise is narrow and practical: if a hiker, hunter, guide, or camper can send a text, RidgeText should be able to return trail maps, weather, safety guidance, and other information when mobile data is unavailable.

The June post is a technical disclosure rather than a financing announcement. No outside investors, valuation, or institutional funding are disclosed in the materials reviewed. RidgeText presents itself as a founder-led product selling subscriptions directly, with a free tier and paid plans listed at $4.99 per month for Explorer and $9.99 per month for Ranger on its pricing page.

The real bottleneck is the model as data pipe

Bogh's map problem starts with a common failure mode in AI products: the LLM gets asked to carry data it does not need to understand.

The naive implementation would fetch wildfire data, return the raw GeoJSON to the model, and then have the model pass that GeoJSON into a rendering tool. RidgeText says a modest wildfire dataset can run 50 KB to 500 KB of raw GeoJSON. Using the rough estimate of one token per four bytes, the high end of that range is about 125,000 tokens before the assistant has written a single useful sentence.

That is expensive when it fits and brittle when it does not. The model is then serving as a courier for polygon coordinates. It cannot reliably simplify them, validate them, or reason over the full geometry. It can, however, drop content, summarize the wrong thing, or exceed the context budget.

RidgeText's fix is what Bogh calls a layer-first pattern. A data-fetching tool stores its result server-side and returns only an acknowledgment to the model. In the example from the post, a wildfire layer call returns a queued status, a layer ID, and a feature count of 847. A trail layer call returns a queued status and a feature count of one. A later generate_map() call drains the queue and returns a map URL.

In the example diagram, each tool returns about 50 bytes, so the model sees roughly 150 bytes of acknowledgments instead of the full geospatial payload. The raw GeoJSON remains in server memory until the renderer consumes it.

Why RidgeText kept Mapbox at the base layer

The Mapbox part of the post is easy to misread. RidgeText is using a Mapbox Static API image as the base tile for terrain, roads, and labels. RidgeText says Mapbox does not receive the GeoJSON overlays. Those overlays are composited on RidgeText's side.

That distinction matters because RidgeText is building for constrained messaging channels. A user texting from a satellite-capable phone does not need an interactive web map. The product needs a deterministic image that can be sent back through the conversation. Bogh writes that RidgeText projects each feature set onto the base image, composites the layers using canvas, uploads the result, and returns a single image URL.

RidgeText's in-process layer queue is keyed by session ID and has a 30-minute TTL, according to the post. Bogh is careful about the abstraction: Redis, a database, or a request-scoped context could hold the same kind of intermediate state. The point is that state belongs in the application, where it can be tested and expired, rather than in the prompt.

The ordering model also borrows from Mapbox's layer stack. Each retrieve_* tool appends to an ordered array. generate_map() renders in insertion order, so earlier layers sit underneath later layers. The LLM controls the order by the sequence of tool calls without touching coordinates or styles directly.

Bogh leaves room for a different renderer later. RidgeText's layer descriptors follow a Mapbox-compatible format, so RidgeText could swap static tiles for a headless Mapbox GL JS renderer running in Playwright if the product needs 3D terrain, richer blending, or animated layers. That is an architectural option, not a disclosed partnership with Mapbox or Playwright.

A small startup pattern with broader AI product lessons

RidgeText's implementation is specific to outdoor maps, but the post is really about tool design. Many AI applications still route large intermediate payloads through the model because that is the fastest way to make a prototype work. The pattern becomes costly in production when logs, documents, geospatial files, analytics rows, or enrichment datasets move through the context window without requiring natural-language reasoning.

Bogh's formulation is simple: if Tool A fetches data and the model immediately passes that same data to Tool B, the model is doing pipeline work. RidgeText keeps the orchestration decision with the LLM and moves the heavy payload into application memory.

There is a tradeoff. RidgeText says the LLM cannot reason about the underlying geometry of a queued layer. It knows a trail was added and how many features it contains, but it does not know the coordinates. If a user asks for the nearest city to a trail, RidgeText would need a separate tool that returns that answer as text. Multi-turn map refinement is also limited if layers expire after the current turn. The post describes a session-keyed queue with a 30-minute TTL, which could enable follow-up requests such as zooming, changing style, or adding another data source.

Those limitations are healthy product boundaries. Bogh is not trying to make the model own every piece of the map. He is using the model where language helps: interpreting the request, choosing data sources, sequencing tools, and explaining the result. The renderer handles the image. The queue holds the intermediate state. The user gets a map through the same SMS thread.

That fits RidgeText's broader positioning. The homepage compares RidgeText with Garmin inReach, SPOT, Zoleo, and AllTrails, while also stating that RidgeText is an AI trail assistant rather than a satellite communicator or a replacement for dedicated SOS hardware. Its strongest claim is convenience, not emergency-grade communications: no extra device, no app download, and a text-message interface that can run over supported satellite SMS plans.

For a solo-founder product, the architecture is also a distribution bet. RidgeText is trying to make AI useful in moments when the normal mobile internet stack is degraded. In that setting, the user will forgive the absence of a glossy interface faster than they will forgive a missing map, a slow response, or an LLM that burns context on coordinates it never needed to read.