Vue d'ensemble

Chaque étape reçoit une structure bien typée et produit la suivante. Aucune étape ne peut être sautée — le pipeline est strictement séquentiel.

Étape 1 — JSON → Room

io/rooms.py · Chargement du fichier JSON exporté depuis Revit. Conversion des coordonnées pieds → mètres. Extraction du contour, des portes, des poteaux et des métadonnées de la pièce.

Chargement

Étape 2 — Room → AnalysePiece

core/analysis.py · Calcul de l'angle principal (inertie), AABB en repère local, détection des murs porteurs et segmentation des portes. Prépare l'ossature géométrique.

Analyse

Étape 3 — AnalysePiece → ConfigImplantation

Choix des systèmes de stationnement, activation du mix, mode exact ou glouton, contrainte d'accessibilité. C'est la « décision » de l'utilisateur ou du génome NSGA-II.

Config

Étape 4 — Config → Constructeur

solve/ · Pavage par bandes, glissement leftmost-fit, zone exacte (DP / CP-SAT). Produit un plan d'implantation valide par construction — zéro chevauchement garanti.

Pavage

Étape 5 — Constructeur → Circulation

circulation/ · Dijkstra à coût d'occupation sur grille fine (0,15 m). Couloir de 1,20 m minimum. Accessibilité BFS depuis chaque porte vers chaque rack.

Accès

Étape 6 — Circulation → NSGA-II

optimize/ · Génome structurel encodant orientation, systèmes, mix. Évaluation = constructeur + circulation. Sélection tournoi binaire, croisement SBX, mutation PM. Front de Pareto (−capacité_accessible, coût_circulation).

Évolution

Étape 7 — NSGA-II → Rendus PNG

viz/render.py · Front de Pareto visualisé, top-N variantes rendues en haute résolution. Chaque rendu montre la pièce, les emprises, le couloir de circulation et les métriques.

Rendu
🔗
Flux linéaire — Chaque étape est une fonction pure qui transforme une structure typée en une autre. Le pipeline est entièrement déterministe à graine fixée. Deux exécutions identiques produisent le même résultat, bit pour bit.

Flux de données

Vue condensée des transformations avec les types d'entrée et de sortie de chaque module.

JSONload_room()Room

Roomanalyser()AnalysePiece

AnalysePiece + ConfigImplantation

├── implanter_piece()Implantation
├── connecter()Réseau
└── optimiser()ParetoFront

ParetoFrontrendre()PNG
💡
Constructeur = boîte noire du NSGA-II — L'optimiseur ne manipule jamais directement les positions de vélos. Il encode une structure (orientation, systèmes, mix) et la fait évaluer par le constructeur. C'est le principe de séparation « structure vs placement ».

Modules impliqués

Chaque module a une responsabilité unique et des frontières bien définies.

ModuleFichiersRôle
io rooms.py, revit_dump.py Chargement des fichiers JSON, conversion pieds → mètres, extraction des contours
core room_model.py, geometry.py, analysis.py Modèle géométrique, calculs d'angle principal, AABB, lacet, ray-casting
catalog systems.py Catalogue des systèmes de stationnement, cotes réglementaires
solve constructor.py, packing.py, rows.py, zone.py Constructeur glouton + packing exact, pavage par bandes, glissement
circulation access.py, connect.py Dijkstra à coût d'occupation, BFS d'accessibilité, couloir 1,20 m
optimize genome.py, phenotype.py, nsga2.py, diversity.py NSGA-II multi-objectif, génome structurel, front de Pareto, diversité top-N
viz render.py Visualisation matplotlib des pièces, implantations et fronts de Pareto
📦
Dépendances minimales — Les modules io et core.geometry sont écrits en stdlib pur (aucune dépendance externe). Shapely, numpy et OR-Tools ne sont utilisés que dans solve et optimize.

Détail de chaque étape

Cliquez sur une étape pour voir les détails techniques — entrées, sorties, invariants.

📂 Étape 1 — Chargement JSON +

Entrée : Fichier .json exporté depuis Revit (coordonnées en pieds impériaux)

