Pujo Atlas : une carte pour préparer Durga Puja
Découvrez Pujo Atlas, une carte web gratuite pour repérer les pandals de Durga Puja et préparer votre parcours. Architecture, données et limites du projet.
Pujo Atlas : organiser son parcours de Durga Puja avec une carte ouverte
À Kolkata, aller voir les pandals de Durga Puja, ce n'est pas juste « trouver un point sur une carte ». Il faut choisir les lieux, tenir compte des distances, comparer plusieurs listes, puis bricoler un parcours qui tient dans le temps qu'on a. Jusqu'ici, ces infos étaient un peu partout : annuaires, recherches carto, et listes faites à la main.
Pujo Atlas réunit tout ça dans une application web accessible depuis un navigateur. Le projet compile des données issues d'un guide de Kolkata et d'un répertoire gouvernemental du Bengale-Occidental. On peut y rechercher des pandals, afficher les résultats sur une carte, et garder une liste des lieux à visiter.
Et au-delà de l'aspect « culture », il y a un point plus intéressant : Pujo Atlas montre qu'on peut faire quelque chose de concret avec une carte statique, des jeux de données ouverts et des bibliothèques cartographiques, sans obliger tout le monde à passer par une plateforme propriétaire. Il montre aussi ce que ce choix implique : qualité des données, taille des fichiers, dépendance à des services tiers, et pas d'optimisation automatique des itinéraires.
Le problème auquel répond Pujo Atlas
Durga Puja est une grande fête au Bengale, et les pandals, ces structures temporaires, attirent énormément de visiteurs. Le vrai problème n'est pas seulement de savoir qu'ils existent. Il faut aussi pouvoir les repérer, les comparer, et décider lesquels visiter quand on a un temps limité.
Un annuaire répond plutôt à : « Quels lieux existent ? ». Une carte : « Où sont-ils ? ». Une liste personnelle : « Qu'est-ce que j'avais prévu ? ». Le hic, c'est de jongler entre tout ça : on finit par refaire soi-même la coordination entre les informations. C'est exactement le petit travail que Pujo Atlas veut réduire.
Une vue combinée plutôt que des sources dispersées
L'application combine deux ensembles de données : des enregistrements issus d'un guide de pujas de Kolkata, et un répertoire gouvernemental couvrant le Bengale-Occidental. L'utilisateur peut explorer ces résultats dans une vue commune, puis rechercher un pandal, une localité ou un nom de lieu.
La recherche accepte aussi des coordonnées géographiques et des codes DIGIPIN. On peut utiliser une localisation comme point de référence pour afficher les pandals situés dans un rayon de 15 km. Ce rayon est pratique pour réduire la liste, mais ce n'est pas un itinéraire : deux lieux « proches » à vol d'oiseau peuvent être pénibles à relier à cause du réseau routier, des temps de déplacement ou de la foule.
Quand la carte montre une zone très dense, les marqueurs sont regroupés. Sans regroupement, les points se superposeraient et la lecture deviendrait vite impossible. Avec des clusters, on voit d'abord les concentrations, puis on zoome pour distinguer les lieux un par un.
Une liste de visite, pas un calculateur de trajet
On peut ajouter des pandals à une liste distincte à partir des résultats. Cette liste sert de plan de visite simple : elle évite de tout mémoriser ou de refaire les mêmes recherches à chaque étape.
À ce stade, il faut être clair sur le rôle de l'outil : d'après ce qui est disponible, Pujo Atlas aide à sélectionner et organiser des étapes, mais ne calcule pas un parcours optimisé selon le trafic, les horaires, les transports ou les temps d'attente. C'est cohérent pour une première version : une liste fiable et facile à modifier rend souvent plus service qu'un algorithme de tournée dépendant de données de circulation et d'hypothèses difficiles à maintenir.
Le projet est gratuit et communautaire : il n'y a pas d'utilisateurs payants ni de revenus. Ça rend l'approche plus légère, mais ça veut aussi dire qu'il faut surveiller les coûts et la charge si l'usage augmente.
Comment l'application est construite
Pujo Atlas est une application web statique en HTML, CSS et JavaScript, sans framework d'interface. La carte est affichée avec Leaflet, et les fonds utilisent par défaut OpenStreetMap. Le regroupement des marqueurs repose sur Supercluster.
L'intérêt, c'est de garder le nombre de composants à déployer assez bas. Pour une application qui sert surtout à lire des données, filtrer des lieux et afficher une carte, un serveur applicatif complet n'est pas forcément nécessaire. Par contre, « statique » ne veut pas dire « sans contraintes » : les données, les services cartographiques et le stockage côté navigateur doivent être compris et testés.
Des fichiers JSON chargés par le navigateur
Les données sont stockées dans des fichiers JSON, dans le répertoire data/. Le navigateur les récupère, puis l'application filtre et trie les enregistrements localement. Pas besoin de construire une API ni une base de données serveur pour chaque recherche.
Le compromis est assez direct : la logique est simple, et le projet peut être hébergé comme un site statique. En contrepartie, le premier téléchargement peut être lourd. Le répertoire gouvernemental fait environ 12 Mo et n'est chargé qu'à la demande. Résultat : on n'oblige pas tout le monde à télécharger ce volume dès la première visite, mais on ralentit la première consultation de ce jeu de données.
Autre règle : l'application n'affiche pas les enregistrements en dehors des limites prévues pour le Bengale-Occidental. C'est important, parce que des points aberrants ou des coordonnées invalides peuvent vite casser l'affichage ou faire partir la carte hors de la zone utile.
Pour lancer le projet localement, il faut le servir en HTTP plutôt que d'ouvrir directement index.html. Depuis le dossier du projet, la commande suivante démarre un serveur local :
python -m http.server 8000Ensuite, ouvrez http://localhost:8000. Un serveur local est nécessaire parce que le navigateur applique des règles de sécurité aux fichiers et aux requêtes de données. Ce n'est pas une exigence particulière à Pujo Atlas, mais une précaution normale quand on développe une application qui charge des ressources locales.
Carte, recherche et stockage local
OpenStreetMap sert de fournisseur de carte par défaut et, dans la configuration décrite, ne demande pas de clé API. Leaflet gère l'affichage, et Supercluster réduit la surcharge visuelle quand il y a beaucoup de pandals.
Pour les suggestions de lieux, Pujo Atlas utilise Photon avec des données OpenStreetMap. Les coordonnées et les codes DIGIPIN sont résolus localement. Le projet propose aussi un fournisseur Google Maps optionnel, à condition de configurer une clé API restreinte au navigateur.
Ce mix évite de dépendre d'un seul fournisseur pour toute l'application. Mais il faut quand même tester plusieurs chemins : la recherche de noms passe par un service externe, alors que les coordonnées et DIGIPIN suivent un autre mécanisme. Il vaut donc mieux vérifier les erreurs réseau, les réponses sans résultat et les formats de saisie inattendus, pas seulement le scénario parfait.
Les listes de visite sont enregistrées dans le stockage du navigateur. C'est pratique : pas de compte utilisateur, pas de serveur de profils. L'inconvénient, c'est que la liste reste liée au navigateur et à l'appareil : elle ne se synchronise pas entre un téléphone et un ordinateur. Pour une planification personnelle, ça peut aller. Pour une utilisation multi-appareils ou collaborative, ça devient vite frustrant.
Des données publiques, avec un traitement de confidentialité
Les fichiers regroupent des données du guide de Kolkata et du répertoire gouvernemental. Les noms de présidents et les numéros de contact ont été retirés des enregistrements utilisés par l'application. Autrement dit, ces informations ne sont pas proposées comme données consultables.
Ce n'est pas juste une question de présentation. Quand un projet republie des jeux de données, il doit décider ce qui sert au besoin réel du produit et ce qui n'a pas de raison d'être diffusé. La minimisation réduit l'exposition d'informations personnelles, mais ne remplace pas une vérification des droits de réutilisation, de la provenance et des conditions attachées à chaque source.
Ce que l'approche ouverte apporte - et ce qu'elle ne résout pas
Le principal apport de Pujo Atlas est simple : combiner des données géographiques et des outils ouverts pour rendre une planification plus lisible. Pas besoin de plateforme propriétaire pour avoir une carte consultable, une recherche côté client et une liste de lieux enregistrée dans le navigateur.
Mais les dépendances ne disparaissent pas. Les cartes, les suggestions de recherche et les données viennent de sources différentes. Chaque fournisseur a ses limites : disponibilité, débit, couverture, conditions d'utilisation. On peut avoir une application « ouverte » dans son code tout en dépendant de services externes pour une partie de l'expérience.
Ouvert ne veut pas dire automatiquement fiable
Une carte peut avoir un rendu propre tout en affichant des coordonnées fausses ou des infos déjà dépassées. La qualité dépend d'abord de la qualité des sources et de leur mise à jour. Avant de planifier une visite, l'utilisateur doit pouvoir comprendre d'où viennent les données, quand elles ont été mises à jour, et comment signaler une erreur.
En version production, les contrôles utiles comprendraient notamment :
- la validation des coordonnées et des champs obligatoires lors de la préparation des fichiers ;
- le nombre d'enregistrements rejetés et la raison de leur exclusion ;
- une date de mise à jour visible pour chaque jeu de données ;
- un mécanisme de signalement simple pour une fiche erronée ;
- des tests de taille de fichiers et de temps de chargement sur mobile.
Ces points comptent plus, au final, que l'ajout d'une bibliothèque « nouvelle ». Une carte techniquement bien faite n'aide pas si les points sont vieux ou si le chargement est trop long sur une connexion mobile.
Un projet utilisant l'IA ne veut pas dire une application « fondée sur l'IA »
La nuance est importante dans le contexte du défi Hacktoberfest Open-Source AI. Le projet indique que GitHub Copilot a été utilisé pendant le développement pour aider à écrire et améliorer Pujo Atlas. Mais cette version n'intègre pas de modèle à poids ouverts, pas d'agent d'IA open source, et pas d'inférence locale.
Donc les fonctions de recherche, de regroupement et d'affichage cartographique ne sont pas présentées comme de l'IA. Le projet dit clairement qu'il ne répond pas encore au cœur de la demande du défi sur l'IA open source. Cette transparence évite une confusion fréquente : utiliser un assistant de programmation ≠ intégrer une IA dans le produit.
C'est valable pour beaucoup d'outils : l'assistant qu'utilise l'équipe au quotidien ne fait pas forcément partie des fonctionnalités de l'application. Si l'objectif était d'ajouter une vraie fonction d'IA, il faudrait partir d'un besoin utilisateur mesurable (par exemple aider à composer un parcours avec des contraintes explicites), puis vérifier la qualité des réponses, la fiabilité des données et le coût de maintenance. Ajouter un modèle « par principe » pour suivre une tendance ne rend pas le produit plus utile.
Comment reprendre cette architecture pour un autre projet
Le principe de Pujo Atlas peut fonctionner aussi pour d'autres répertoires géographiques : événements, lieux culturels, marchés, points de collecte ou activités temporaires. Le bon cas d'usage a souvent trois caractéristiques : des données structurées, des lieux au centre de la décision, et la nécessité de comparer plusieurs points avant de se déplacer.
En France, on pourrait imaginer une carte pour explorer des rendez-vous locaux. Mais il faut alors vérifier les licences des données, les règles de réutilisation, et ce qu'on peut faire avec des informations personnelles. Le RGPD ne se limite pas à retirer quelques champs : il faut comprendre quelles données sont traitées, pourquoi, combien de temps, et quels services tiers y accèdent.
Une méthode de conception en cinq décisions
Avant de choisir les bibliothèques, posez d'abord le périmètre :
- Définir la décision à faciliter. L'application aide-t-elle à trouver un lieu, comparer des options, ou planifier une visite ? Plusieurs objectifs peuvent coexister, mais il faut choisir un premier parcours prioritaire.
- Évaluer les données avant l'interface. Format, volume, couverture, fraîcheur et conditions de réutilisation. Un fichier de 12 Mo n'a pas le même impact sur un téléphone qu'un jeu léger.
- Choisir où s'effectue le traitement. Filtrer dans le navigateur réduit l'infrastructure, mais transfère le coût de calcul et le téléchargement à l'utilisateur. Une API peut mieux gérer de gros volumes, mais implique un service à héberger et à surveiller.
- Séparer recherche, carte et planification. Ce sont trois responsabilités distinctes. Les séparer facilite les tests et permet de changer un fournisseur sans tout réécrire.
- Prévoir les cas dégradés. Que se passe-t-il si la carte ne charge pas, si Photon ne répond pas, ou si le navigateur efface le stockage local ? Un outil utile doit rester compréhensible même quand ses dépendances ne le sont pas.
Cette approche limite le risque de construire une interface « jolie » autour d'un jeu de données mal maîtrisé. Elle aide aussi à doser la complexité : pour un projet communautaire à faible trafic, une application statique peut suffire. Si les données sont volumineuses, mises à jour très souvent, ou partagées entre utilisateurs, une API et une base de données deviennent plus pertinentes.
Ce qu'il faut mesurer après la mise en ligne
Le succès ne se résume pas au nombre de marqueurs affichés. Pour savoir si l'application résout le problème, il faut regarder des indicateurs liés aux tâches réelles : temps pour trouver un lieu, part des recherches sans résultat, proportion des visiteurs qui créent une liste, temps de chargement des données et erreurs sur mobile.
Il faut aussi recueillir des retours sur la qualité des données. Un formulaire de signalement simple peut révéler des problèmes plus vite qu'un tableau de bord compliqué. Pour un projet sans revenus, l'idée est de savoir si l'outil est utile et maintenable avant d'ajouter des fonctions avancées.
Le code source et les fichiers de données permettent à d'autres personnes d'inspecter le fonctionnement et de proposer des améliorations. Le dépôt est disponible sur GitHub. Publier un projet ouvert ne garantit pas, à lui seul, une communauté active : il faut documenter le format des données, expliquer comment contribuer, et indiquer clairement les limites connues.
Conclusion
Pujo Atlas défend une approche volontairement simple : réunir plusieurs répertoires de pandals, les rendre explorables sur une carte, et permettre à chacun de préparer une liste de visite. HTML, CSS, JavaScript, Leaflet, Supercluster et des fichiers JSON suffisent pour faire un outil concret, sans lancer immédiatement une infrastructure serveur.
Le compromis, lui, est clair. Une application statique réduit la complexité opérationnelle, mais la taille des fichiers, la dépendance aux services de recherche, la qualité des données et l'absence de synchronisation restent des sujets à traiter. Le projet a aussi le mérite de distinguer clairement l'assistance de Copilot pendant le développement et une vraie fonctionnalité d'IA intégrée.
Si vous voulez reprendre cette idée, commencez par vérifier les données et la tâche utilisateur, puis choisissez la carte et l'architecture. Testez le rendu sur mobile, mesurez les temps de chargement, documentez les limites avant d'ajouter des fonctions plus « ambitieuses ». Vous pouvez consulter le code de Pujo Atlas sur GitHub et voir comment cette approche pourrait s'adapter à vos propres données géographiques.