UPdiKo: The Campus Map That Knows Miagao Better Than a General Map Ever Could

A local navigation stack for UP Visayas that blends offline caches, Supabase, Leaflet, and a Miagao-specific AI guide into one practical system.

8 min read View on GitHub More from Adobo-Mappers

A student stands near the edge of campus, holding a phone that shows a hand-drawn local map. Around the device are small landmarks like a sari-sari store, a pharmacy, a laundry shop, and a tricycle stop, with campus paths and the town blending together in the background. It explains that UPdiKo is built from local detail, not generic cartography.
UPdiKo treats the campus and the town as one navigable system, with the kind of landmarks global maps usually flatten away.
Key Takeaways

The Map Global Platforms Miss

UPdiKo is not trying to out-Google Google Maps. It is trying to solve a smaller, harder problem: how do you navigate a place when the places that matter are the ones global platforms tend to miss?

On a campus and in a town like Miagao, the useful unit is not a highway exit or a chain store. It is the sari-sari store near the gate, the tricycle stop, the laundry shop, the pharmacy, the shortcut between buildings, the thing people actually ask for when they are late, lost, or hungry.

That is the real thesis here. UPdiKo is a community-built navigation system for a place that needs local resolution more than global scale.

UPdiKo’s Real Product Is Local Knowledge

The map is only the surface. The moat is the data: curated locations, photos, tags, and local establishments that turn a campus app into a usable directory of daily life.

What you needGeneric map appUPdiKo
Landmark coverageBroad, uneven, often missing small local placesDense, campus-specific, and Miagao-aware
Local searchBuilt for universal categories and large-area queriesBuilt for the names and habits people in Miagao actually use
Offline usefulnessLimited unless the right data was already cachedDesigned to stay useful with local storage and background refresh
Trust modelDepends on global completenessDepends on local curation and community-maintained detail
Knowledge scopeEverything, everywhereNarrow on purpose

That narrowness is the point. A local map becomes valuable when it knows what not to include, because the best answer is often not more geography. It is the exact place a person meant.

How It Still Works When the Network Doesn’t

The technical trick that matters most is simple to say and easy to get wrong: serve from local storage first, refresh from the backend when needed, and never block the user on a weak connection.

UPdiKo uses local storage as the first response, then refreshes from Supabase in the background when data gets stale.

In practice, this means the app can open, search, and render useful location data even when connectivity is poor. IndexedDB gives the browser a local memory. Supabase acts as the source of truth when the app can reach it.

That is a better experience than a map that simply gives up. It also matches the reality of campus life, where the network may be inconsistent long before the need for directions disappears.

A close-up of a phone screen sits beside a set of small database drawers. One drawer is labeled IndexedDB cache, another Supabase, and a narrow paper strip marked freshness check slides between them like a gate. A temporary pin on the map is shown turning into a permanent place record. It explains the app's offline-first refresh logic.
The app does not wait for perfect connectivity. It uses the fastest available answer, then reconciles with the backend when it can.

Casie Turns Questions Into Places

Casie is the project’s most visible AI feature, but the important detail is not that it chats. It is that it stays local in scope.

Instead of behaving like a general assistant, Casie is constrained to Miagao and wired toward structured lookup behavior. That matters because a map assistant is only useful if it can resolve a vague request into an actual place.

In the repo, that means Gemini function calling feeds a search path like search_locations, which turns natural language into a database query. The effect is less “talk to an oracle” and more “ask a knowledgeable local guide who knows what can be found nearby.”

User asks: "Where can I buy medicine?"
Casie interprets intent
→ search_locations(category: pharmacy, area: Miagao)
→ rank local matches
→ return specific places the map can actually show

That constraint is the win. Narrowing the model’s job makes it less impressive on a benchmark and more useful in a town.

A Simple App Shell, Not a Framework Maze

The architecture follows the same discipline as the product. The codebase seems built to stay legible to contributors who need to move fast, not to impress them with abstraction.

Rather than hiding navigation behind a heavy routing system, the app uses a central section switch in App.jsx. That keeps the state flow visible, which is a good trade when a small team needs to share services and iterate quickly.

The folder structure reinforces that choice. Pages hold high-level views. Components handle reusable UI and map logic. Services isolate data access, caching, and AI calls. The result is not fancy, but it is readable.

That readability matters more than people admit. For a project built around a local community and an academic workflow, clarity is not a compromise. It is part of the product.

What UPdiKo Chooses Not to Be

UPdiKo is the opposite of a generic map app plus a generic chatbot. It does not try to know everything. It tries to know one place extremely well.

DimensionGeneric map plus chatbotUPdiKo
BreadthBroad, multilingual, and general-purposeNarrow, local, and intentionally scoped
Answer qualityOften accurate at a city level, weak at a micro-local levelOptimized for campus-level and town-level precision
Offline behaviorUsually secondaryCore to the experience
AI behaviorOpen-ended conversationConstrained search through local places
Source of trustPlatform scaleCommunity-specific data and curation

That tradeoff is why the project feels bigger than a student app. It is a small example of a larger pattern: local groups building digital infrastructure that reflects local reality better than a universal product can.

Why This Pattern Scales Beyond One Campus

The lesson is not that every town should build its own map from scratch. The lesson is that community-owned knowledge, offline-first storage, and tightly scoped AI can combine into something more reliable than a one-size-fits-all platform.

That pattern is portable. Another campus, another rural municipality, another low-connectivity district could use the same idea: keep the scope small, keep the data local, and make the assistant answer real questions instead of generic ones.

UPdiKo is interesting because it treats local detail as infrastructure. Once you see that, the rest of the stack stops looking like a demo and starts looking like a civic tool.