Sortie : Objet Room — polygone de contour (mètres), liste de portes, liste de poteaux

Invariant : Le polygone est toujours orienté en sens anti-horaire (lacet positif). Les coordonnées sont toujours en mètres SI.

from bikeoptim.io.rooms import load_room room = load_room('data/rooms/piece_46.json') # room.boundary : List[Tuple[float, float]] # room.doors : List[Door] # room.columns : List[Column]
📐 Étape 2 — Analyse géométrique +

Entrée : Room

Sortie : AnalysePiece — angle principal θ, AABB en repère local, segments de murs, portes projetées

Méthode : Analyse en composantes principales (PCA) sur les sommets du polygone pour trouver l'orientation dominante. Rotation → AABB minimale.

θ = atan2(λ₂, λ₁) — angle principal par inertie du polygone
⚙️ Étape 3 — Configuration +

Entrée : Choix utilisateur ou génome NSGA-II

Sortie : ConfigImplantation

Paramètres :

  • systems — liste des systèmes à utiliser
  • mix_enabled — autoriser le mélange de systèmes par bande
  • exact_zone — packing exact (M3) vs glouton
  • enforce_access — garantir l'accessibilité (M4)
  • reserve_cargo — réserver un emplacement cargo
🔧 Étape 4 — Constructeur +

Entrée : AnalysePiece + ConfigImplantation

Sortie : Implantation — liste d'emprises positionnées, capacité totale

Algorithme : Pavage par bandes parallèles à l'angle principal. Chaque bande est remplie par glissement leftmost-fit. En mode exact, DP/CP-SAT sélectionne la combinaison optimale de bandes.

Invariant : Zéro chevauchement — garanti par construction, vérifié par test AABB.

🔗 Étape 5 — Circulation +

Entrée : Implantation + portes de la pièce

Sortie : Réseau de circulation, coût total, capacité accessible

Algorithme : Grille fine (0,15 m). Dijkstra depuis chaque porte avec coût = occupation de la cellule. BFS pour tester l'accessibilité de chaque emprise via un couloir de 1,20 m minimum.

🧬 Étape 6 — NSGA-II +

Entrée : Room + espace de configurations

Sortie : Front de Pareto + top-N variantes

Objectifs :

minimiser (−capacité_accessible, coût_circulation)

Opérateurs : SBX (croisement), PM (mutation polynomiale), tournoi binaire, crowding distance pour la diversité.

🖼️ Étape 7 — Rendus +

Entrée : ParetoFront + top-N solutions

Sortie : Fichiers PNG haute résolution

Contenu : Polygone de la pièce, emprises colorées par système, couloir de circulation, métriques de capacité et d'accessibilité, front de Pareto avec les solutions dominées et non dominées.

Temps d'exécution

Le pipeline doit rester compatible avec l'évaluation intensive de NSGA-II : des centaines d'appels en quelques secondes.

⏱️ Objectif par évaluation

<50 ms / éval

Constructeur + Circulation doivent s'exécuter en moins de 50 ms pour une pièce standard.

🧬 Budget NSGA-II

200 évaluations

200 évaluations × 30 s max de budget total. Le front de Pareto converge typiquement en ~120 évaluations.

ÉtapeTemps typiqueGoulot ?Notes
Chargement JSON<1 msNonParsing + conversion pieds → mètres
Analyse<1 msNonPCA + AABB, opérations vectorielles
Constructeur (glouton)~5 msNon8 combinaisons × pavage + glissement
Constructeur (exact)~15 msPossibleDP linéaire, CP-SAT si nécessaire
Circulation~20 msOuiDijkstra sur grille fine + BFS
Rendu PNG~200 msHors bouclematplotlib — appelé uniquement sur top-N
Circulation = goulot d'étranglement — Le Dijkstra sur grille fine représente ~40% du temps d'évaluation. L'utilisation d'une résolution adaptative (grossière en zones libres, fine près des racks) est envisagée pour M6.
Rendus hors boucle — Les rendus PNG ne sont jamais appelés dans la boucle NSGA-II. Ils sont générés uniquement sur le front de Pareto final et les top-N variantes sélectionnées.