Comparaison mkgmap / imgforge — taille IMG et lissage géométrique¶

Cette page analyse pourquoi mkgmap r4924 et imgforge produisent des IMG de tailles différentes et des géométries visuellement distinctes, à partir de la même tuile .mp. Elle s'appuie sur les mesures directes de la tuile BDTOPO-001-004 (Vienne, D038) et sur le code source Java de mkgmap r4924 (build/MapBuilder.java L929-1354).

Introduction — la question posée¶

Pour la même tuile MP (BDTOPO-001-004.mp, 43 MB), mkgmap r4924 et imgforge produisent des IMG de tailles différentes. Le ratio de taille évoqué en amont ("6×") résultait d'une comparaison non rigoureuse (périmètres différents : nombre de tuiles, sections incluses). La mesure instrumentée sur la même tuile BDTOPO-001-004 donne un résultat très différent, détaillé ci-dessous.

§1 — Mesures de référence (état actuel)¶

Conditions de mesure¶

Méthode¶

Pour chaque IMG, le script extrait le TRE de la sous-map principale, lit la section map levels et la section subdivisions, puis agrège les deltas rgn_offset(i+1) − rgn_offset(i) par niveau. C'est la mesure utilisée par le firmware Garmin pour sélectionner les données à rendre. Elle exclut les sections étendues (types étendus, NET, NOD, RGN2-RGN5).

Commandes de reproduction¶

# Mesure mkgmap (IMG déjà disponible)
python3 scripts/debug/bytes-per-level.py tmp/mkgmap-vienne-build.img

# Build imgforge mono-tuile (sous-map 00380042)
mkdir -p /tmp/vienne-mp
cp pipeline/output/2026/v2026.03/D038/mp/BDTOPO-001-004.mp /tmp/vienne-mp/
imgforge build /tmp/vienne-mp --output /tmp/vienne-local.img

# Mesure imgforge (analyser le sous-map 00380042, pas 00011855 qui est le conteneur GMP)
python3 scripts/debug/bytes-per-level.py /tmp/vienne-local.img  # lit le premier sous-map
# Note : bytes-per-level.py lit le premier sous-map alphabétique ; pour imgforge GMP,
# le sous-map tuile (00380042) vient après le conteneur (00011855). Voir §A.

Tableau de comparaison¶

Convention — colonne mk÷if : valeur > 1 signifie que mkgmap a plus de bytes que imgforge à ce niveau.

(1) "inh." pour inherited : le niveau 6 hérite sa subdivision du niveau 5 ; aucune feature n'y est émise directement.

Observations clé¶

1. imgforge est désormais 1,73× plus compact que mkgmap en données géométriques RGN : 1 053 284 bytes vs 1 817 996 bytes. Le fix EndLevel filtering (commit 6478c47) a éliminé l'émission erronée aux niveaux larges.

2. L'écart est maximal aux niveaux larges : à n=5, mkgmap stocke 15,8× plus de données. Mais à n=0 la tendance s'inverse : imgforge a 30 % de données supplémentaires au niveau de détail maximal.

3. mkgmap inclut plus de features aux niveaux larges : 95 subdivisions à n=5 vs 4 pour imgforge. Ce n'est pas de la mauvaise qualité — c'est un choix de conception : mkgmap garde plus de features visibles en dézoom mais les simplifie agressivement via sa chaîne de filtres. imgforge applique le EndLevel filtering (features absentes des niveaux au-dessus de leur EndLevel) mais ne simplifie pas la géométrie des features présentes.

4. Le total IMG mono-tuile reste plus grand pour imgforge (4,9 MB vs 3,8 MB pour mkgmap), malgré une géométrie ordinale plus petite. La différence vient de l'overhead du conteneur GMP et des sections étendues : la RGN déclarée imgforge est 3,37 MB dont 2,32 MB d'extended types/NET/NOD, contre 3,79 MB déclarée mkgmap dont 1,97 MB d'extended. Ce n'est pas la section géométrique qui explique la différence de taille de l'IMG total — c'est l'overhead de format.

Baseline historique (avant fix EndLevel)¶

Le niveau 0 est quasi-identique avant et après le fix : les features à EndLevel=0 n'étaient pas affectées par le bug. L'amélioration se concentre entièrement sur les niveaux n=1..5.

§2 — La chaîne de filtres mkgmap¶

Vue d'ensemble¶

mkgmap applique une chaîne de filtres par résolution, en deux passes selon le type de feature. Le code source de référence est MapBuilder.java L929-1354.

Gate préliminaire (L929-930) :

lines = lines.stream().filter(l -> l.getMinResolution() <= res).collect(Collectors.toList());
shapes = shapes.stream().filter(s -> s.getMinResolution() <= res).collect(Collectors.toList());

