Une application tactique de terrain vit ou meurt selon sa carte de fond. Lorsque le soldat qui tient le téléphone se trouve dans une vallée sans signal cellulaire, sans liaison satellite et avec une batterie qui doit tenir toute la mission, la carte doit déjà se trouver sur l'appareil — chaque tuile, chaque courbe de niveau, chaque route, regroupée dans un fichier chargé avant que l'opérateur ne franchisse la ligne. La question de savoir quel format de conteneur abrite cette carte n'est pas cosmétique. Elle détermine les budgets de stockage, les performances de rendu, l'outillage dont votre chaîne a besoin, et le fait que les données s'intègrent directement dans ATAK ou nécessitent une étape de conversion sur le terrain. Voici une comparaison d'ingénierie des trois formats qui comptent : GeoPackage, MBTiles et PMTiles.
1. le problème de la carte de fond hors ligne
La contrainte déterminante d'une application de terrain est l'absence de liaison de retour. Il n'y a pas de serveur de tuiles à appeler, pas de CDN, pas d'API en direct. Tout ce que le moteur de rendu dessinera un jour doit résider sur le stockage local avant que l'appareil ne s'isole. Cela transforme la livraison des cartes en un problème d'empaquetage : il faut un artefact unique, copiable et vérifiable, qui contienne l'équivalent d'une région entière de données cartographiques et qu'un moteur de rendu mobile puisse interroger à grande vitesse depuis un stockage flash.
Le stockage est limité et disputé. Un appareil Android durci destiné à l'utilisateur final peut allouer 16 à 64 Go aux données de mission, partagées entre l'imagerie, l'élévation, les clips vidéo en mouvement et la carte de fond. Une carte de fond raster à l'échelle d'un théâtre, à des niveaux de zoom exploitables, peut atteindre à elle seule des dizaines de gigaoctets. Le format de conteneur n'est donc pas qu'une simple enveloppe — son comportement de compression, sa structure de pyramide de tuiles et son coût d'interrogation décident directement de la quantité de carte que vous pouvez transporter et de la vitesse à laquelle elle s'affiche.
2. MBTiles — le conteneur de tuiles SQLite
MBTiles est le format qui a rendu la cartographie hors ligne ordinaire. C'est, en son cœur, une base de données SQLite dotée d'un schéma convenu : une table tiles indexée par niveau de zoom, colonne et ligne, plus une table metadata de paires nom/valeur décrivant les limites, le zoom min/max, le format et l'attribution. Le génie réside dans sa simplicité — toute plateforme dotée d'une bibliothèque SQLite (c'est-à-dire toute plateforme mobile) peut l'ouvrir et l'interroger sans pilote particulier.
MBTiles contient soit des tuiles raster (PNG, JPEG, WebP), soit des tuiles vectorielles (Mapbox Vector Tiles, protobuf compressé en gzip). Le MBTiles raster est ce que la plupart des opérateurs de terrain ont réellement utilisé : imagerie pré-rendue ou planches topographiques numérisées, découpées dans la pyramide de tuiles Web Mercator standard et empilées dans la base de données. Le champ format de la table metadata indique au client s'il doit s'attendre à du png ou du pbf, et la convention de numérotation des lignes TMS (axe y inversé par rapport à XYZ) est le seul piège persistant qui surprend une fois chaque nouvel intégrateur.
Son omniprésence est l'argument principal. MBTiles est une norme de fait avec une décennie d'outillage derrière elle, et c'est la lingua franca de l'écosystème ouvert de cartographie hors ligne. Si vous devez choisir un format que quelque chose en aval comprendra à coup sûr, MBTiles est le pari sûr.
3. PMTiles — le format à fichier unique optimisé pour le cloud
PMTiles, créé par Brandon Liu, résout un problème que MBTiles ne peut pas résoudre : servir des tuiles directement depuis un stockage statique sans processus de base de données. Une archive PMTiles est un fichier unique comportant un répertoire compact en tête et les données de tuiles derrière, agencés de sorte qu'un client puisse récupérer n'importe quelle tuile individuelle avec une requête de plage HTTP (HTTP range request). Placez le fichier sur un simple object store ou une carte flash, et le client lit le répertoire une fois, puis ne demande par plage d'octets que les tuiles dont il a besoin — pas de serveur de tuiles, pas de processus SQLite, pas de décompression.
Pour une application de terrain, cela présente deux avantages distincts. Sur un réseau de préparation connecté, une archive PMTiles dans un bucket statique remplace toute une pile de serveur de tuiles, ce qui fait une chose de moins à déployer et à homologuer. Sur l'appareil, ce même agencement à fichier unique et en ajout seul (append-only) se copie et se contrôle proprement et se prête bien aux lectures de type mmap. Le répertoire en grappe du format maintient l'index petit même pour des archives à l'échelle planétaire, de sorte que la recherche par tuile reste peu coûteuse. Les compromis autour des cartes hors ligne MBTiles et PMTiles se résument à savoir si votre moteur de rendu parle nativement le modèle d'accès par requête de plage ou s'attend à un descripteur SQLite.
Idée clé : MBTiles, PMTiles et le GeoPackage tuilé encodent tous exactement la même pyramide de tuiles Web Mercator — les mêmes octets PNG ou de tuiles vectorielles. La guerre des formats ne porte pas sur les tuiles ; elle porte sur l'index placé devant elles. Choisissez l'index qui correspond à la façon dont votre moteur de rendu lit le stockage : requête SQLite, plage HTTP ou accès aux entités OGC. Les pixels sont identiques.
4. GeoPackage — la norme OGC
GeoPackage (GPKG) est le seul des trois à être une norme ouverte formelle, publiée par l'Open Geospatial Consortium et adoptée comme conteneur pertinent pour la National Geospatial-Intelligence Agency américaine et l'OTAN. Comme MBTiles, il repose sur SQLite, mais il est bien plus ambitieux : un seul fichier GeoPackage peut contenir des pyramides de tuiles raster, des tables d'entités vectorielles avec géométrie et attributs complets, des index spatiaux (R-tree) et les métadonnées pour tout décrire. Un seul fichier peut être à la fois votre carte de fond et votre surcouche vectorielle — pistes des forces amies, mesures de coordination, zones d'intérêt nommées — dans une seule base de données interrogeable et modifiable.
Cette ampleur explique pourquoi GeoPackage domine dans le monde géospatial formel de la défense. Lorsqu'une cellule géospatiale livre un paquet de données de mission, GeoPackage permet aux tuiles d'imagerie et aux données d'entités attribuées de voyager ensemble dans un seul artefact responsabilisable, doté d'un schéma documenté que le système destinataire est contractuellement tenu de lire. Le coût est que GeoPackage est plus lourd à produire et que son modèle d'entités complet dépasse ce dont une simple carte de fond a besoin — vous transportez une norme conçue pour des données SIG modifiables, et pas seulement un cache de tuiles.
5. compromis entre taille et performances
Le choix du format modifie moins la taille du fichier qu'on ne le pense, car le coût dominant tient aux octets des tuiles, et ceux-ci sont en grande partie les mêmes d'un conteneur à l'autre. Les véritables leviers se situent en amont : format de tuile (le WebP bat le PNG de 25 à 35 % à qualité égale), seuil de niveau de zoom, et le fait de servir du vectoriel ou du raster.
Les tuiles vectorielles sont le grand gain. Une carte de fond raster d'un pays au zoom 0–16 peut faire 20 à 40 Go ; l'ensemble équivalent de tuiles vectorielles, où la géométrie est encodée une seule fois et stylée au moment du rendu, atterrit couramment à 1–3 Go pour la même couverture. Le vectoriel permet aussi à l'appareil de re-styler à la volée — palettes jour/nuit, bascules de couches propres à la mission — sans re-générer les tuiles. Le coût se paie en GPU et CPU au moment du dessin : l'appareil assemble l'image image par image au lieu de recopier une image pré-cuite, ce qui correspond précisément au type de budget de rendu cartographique en temps réel que vous devez profiler sur le matériel cible réel, et non sur un ordinateur portable de développeur.
Sur le coût d'interrogation, les trois sont en pratique proches. MBTiles et GeoPackage adossés à SQLite résolvent une tuile par une recherche indexée sur clé primaire — quelques microsecondes depuis un cache chaud. PMTiles résout via son répertoire interne au fichier, soit une ou deux lectures, également négligeable une fois le répertoire racine mis en cache. Aucun de ceux-ci n'est le goulot d'étranglement ; ce sont les E/S de stockage et le décodage/rendu. La conclusion d'ingénierie honnête : choisissez le format en fonction de l'adéquation à l'outillage et à l'intégration, puis consacrez votre effort de performance au format de tuile, au budget de zoom et au moteur de rendu.
6. support ATAK/TAK et applications de terrain
Pour l'écosystème TAK, la réponse est concrète. ATAK lit nativement MBTiles et GeoPackage comme sources de carte de fond — déposez le fichier dans le bon répertoire ou importez-le via le gestionnaire de paquets, et il apparaît comme une couche cartographique sélectionnable. Le MBTiles raster est la voie la plus éprouvée au combat et celle vers laquelle se tournent la plupart des opérateurs. GeoPackage est le bon choix lorsque vous avez besoin de l'imagerie et des entités vectorielles attribuées dans un seul paquet de mission importable, ce qui est la manière standard dont les produits de données formels parviennent au client.
PMTiles est le nouveau venu. Il est de plus en plus pris en charge via des plugins et dans les clients modernes basés sur MapLibre, mais ce n'est pas encore l'import natif de carte de fond par défaut dans toutes les versions de TAK ; vérifiez donc la version spécifique du client avant de le standardiser pour un programme déployé. Le flux de travail pragmatique adopté par de nombreuses équipes : créer et stocker en PMTiles pour ses avantages de diffusion à fichier unique, puis exporter vers MBTiles ou GeoPackage pour le paquet final destiné à l'appareil lorsque le client cible l'exige.
7. outillage
La chaîne de conversion est là où les heures d'ingénierie passent réellement. Pour les tuiles vectorielles, tippecanoe — issu à l'origine de Mapbox, désormais maintenu par Felt — est le cheval de trait : il transforme du GeoJSON ou d'autres sources vectorielles en un ensemble de tuiles vectorielles MBTiles ou PMTiles optimisé, gérant l'abandon d'entités, la fusion et la généralisation par niveau de zoom afin que les données denses restent affichables à faible zoom. C'est l'outil le plus important d'une chaîne vectorielle hors ligne.
Pour tout le reste, GDAL est l'adaptateur universel. Ses utilitaires raster et vectoriels convertissent entre formats, construisent des pyramides de tuiles, et lisent ou écrivent du GeoPackage, du MBTiles et (dans les versions actuelles) du PMTiles. ogr2ogr déplace les entités vectorielles dans des tables d'entités GeoPackage ; gdal_translate et gdaladdo construisent les pyramides de tuiles raster GeoPackage ; gdal2tiles découpe l'imagerie dans la pyramide standard. Une chaîne de production type enchaîne données source → GDAL ou tippecanoe → conteneur → contrôle d'intégrité → paquet de données de mission, scriptée et reproductible de sorte que la même région se reconstruise octet pour octet. L'outil en ligne de commande PMTiles complète le tout, convertissant le MBTiles en PMTiles et inspectant les répertoires d'archives.
8. choisir pour une application de terrain
La décision se résume à trois questions. Premièrement, raster ou vectoriel ? Si vous pouvez créer et styler des tuiles vectorielles de bout en bout, faites-le — la réduction de taille d'un facteur 10 et le re-stylage sur l'appareil sont décisifs pour des appareils à stockage limité. Ne repliez sur le raster que lorsque la source est de l'imagerie ou des planches numérisées sans équivalent vectoriel.
Deuxièmement, diffusion à fichier unique ou richesse d'entités ? Si vous avez besoin d'imagerie plus d'entités vectorielles attribuées et modifiables dans un seul artefact responsabilisable — le cas du paquet formel de données de mission — GeoPackage est la réponse, et son statut de norme OGC est ce qui le fait accepter au sein d'une coalition. Si vous livrez une simple carte de fond et voulez le scénario de diffusion le plus léger, le modèle à fichier unique et sans serveur de PMTiles l'emporte.
Troisièmement, que lit le client aujourd'hui ? Pour les programmes TAK qui se déploient maintenant, du MBTiles raster ou vectoriel pour la carte de fond et du GeoPackage pour les paquets combinant imagerie et entités constituent le choix pragmatique par défaut — les deux s'importent nativement, les deux sont éprouvés au combat. Adoptez PMTiles là où votre moteur de rendu parle déjà les requêtes de plage et où vous contrôlez la version du client. Quel que soit votre choix, gardez le format hors de votre domaine métier central : stockez les données cartographiques canoniques une seule fois, et traitez MBTiles, PMTiles et GeoPackage comme des cibles d'export interchangeables issues d'une même chaîne reproductible. Le conteneur est une décision d'empaquetage, pas une architecture dans laquelle vous devriez être enfermé.