Pujo Atlas: An Open-Source Durga Puja Map

A combined view, not a guarantee the data is complete

Pujo Atlas gives you a combined view of two datasets, but combining sources doesn't automatically make them complete, up to date, or consistent. A record can be missing, a location can be off, and two directories can describe the same place in different ways. Those are data-quality issues - not things a map library can magically fix on its own.

This matters when you use the app. Treat the results as a planning aid, and double-check important details if they affect your trip. The project describes the underlying JSON files and where they came from, so users and contributors can start by inspecting the data rather than assuming every pin on the map is perfect.

Searching by more than a pandal name

For many visitors, searching by locality or place name is more useful than knowing a pandal's official name. Pujo Atlas accepts latitude/longitude and DIGIPIN codes as well. Place-name suggestions use Photon with OpenStreetMap data, while coordinate and DIGIPIN lookups can be handled locally.

Once you pick a location, you can find pandals within 15 km. That's a discovery radius, not a promise of an easy walking route or a travel-time estimate. In a dense city, distance alone won't tell you about traffic, crowds, road access, or event-day restrictions. The feature helps narrow what you're looking at - but you still need to judge how to move between locations.

Clustering dense map results

If you plot a marker for every pandal, the map can turn into a wall of overlapping points - especially when many locations are close together. Pujo Atlas renders the map with Leaflet and uses Supercluster to group dense marker areas. Clustering keeps the map readable at broader zoom levels, and as you zoom in, the locations become easier to examine in detail.

This is a straightforward interface choice. Showing everything at once may look "complete," but dense clusters overlap and hide both the map structure and the underlying records. Clustering adds a small layer of abstraction, but it keeps the experience usable. It doesn't change what the data says, and it doesn't decide which pandals you should visit first.

Turning discovery into a hopping list

You can save pandals into a separate hopping list. That's the handoff between browsing and planning: instead of trying to remember every promising result, you build a shortlist inside the app and come back to it as your plan evolves. The list is stored in browser storage, so the project can offer basic persistence without requiring a server-side account system.

One boundary is important, though. A saved list isn't the same thing as an automatically optimized itinerary. The project describes a list meant for planning, but it doesn't claim the app calculates the best order, estimates travel times, or provides turn-by-turn directions. Those are separate features with separate data and maintenance needs.

For an early community tool, keeping the scope tight is a sensible decision. Route optimization depends on assumptions about transport mode, road conditions, opening times, and crowd levels. If you add "order the route" without reliable inputs, you risk adding confidence without accuracy. A practical shortlist might be less flashy, but it's also easier to explain - and easier to maintain.

Why a static app fits this project

A static site can be hosted as files and opened in a modern browser. For this project, that keeps the setup relatively simple: there's no backend described as necessary for loading the map, searching local records, or saving a list in the browser. It also makes the source and data formats easier for someone to inspect or adapt.

To run it locally, the instructions are to serve the project folder over HTTP rather than opening index.html directly. For example:

python -m http.server 8000

Then open http://localhost:8000. Serving over HTTP is a small setup step, but it avoids relying on browser behavior when a page tries to fetch local JSON files directly from the filesystem.

Static hosting isn't a magic shortcut, though. Dataset updates still need to be prepared and published. Large files can slow downloads. And browser storage is tied to a device and browser - so a saved list shouldn't be assumed to sync across devices. This approach reduces server complexity, but it doesn't eliminate the need to manage data and user expectations.

A notable data-size constraint

The government directory is loaded on demand and is about 12 MB, according to the project documentation. Deferring that download is a sensible choice: users who don't need that directory don't have to load it immediately. Still, 12 MB is a lot for a browser app on a mobile connection or an older device.

This is the kind of thing that can be fine for a prototype and still need work before broader use. A next step could be measuring real load time and memory usage, then testing options like removing redundant fields, compressing data in transit, or splitting records into smaller geographic chunks. Those are directions worth considering, not features the project says it has already implemented.

The app also omits government-directory records that fall outside its supported West Bengal map bounds. That's a specific implementation limit with a clear purpose: keeping the map focused on the area it supports. It should be read as a boundary of the current view, not as evidence that the source directory contains no records elsewhere.

Data handling and privacy

In the government-directory JSON, president names and contact numbers have been removed, and the app doesn't display or search those details. That's a deliberate boundary around personal information. The available source describes these removals, but it doesn't give enough detail to make broad claims about licensing, verification, or the update process.

That clarification matters. Publicly accessible data still isn't automatically safe or appropriate to republish everywhere. Removing personal contact fields is a concrete step, and anyone adapting the project should inspect the dataset, understand its origin, and check the conditions that apply to how they plan to reuse it.

An honest AI disclosure

This version doesn't use an open-weight model, an open-source AI agent framework, or local inference. Search, location lookup, and map features aren't presented as AI features. The creator mentions using GitHub Copilot during development to help build and refine the app - but that's different from shipping AI functionality to end users.

That distinction matters because "AI" can blur two very different things: using an AI coding assistant while building software versus providing AI-driven capabilities inside the product itself. The project's disclosure is clear that it doesn't yet match the challenge's central technical prompt for open-source AI.

You also don't need to bolt an AI model onto the product just to make the label fit. A real AI feature would need a job to do - like helping someone narrow a long list based on stated preferences. And even then, it would require reliable input data, a transparent way to explain suggestions, and care to avoid presenting generated recommendations as verified event information. The current project doesn't claim any of that.

A grounded way to evaluate future work

Future development should follow the problem, not the trend. Before adding features, it would help to answer some practical operational questions:

• How often do the directories change, and who can verify updates?
• Are users getting stuck - finding places, understanding the map, or organizing their shortlist?
• Does the 12 MB directory download cause a measurable problem on target devices?
• Would users benefit more from route ordering, offline access, improved data quality, or a different enhancement?
• If AI is considered, what decision would it improve, and how would its output be checked?

These questions make a realistic backlog. They also separate actual user needs from features that might look good in a demo. For a free community project with no revenue yet, it's especially important to keep maintenance costs and contributor effort visible. Each new capability creates ongoing work, not just an initial build.

The source code and datasets are available through the Pujo Atlas GitHub repository. The original project submission is also available on DEV Community.