SMP Maps : SIG Web interactif sur Minecraft

Introduction et objectifs

Entre 2020 et 2021, j'avais réalisé un réseau de métro complet sur un serveur multijoueur Minecraft. Cependant, j'étais le seul à vraiment savoir l'utiliser...

Ce projet est donc né en réponse à la problématique d'alors : comment rendre lisible, navigable et accessible un réseau de transport dense et complexe ?

J'avais en effet réalisé un plan schématique du réseau / carte topologique ainsi que des schémas de lignes, mais celle-ci restait plutôt floue pour de nombreux joueurs.

Dans une démarche d'urbanisme virtuel et expérimental, j'ai conçu un outil de navigation temps réel comparable à "Google Maps" permettant aux joueurs de calculer l'itinéraire le plus rapide en prenant en compte la physique spécifique du jeu.

• Problématique : Comment transformer un réseau de transport virtuel difficilement lisible en une carte de transport claire, multimodale et fonctionnelle ?
• Objectif : Développer une application web complète, de la collecte de données brutes à l'interface utilisateur.

Les noms des stations présentés dans ce portfolio ont été anonymisés ou modifiés afin de respecter la vie privée du serveur et de ses utilisateurs.

Création des Données et SIG pur avec QGIS

Cette phase cruciale a permis de transformer le monde du jeu en données exploitables. Elle démontre une rigueur mathématique et mon apprentissage des outils SIG.

Exportation de la carte

J'ai tout d'abord utilisé l'outil uNmINeD pour exporter une carte depuis une sauvegarde de ce serveur. Afin d'avoir une image plus nette sur le site web, j'ai exporté l'image en 4x (où 4 pixels = 1 bloc dans le jeu). La carte exportée est un carré de 2048 mètres de côté.

Création du projet QGIS

J'ai ensuite créé un projet QGIS cartésien (coordonnées simples en 2D) en EPSG:3857 qui est le système de coordonnées utilisé par Google Maps et OpenStreetMap (et donc Leaflet, que j'utilise dans ce projet). Ce type de carte permet d'utiliser facilement les mètres comme unité, ce qui est parfaitement ce dont on a besoin pour Minecraft où chaque bloc correspond à un mètre.

Géoréférencement et précision

J'ai utilisé le géoréférenceur de QGIS pour aligner ma cartes raster brute en 4x sur le système de coordonnées projeté . L'utilisation de points de contrôle (GCP) a permis d'assurer une précision au bloc près, indispensable pour la navigation in-game.

J'ai ensuite transformé la carte de manière linéaire.

Création des couches

J'ai ensuite créé les couches stations et lignes via les outils fournis par QGIS pour pouvoir placer les stations et lignes. J'avais tout d'abord aligné les stations sur la carte manuellement, en cliquant dessus, mais cette manière s'avère peu précise et inadaptée pour Minecraft, où les coordonnées se doivent d'être précises au mètre près pour avoir des temps de trajet réalistes. Les coordonnées ont été relevées directement depuis le jeu.

L'attribut type correspond au type de ligne (métro, TGV, etc.). Ici, seul le métro de bateau sur glace a été implémenté. Les lignes de métro dans ce réseau sont des lignes de glace que les joueurs traversent avec un petit bateau. Selon le type de glace utilisée, la vitesse maximale atteinte est plus ou moins rapide.

Pour une première version, j'avais donc rempli les lignes manuellement en utilisant le mode édition et en faisant des polylignes en cliquant sur chaque station de chaque ligne à la suite.

On remarque de nombreux problèmes : non seulement des stations géographiquement alignées ne le sont pas parfaitement, mais certaines stations font des diagonales, alors que tous les angles sont droits dans le vrai réseau de métro sur le jeu ! Egalement, Minecraft a un système de coordonnées non standard où les coordonnées de la carte ne sont pas vraiment en (x ; y) mais plutôt en (x ; z). Pour les convertir en un format que QGIS comprend, il faut remplacer y par -z.

Il me fallait donc réfléchir à des changements majeurs pour améliorer la situation.

Changements sur les couches

J'ai donc décidé de faire les choix suivants :

Pour les stations

• Faire une station par quai pour les stations qui en disposent de plusieurs (généralement une par ligne)
• Ajouter un paramètre "hub_id" (identifiant de hub) qui permettent de regrouper les différents quais d'une seule station

Pour les lignes

• Ajouter une ligne spéciale "Ascenseur Paradis". En effet, entre les stations Paradis et Paradis - Île, il y a un ascenseur vertigineux qui a une durée assez longue et qui ne correspond pas du tout au reste de la ligne 5.
• Ajouter un paramètre "materiau" car une ligne (la ligne 1) a un matériau différent des autres permettant d'accélerer les déplacements.
• Cette ligne a un autre nouveau paramètre, la "duration" (durée) qui permet de définir la durée d'ascension (qui a été mesurée par mes soins).

