Présentation du projet

Cartopolis est une réplique marchable du monde réel, générée à partir de données publiques ouvertes (BAG, 3DBAG, AHN, PDOK, registres de transport). Chaque bâtiment possède une fiche détaillée : année de construction, usage, surface, statut, voire son numéro de monument. Le rendu s’appuie sur le moteur Bevy, écrit en Rust, qui représente 93,5 % du code du dépôt, le reste étant du TypeScript, WGSL et quelques scripts Shell.

Architecture technique

Le client s’exécute sur trois cibles : navigateur (via WebGPU), poste de travail (Linux/Windows, support AVX2 + FMA depuis 2013) et Android (APK arm64, Android 9+). La compilation WebGPU impose un GPU compatible, sinon le chargement échoue. Le serveur gère la synchronisation d’état via TLS et expose une API HTTP pour l’import/export d’objets 3D ou d’IFC. Les pipelines de données sont organisés en crates sous crates/atlas, chaque registre (bâtiments, relief, objets de voirie) étant traité séparément avant d’être agrégé dans le monde partagé.

Fonctionnalités réseau et sécurité

Cartopolis propose plusieurs canaux de communication : chat local basé sur la distance, voix de proximité, chat global et chats privés chiffrés de bout en bout grâce à la crate bevy-free ajoutée en septembre 2026. Le système d’authentification repose sur des sessions sign‑in/sign‑out qui peuvent être interrompues sans perdre la connexion client, comme le montre le commit « fix what the first two bot sessions ran into ». Les appels de type walk_to acceptent un paramètre wait_s et renvoient un accusé de réception à la fin du déplacement, évitant les boucles de polling inutiles.

cargo run -p cartopolis               # démarre en mode hors‑ligne
cargo run -p cartopolis -- --connect <host>   # se connecte à un serveur live (TLS)

Limites et perspectives

Le rendu dépend fortement de la disponibilité de données de haute résolution : aux Pays‑Bas, le sol et les bâtiments proviennent de sources officielles, tandis que le reste du globe se limite à OpenStreetMap et à un relief plat. Cette disparité entraîne des variations de densité de géométrie et de texture. De plus, la version binaire requiert le support AVX2/FMA, excluant les machines plus anciennes. Le client WebGPU, bien que performant, reste sensible aux pilotes graphiques ; aucune solution de repli n’est fournie pour les GPU sans WebGPU. Enfin, le modèle de modération (blocage, signalement, suppression de compte) est implémenté côté serveur, mais le code ne détaille pas les mécanismes de persistance ni les garanties de conformité GDPR, ce qui peut freiner l’adoption par les municipalités soucieuses de la protection des données.