Ce gate est l'équivalent du EndLevel filtering d'imgforge (fix TD-1). Une feature dont MinResolution > res n'est pas simplifiée — elle n'est pas émise du tout.

Chaîne polylignes (L1248-1283)¶

Pour les polylignes normales (res < 24, tous les niveaux sauf n=0) :

RoundCoordsFilter
→ SizeFilter(MIN_SIZE_LINE=1)
→ RemoveObsoletePointsFilter
→ DouglasPeuckerFilter(2.6 × (1 << shift))
→ RemoveEmpty → LineSplitterFilter → LinePreparerFilter → LineAddFilter

Chaîne polygones (L1313-1335)¶

PolygonSplitterFilter
→ RoundCoordsFilter
→ RemoveObsoletePointsFilter
→ SizeFilter(min-size-polygon=8)
→ DouglasPeuckerFilter(2.6 × (1 << shift))
→ RemoveEmpty → LinePreparerFilter → ShapeAddFilter

Paramètres par défaut¶

§3 — Filtre par filtre¶

RoundCoordsFilter¶

Quantifie chaque coordonnée à la grille de résolution (1 << shift) unités Garmin. Une unité Garmin ≈ 2,14 m (latitude, aux latitudes de la France). Désactivé à res=24 (enableLineCleanFilters requiert res < 24).

Mode spécial courbes de niveau : pour chaque point intermédiaire, mkgmap teste les 4 coins de la cellule et choisit celui qui minimise la somme des distances au segment avant et après (calcDistortion). Ce mode "best-fit" produit un tracé naturellement aligné sur la grille, visuellement plus fluide que l'arrondi naïf.

SizeFilter¶

Supprime les features dont la bounding box est trop petite pour être visible à la résolution courante. Désactivé à res=24.

maxDimension < minSize × (1 << shift)

Exemple : une portion de CONSTRUCTION_LINEAIRE (mur, haie) de 20 m de long disparaît dès n=3 (shift=3, seuil = 8 unités ≈ 17 m pour les lignes). Cela réduit la RGN aux niveaux larges sans affecter le zoom maximal.

DouglasPeuckerFilter¶

L'erreur maximale est scalée exponentiellement par niveau :

// DouglasPeuckerFilter.java L43
maxErrorDistance = filterDistance * (1 << config.getShift());
// avec filterDistance = 2.6 (défaut) et shift = 24 - res
// Désactivé à res=24 (enableLineCleanFilters requiert res < 24)

mkgmap est 10 à 40× plus agressif que notre profil aux niveaux de dézoom (n=4..6). À n=6, mkgmap accepte une erreur de ~1,4 km — seules les grandes inflexions du réseau routier survivent.

RemoveObsoletePointsFilter¶

Élimine après chaque filtre :

• Les points dupliqués (coordonnées identiques après arrondi)
• Les points colinéaires stricts (STRICTLY_STRAIGHT)
• Les spikes (inversions brusques de direction)

Appliqué après RoundCoordsFilter pour les polylignes et polygones. Le nettoyage post-quantification est crucial : RoundCoordsFilter peut projeter deux coordonnées distinctes vers la même valeur arrondie, produisant des doublons que RemoveObsolete élimine immédiatement.

SmoothingFilter — code mort¶

// SmoothingFilter.java — jamais instancié dans MapBuilder r4924
// stepsize = 5 << shift — moyenne glissante de groupes de points adjacents

SmoothingFilter est présent dans les sources de mkgmap r4924 mais jamais instancié dans MapBuilder.java. C'est un artefact historique. L'effet lissant visuel de mkgmap vient de RoundCoordsFilter (quantification grille, mode best-fit courbes de niveau) et de DouglasPeuckerFilter (élimination des micro-déviations), pas de ce filtre.

Le lissage smooth: chaikin d'imgforge/mpforge (itérations de subdivision de courbes) n'a pas d'équivalent dans mkgmap r4924 — les deux outils lissent par des mécanismes orthogonaux.

LineMergeFilter — option avancée¶

LineMergeFilter est instancié dans MapBuilder.java L933 uniquement si l'option --merge-lines est passée à mkgmap. Non activé par défaut. Ce filtre fusionne des segments de même type adjacents pour réduire le nombre de features distinctes. Il n'est pas inclus dans la chaîne standard documentée ici.

§4 — Comparaison avec notre pipeline¶

Ce qu'implémente mpforge/imgforge¶

Couverture des couches par generalize-profiles-local.yaml¶

Sur les 124 863 features de BDTOPO-001-004.mp (Vienne), le profil local couvre 8 couches représentant 34 % des features. Les 66 % restants traversent le pipeline sans simplification géométrique par niveau.

Couches couvertes (profil avec simplification) :

Principales couches non couvertes :