Par ailleurs, celle-ci a ensuite été modifiée dans l'application pour prendre en compte le fait que la descente (6 secondes) est bien plus courte que la montée.

Modélisation mathématique (Excel vers QGIS)

Avant l'importation, un travail de normalisation a été effectué via Excel pour garantir l'intégrité des relevés topographiques.

• Conversion des coordonnées Minecraft (x, z) vers le standard cartographique (x, y).
• Application de la logique de transformation y = -z pour respecter l'orientation géographique.

Je suis passé par le format CSV pour passer de Excel brut à QGIS. C'est essentiellement un fichier Excel simplifié.

J'ai ajouté une couche de texte délimitée sur QGIS pour importer le fichier CSV nettoyé.

Enfin, j'ai utilisé Points to Path pour relier les stations dans des lignes.

Avec la gestion des hubs grâce au hub_id, j'ai enfin eu un résultat parfaitement importable pour la deuxième phase du projet : l'application web.

J'ai ensuite exporté les fichiers des stations et des lignes au format GeoJSON, standard de l'industrie, pour avoir un fichier plus facilement utilisable dans mon application.

Création et mise en place de l'application web

Le cœur du projet repose sur un moteur de calcul d'itinéraire intelligent, exporté depuis QGIS vers un format web léger.

• Architecture locale : tous les calculs d'itinéraire se déroulent dans le navigateur, ce qui réduit les appels au serveur
  • L'image de fond est stockée dans un format efficace et léger (.AVIF) ce qui améliore la rapidité et réduit l'empreinte carbone du site
  • Le site web, tout comme mon portfolio, sont hébergés chez Infomaniak, un hébergeur suisse qui compense doublement ses émissions de carbone
  • Le numérique est une industrie de plus en plus polluante et l'éco-conception devient un sujet majeur dans l'informatique contemporaine
• Techstack simple :
  • React (JS, ensemble d'outils permettant de faciliter le développement d'applications web contemporaines)
  • Leaflet (JS, affichage des cartes)
  • Tailwind (CSS, amélioration de l'affichage).
• Import GeoJSON : Utilisation d'un fichier lisible nativement par Leaflet
• Moteur A* : Implémentation d'un algorithme de parcours de graphe adapté aux contraintes physiques :
  • Vitesse variable selon le matériau (blue ice vs packed ice)
  • Adaptation des vitesses selon celles remarquées dans le jeu (inférieures à celles théoriques)
  • Pénalités temporelles pour les correspondances à pied. Celles-ci ne sont intégrées qu'à l'intérieur des stations
  • Intégration des ascenseurs avec coûts fixes
• Tutoriel : Mise en place d'un tutoriel pour accompagner l'utilisateur dans l'usage de l'application
• Affichage amélioré : De nombreuses améliorations ont été faites pour rendre l'affichage plus clair et moins confus.

Le résultat est une application complète, avec des temps très réalistes comparé au jeu (voire identiques. La marge d'erreur est faible.

Visualisation et UX :

La finalité du projet est d'offrir une interface lisible, inspirée des standards de l'industrie, principalement Google Maps.

Hiérarchie visuelle et "Casing"

Pour résoudre le problème de lisibilité sur fond complexe, j'ai utilisé la technique du "casing" : un double tracé des lignes (contour blanc épais + couleur de la ligne) permettant de détacher visuellement le réseau du fond de carte raster.

Expérience utilisateur (UX)

L'interface propose une visualisation dynamique : le fond de carte est grisé, les stations traversées dans un itinéraire sont entourées, les stations de départ et d'arrivée sont clairement marquées et les stations de transfert sont bien définies.

Les hubs sont également regroupés visuellement, avec un affichage spécifique en pointillés gris pour les correspondances entre quais.

Dans le panneau de gauche, les stations parcourues sont affichées, ainsi que la direction et la station à laquelle descendre. En effet, dans le jeu, les stations sont faites telles que seule la prochaine station est affichée. Avoir la direction est ainsi crucial.

Si on déplace son curseur sur une ligne, celle-ci est mise en avant visuellement, avec une opacité accrue et le reste de la carte est grisé davantage. L'itinéraire en cours dispose également d'un effet similaire.

En cliquant sur une ligne ou une station, on dispose de ses informations détaillées.

Améliorations à venir

Des correctifs de bogues ainsi que des améliorations visuelles sont à venir afin d'améliorer l'ergonomie du site et son aspect visuel.

Il est aussi potentiellement prévu d'ajouter un système plus complet de calcul d'itinéraires, avec notamment la prise en charge des chemins, du "hors-piste", des chariots (minecarts) et plus encore.

Bilan et compétences clés

Ce projet transversal m'a permis de consolider des compétences techniques variées :

• SIG (QGIS) : Géoréférencement, systèmes de coordonnées, manipulation raster/vecteur
• Data Management : Nettoyage, transformation et structuration de données spatiales
• Développement : Logique algorithmique appliquée aux transports
• Vision urbanistique : Capacité à modéliser des flux de transport multimodaux complexes