Katha of Temples
A map-driven guide to Indian temples — their stories, architecture and heritage — with a trip planner for people who want to actually go.
Overview
A map-driven guide to Indian temples — their stories, architecture and heritage — with a trip planner for people who want to actually go.
- Interactive maps for discovering temples by location.
- Gallery browsing organised by deity.
- Trip planner for curating sacred-site visits.
The problem
Information about Indian temples is scattered across blog posts and tourism pages, rarely mapped, and almost never organised in a way that helps someone plan a route between several sites.
Who it is for
Travellers, students of architecture, and anyone planning a heritage trip.
My responsibilities
- Built the platform end to end on Next.js and Supabase.
- Modelled temples, deities and locations in PostgreSQL.
- Integrated React-Leaflet for interactive map discovery.
- Built the gallery browsing and trip-planner features.
Product & technical decisions
Relational data for a relational domain
Temples, deities, locations and stories are genuinely relational, so PostgreSQL via Supabase models the domain directly instead of flattening it into documents.
Maps as navigation, not illustration
The map is the entry point to content rather than a decorative panel beside it.
Architecture
How the pieces fit together, from the surface the user touches down to the sources of truth.
Client
- Next.js pages
- React-Leaflet map
Server
- Data fetching
- Trip planner
Data
- Supabase / PostgreSQL
InterfaceApplication logicData & authThird-party
Key functionality
Map discovery
React-Leaflet maps make geography the primary index — you find temples by where they are, which is how a trip is actually planned.
Browse by deity
A gallery system organised around deities, matching how people who care about these sites already think about them.
Trip planner
Curate a set of temples into a planned visit rather than researching each one in isolation.
What went wrong, and what I did
Routing that belonged on the server, not in the map
- Constraint
- The trip planner needed driving distance and journey time between the user and a temple. Calling the public OSRM routing service straight from the browser meant cross-origin failures, and it tied the interface to an external service's response shape.
- Wrong turn
- I treated routing as a client-side map concern and called OSRM directly from the map component — which left route calculation exposed to CORS and forced the front end to understand OSRM's longitude-first coordinates and raw response format.
- What I shipped
- Added a Next.js API route as a routing proxy: it validates the coordinates, converts them to OSRM's longitude,latitude order, calls the routing endpoint server-side, handles unavailable routes and upstream failures, normalises metres to kilometres and seconds to readable hours and minutes, and returns a Google Maps directions link alongside the result.
- Effect
- The browser now calls one stable, application-owned endpoint. Users get a normalised distance, journey time and directions link, and every quirk of the third-party routing service stays behind the API layer.
Where it stands
Katha of Temples is deployed and publicly usable — the full feature set above is live rather than a prototype.
What I would improve next
- Route optimisation between selected temples.
- Contributed photography and stories from visitors.