§5 — Comportement selon la configuration de profils¶

§6 — Recommandations priorisées¶

Candidats d'implémentation classés par rapport gain/complexité, basés sur les mesures §1.

Les niveaux n=1..5 représentent 389 342 bytes (37 % du RGN total) — c'est sur cette tranche que les filtres mkgmap ont le plus d'effet. Le niveau n=0 (663 942 bytes, 63 %) est non affecté par les filtres mkgmap (res < 24).

Bilan¶

L'ensemble des 5 candidats est maintenant implémenté. Le gain total combiné estimé reste de l'ordre de 12-21 % du RGN total (1 053 284 → ~830-925 KB), en supposant une indépendance approximative des effets. L'effet principal de mkgmap au niveau visuel (lissage géométrique aux zooms larges) vient surtout de RoundCoordsFilter + DP scalé.

Les trois filtres imgforge (RoundCoordsFilter, SizeFilter, RemoveObsoletePointsFilter) sont actifs par défaut à tous les niveaux n>0. Ils peuvent être désactivés individuellement pour mesurer leur impact isolé ou reproduire le comportement d'une baseline sans filtres :

# Désactiver uniquement RoundCoordsFilter (mesure impact sub-pixel)
imgforge build tiles/ --no-round-coords

# Désactiver les trois filtres (baseline sans filtrage post-parsing)
imgforge build tiles/ --no-round-coords --no-size-filter --no-remove-obsolete-points

§7 — Sélection des features par niveau : imgforge est-il correct ?¶

Hypothèse initiale¶

La différence de 95 subdivisions (mkgmap) vs 4 (imgforge) à n=5, avec un écart de bytes de 15,8×, avait soulevé la question : mkgmap inclut-il des features à n=5 qu'imgforge exclurait à tort ? L'hypothèse était que mkgmap lirait les sections DataN de manière cumulative (minResolution = min(résolution de tous les DataN lus)) et promourait ainsi des features vers des niveaux dépassant leur EndLevel.

Vérification — mpforge n'émet jamais DataN au-delà de EndLevel¶

La distribution du MP de production (BDTOPO-001-004.mp, 124 863 features) est parfaitement propre :

mpforge n'émet jamais DataN au-delà de EndLevel. L'hypothèse d'une promotion par lecture cumulative ne peut donc pas se produire : mkgmap ne voit pas de Data5= pour une feature avec EndLevel=4.

Vérification — même features à n=5¶

Selon la logique feature_visible_at_level d'imgforge (writer.rs) :

• Feature visible à n=5 si EndLevel ≥ 5 ET il existe DataN(k ≤ 5)
• Résultat sur le MP : 4 795 features (exactement celles avec EndLevel=6)

mkgmap applique la même règle via son gate l.getMinResolution() <= res (MapBuilder.java L929), où minResolution est dérivé de EndLevel. Les deux outils incluent les mêmes features à n=5.

Explication de l'écart de bytes¶

La différence 129 713 bytes (mkgmap) vs 8 200 bytes (imgforge) à n=5 pour les mêmes 4 795 features vient de deux facteurs combinés :

1. Granularité du splitter : mkgmap crée 95 petites subdivisions (~50 features/subdiv) là où imgforge crée 4 grandes subdivisions (~1 200 features/subdiv). Chaque subdivision porte un overhead de structure fixe dans la RGN — 95 × overhead >> 4 × overhead.

2. Chaîne de filtres : les 4 795 features passent par RoundCoordsFilter + DouglasPeuckerFilter (erreur 166 unités ≈ 356 m à n=5) dans mkgmap, réduisant chaque polyligne à quelques points. Dans imgforge, la simplification à n=5 dépend du profil YAML (14 m pour les routes communales, absent pour les features hors profil).

Conclusion¶

L'implémentation imgforge est correcte et sémantiquement fidèle à mkgmap sur la sélection des features. La différence de taille à n=5 est intégralement expliquée par la granularité du splitter (plus d'overhead de structure côté mkgmap) et l'absence des filtres RoundCoords + SizeFilter côté imgforge.

La granularité fine de mkgmap (petites subdivisions) peut offrir un avantage côté firmware Garmin (moins de données à charger par requête), mais c'est une optimisation de splitter distincte du sujet de cette page.

Annexe A — Extraction manuelle du sous-map imgforge¶

Le script bytes-per-level.py lit le premier sous-map alphabétique trouvant un TRE. Pour un IMG imgforge au format GMP, deux sous-maps ont un TRE :

Le script choisit 00011855 (ordre alphabétique) — le résultat affiché par défaut est le conteneur vide. Pour analyser la vraie tuile, il faut modifier le script pour cibler 00380042 explicitement, ou ajouter un argument --submap <nom>.

Annexe B — Sources de référence¶