Meilleurs formats de fichiers GIS pour applications mobiles : le guide définitif du développeur

Les applications SIG mobiles sont confrontées à des contraintes matérielles et réseau que les configurations SIG de bureau ne rencontrent jamais. Les appareils portables fonctionnent avec une RAM limitée, une autonomie de batterie fluctuante et une connectivité cellulaire intermittente ou inexistante sur le terrain. Tenter d’analyser un jeu de données spatiales monolithique et mal structuré sur un appareil iOS ou Android entraîne des plantages d’application, une réponse tactile lente et une forte consommation de batterie.

Choisir le bon conteneur de données géographiques est la décision technique la plus impactante lors de la conception d’outils d’inspection sur le terrain, de tableaux de bord logistiques, de traceurs de randonnée hors ligne ou d’applications d’urbanisme. Ce guide décortique les principaux formats spatiaux pour les environnements mobiles, compare leurs compromis opérationnels et fournit des recommandations concrètes basées sur des cas d’utilisation réels.

Contraintes techniques des environnements GIS mobiles

Avant d’évaluer les formats, considérez les quatre limitations fondamentales qui dictent les performances mobiles :

1. Allocation de mémoire (RAM) : Les systèmes d’exploitation mobiles tuent agressivement les processus en arrière-plan ou les tâches gourmandes en tas. Charger des couches vectorielles non indexées directement en mémoire entraîne une terminaison rapide pour dépassement de mémoire (OOM).
2. Entrée/Sortie hors ligne et accès aléatoire : Les travailleurs sur le terrain perdent fréquemment l’accès au réseau. Le moteur de stockage doit prendre en charge les requêtes spatiales indexées au niveau du disque (par ex., R-Tree) afin que l’application ne lise que les entités actuellement dans le champ de vision plutôt que de scanner le fichier complet.
3. Surcharge de données et bande passante : Transmettre des charges utiles volumineuses sur les réseaux 3G/4G/5G draine les batteries des appareils et consomme des quotas de données coûteux.
4. Mutabilité en lecture/écriture : Les flux de travail d’inspection mobile exigent que le personnel sur le terrain enregistre les coordonnées GPS, ajoute des notes, mette à jour les attributs d’état et synchronise les modifications avec les bases de données centrales sans corruption de fichier.

Évaluation détaillée : Meilleurs formats GIS pour mobile

1. GeoPackage (.gpkg) — Le standard or de l’industrie incontesté

Maintenu comme une norme ouverte par le Open Geospatial Consortium (OGC), GeoPackage est construit sur un conteneur de base de données SQLite intégré.

• Pourquoi il excelle sur mobile : SQLite est intégré nativement aux systèmes d’exploitation Android et iOS. Interroger un GeoPackage ne nécessite aucune couche d’analyse personnalisée lourde. Il utilise l’indexation spatiale (R-Tree) dès le départ, permettant aux applications de récupérer rapidement des tranches de boîtes englobantes spatiales sans charger la base de données complète en RAM.
• Fonctionnalités clés : Il prend en charge à la fois les données vectorielles et les pyramides de tuiles raster dans un seul fichier binaire compact. Il gère plusieurs couches, des attributs complexes, des définitions de schéma et des mises à jour spatiales directes (INSERT, UPDATE, DELETE).
• Meilleure utilisation : Collecte de données hors ligne, applications d’inspection sur le terrain (par ex., QField, Mergin Maps), gestion d’actifs et stockage hors ligne mixte vectoriel/raster.

2. MBTiles (.mbtiles) — Idéal pour les cartes de base et les images raster

Initialement développé par Mapbox, MBTiles est également une spécification basée sur SQLite conçue spécifiquement pour empaqueter des tuiles cartographiques pré-rendues.

• Pourquoi il excelle sur mobile : MBTiles résout le goulot d’étranglement du système de fichiers. Stocker des dizaines de milliers d’images de tuiles individuelles (.png ou .pbf) directement sur les systèmes de fichiers mobiles dégrade les performances. Regrouper ces tuiles dans un seul conteneur SQLite permet des recherches quasi-instantanées grâce à l’indexation standard des coordonnées de tuiles SQL (z, x, y).
• Tuiles vectorielles (MVT) dans MBTiles : Lorsqu’elles sont combinées avec les Mapbox Vector Tiles (MVT), les MBTiles offrent des cartes de base ultra-nettes et haute performance qui peuvent être restylées dynamiquement sur l’appareil via le rendu GPU avec une empreinte de stockage minimale.
• Meilleure utilisation : Cartes de base hors ligne, couches de base d’imagerie aérienne, cartes de randonnée et affichages de navigation.

3. FlatGeobuf (.fgb) — Idéal pour le streaming vectoriel en lecture seule haute performance

FlatGeobuf est un format d’encodage binaire moderne pour les données vectorielles basé sur FlatBuffers.

• Pourquoi il excelle sur mobile : Contrairement à GeoJSON, FlatGeobuf ne nécessite aucune étape de désérialisation. Le CPU lit les données directement depuis le flux binaire sans allouer d’objets mémoire intermédiaires. Il comprend un index spatial intégré (arbre R Hilbert compacté). FlatGeobuf est particulièrement puissant sur HTTP/HTTPS : les clients mobiles peuvent émettre des requêtes de plage HTTP pour télécharger uniquement la tranche de données vectorielles couvrant la zone d’affichage actuelle de l’appareil.
• Limitations : FlatGeobuf est fondamentalement un format d’archive/flux ; il n’est pas conçu pour l’édition de base de données en place ou la manipulation d’enregistrements de champs.
• Meilleur usage : Diffusion à haute vitesse de jeux de données vectorielles volumineux (par ex., parcelles nationales, courbes de niveau, réseaux routiers) avec un rendu de la zone d’affichage quasi instantané.

4. GeoJSON (.geojson) — Idéal uniquement pour les charges utiles d’API légères

GeoJSON est un standard ouvert et lisible par l’homme basé sur la notation JavaScript Object Notation.

• Pourquoi c’est risqué pour les grands ensembles de données: Parce que le GeoJSON est basé sur du texte et non indexé, les appareils mobiles doivent analyser toute la chaîne et instancier chaque coordonnée et propriété en mémoire avant le rendu. Un fichier GeoJSON de 40 Mo peut rapidement gonfler à plusieurs centaines de mégaoctets de mémoire du tas, faisant planter un client mobile.
• Quand l’utiliser: Idéal pour transmettre de petites charges transactionnelles (p. ex., une seule géométrie de route, 50 points d’intérêt à proximité, ou des soumissions rapides de formulaires API).

5. Shapefile (.shp) — Pourquoi vous devez l’éviter sur mobile

Développé dans les années 1990 par Esri, le Shapefile reste courant sur les systèmes de bureau hérités, mais il est mal adapté au développement mobile :

• Il nécessite plusieurs fichiers associés (.shp, .shx, .dbf, .prj), créant des risques de synchronisation et d’empaquetage des fichiers.
• Les noms de champs sont tronqués à 10 caractères.
• La taille maximale du fichier est plafonnée à 2 Go.
• Il ne possède pas de normes d’encodage modernes, ce qui entraîne souvent une corruption du jeu de caractères avec du texte international.

Matrice de comparaison : Formats GIS mobiles

Recommandations architecturales pratiques

Lors de la création d’une architecture GIS mobile de qualité production, évitez de dépendre d’un format unique pour toutes les tâches. Les applications GIS modernes utilisent une approche de stockage à plusieurs niveaux :

1. Pour les éditions de terrain hors ligne & capture de données : Utilisez GeoPackage (.gpkg). Son socle SQLite natif garantit la conformité ACID, les jointures multi‑tables, des mises à jour géométriques fluides et une mise en cache hors ligne fiable.
2. Pour les fonds de carte hors ligne & superpositions de tuiles : Utilisez MBTiles (.mbtiles) contenant des Mapbox Vector Tiles (MVT). Cela maintient le stockage de fichiers propre et délègue le rendu au GPU mobile.
3. Pour la synchronisation vectorielle en direct du cloud vers le mobile : Diffusez les géométries en utilisant FlatGeobuf (.fgb) via des requêtes de plage HTTP pour des couches massives en lecture seule, ou des extraits GeoJSON légers pour les mises à jour de points individuels et les alertes en temps réel.

Métadonnées SEO & Titres proposés

Suggestions d’étiquettes de titre

1. Meilleur format de fichier GIS pour les applications mobiles : Performance, stockage et guide hors ligne
2. Architecture GIS mobile : Pourquoi GeoPackage et MBTiles surpassent les formats hérités
3. Principaux formats GIS pour le développement d’applications mobiles : Vitesse, mémoire et synchronisation hors ligne

Suggestions de méta description

1. Découvrez les meilleurs formats de fichiers GIS pour les applications mobiles. Comparez GeoPackage, MBTiles, FlatGeobuf et GeoJSON pour l’efficacité mémoire, la synchronisation hors ligne et le rendu rapide.
2. Vous créez une application de cartographie mobile ? Découvrez quels formats de données spatiales évitent les plantages de mémoire, prennent en charge l’édition de terrain hors ligne et garantissent un rendu ultra‑rapide.
3. Guide du développeur sur les formats de fichiers SIG mobiles. Découvrez pourquoi GeoPackage et MBTiles dominent la collecte de données sur le terrain tandis que les anciens Shapefiles sont insuffisants.

Foire aux questions

Pourquoi GeoPackage est-il préféré au Shapefile pour les applications mobiles ? GeoPackage consolide la géométrie, les attributs et l’indexation dans un seul fichier SQLite compact, ce qui permet une édition directe rapide sans les risques de dépendance multi‑fichiers des Shapefiles.

Un GeoPackage peut‑il stocker simultanément des données raster et vectorielles ? Oui, la norme OGC GeoPackage prend en charge les entités vectorielles et les pyramides de tuiles raster au sein du même conteneur de base de données.

Qu’est‑ce qui rend MBTiles idéal pour les fonds de carte mobiles ? MBTiles stocke des dizaines de milliers de tuiles cartographiques dans une base de données SQLite indexée, éliminant les ralentissements du système de fichiers mobiles causés par les recherches de répertoires de fichiers image séparés.

Quand les développeurs doivent‑ils éviter d’utiliser GeoJSON dans les applications mobiles ? Évitez GeoJSON lorsqu’il s’agit de jeux de données de plus de 10 Mo ou de milliers d’entités, car l’analyse de gros blocs de texte JSON entraîne des pics de mémoire élevés et des ralentissements de l’interface mobile.

Comment FlatGeobuf améliore-t-il le streaming de données vectorielles mobiles ? FlatGeobuf permet la lecture binaire sans désérialisation en mémoire et utilise les requêtes HTTP de plage afin que les appareils mobiles ne téléchargent que les entités présentes dans leur fenêtre actuelle.

Voir aussi

Formats de fichiers SIG sur FileFormat.com

Top 5 des formats de fichiers SIG pour Google Maps

Actualités des formats de fichiers

Forums des formats de fichiers

GeoParquet vs. GeoJSON : quel format SIG est meilleur pour les grands ensembles de données ?

Si vous avez déjà essayé d’ouvrir un fichier GeoJSON de 2 Go dans QGIS ou de charger un fichier de limites polygonales contenant plusieurs millions de lignes dans une carte interactive, vous connaissez déjà la sensation désagréable d’un écran figé et d’un plantage dû à un manque de mémoire.

Depuis plus d’une décennie, GeoJSON sert de lingua franca universelle de la cartographie web. Il est transparent, lisible par l’homme et pris en charge immédiatement par presque toutes les bibliothèques de cartographie web et les API REST sur Internet.

Cependant, les flux de travail GIS modernes sont radicalement différents de ceux de 2008. Les praticiens géospatiaux d’aujourd’hui ingèrent régulièrement des gigaoctets (ou téraoctets) de télémétrie de mobilité IoT, des empreintes de bâtiments à l’échelle nationale, des masques de segmentation dérivés de satellites et des grilles climatiques à haute fréquence.

Lorsqu’il est appliqué à des ensembles de données à cette échelle, le GeoJSON ne se contente pas de ralentir — il crée un goulot d’étranglement complet des architectures de données.

Voici GeoParquet, une extension géospatiale ouverte et standardisée d’Apache Parquet en incubation au sein de l’Open Geospatial Consortium (OGC).

Dans ce guide complet, nous comparons GeoParquet et GeoJSON en termes d’architecture, d’efficacité de stockage, de débit de lecture/écriture, de préparation au cloud et d’ergonomie pour les développeurs afin de répondre à une question cruciale : Quel format devez‑vous choisir pour les grands ensembles de données ?

1. Architecture structurelle : texte vs. colonne binaire

Pour comprendre pourquoi ces formats se comportent si différemment à grande échelle, il faut examiner en profondeur la façon dont chacun représente les valeurs de coordonnées et les métadonnées tabulaires.

+--------------------------------------------------------------+
| Métrique d'évaluation |
| **Format de données** |
| **Représentation géométrique** |
| **Taux de compression** |
| **Projection de colonne** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Propagation de prédicat spatial** |
| **Stockage d'objets cloud (S3/GCS)** |
| **Lisibilité humaine** |
| **Prise en charge des navigateurs Web** |
| **Organisme de normalisation** |
+--------------------------------------------------------------+

GeoJSON : orienté lignes, JSON encodé en texte

GeoJSON représente les données sous forme d’un tableau d’objets JSON. Chaque caractéristique répète explicitement les clés d’attributs aux côtés d’un tableau de nombres à virgule flottante encodés en chaîne :

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

Parce que GeoJSON est basé sur du texte :

• Schémas répétitifs : Les noms de champs comme "properties", "type" et "coordinates" sont répétés des millions de fois, gonflant la taille brute du fichier.
• Conversion coûteuse de chaîne en flottant : Votre CPU doit analyser les caractères texte ("-", "9", "7", ".", "7"...) en nombres à virgule flottante double précision IEEE 64 bits avant d’effectuer toute opération spatiale.
• Exigences de lecture monolithiques : Les analyseurs JSON standard doivent charger le fichier entier en mémoire pour construire le Document Object Model (DOM). Lire un seul attribut nécessite d’analyser chaque caractéristique.

GeoParquet : orienté colonnes, données encodées en binaire

GeoParquet s’appuie directement sur Apache Parquet, stockant les tables spatiales colonne par colonne plutôt que ligne par ligne.

Des attributs comme county sont stockés dans des blocs contigus, permettant des techniques de compression avancées telles que l’encodage run-length (RLE), le bit-packing et la compression par dictionnaire. Les données géométriques sont standardisées en Well-Known Binary (WKB), accompagnées de métadonnées JSON intégrées détaillant les systèmes de référence spatiale (CRS), les boîtes englobantes et les types de géométrie.

Parce que GeoParquet est binaire et columnaire :

• Coût zéro d’analyse des coordonnées : Les géométries sont stockées directement en forme binaire, contournant les coûteuses conversions chaîne‑vers‑flottant.
• Projection Pushdown : Si votre flux de travail en aval n’a besoin que des colonnes county et pop_density, le lecteur récupère uniquement ces décalages d’octets depuis le disque ou S3, en sautant complètement la colonne de géométrie.
• Partitionnement par groupe de lignes : Les fichiers Parquet divisent les enregistrements en “Row Groups” autonomes (souvent de 100 000 à 1 000 000 de lignes chacun) complets avec des statistiques min/max pour chaque colonne.

2. Comparaison côte à côte : les métriques principales

3. Efficacité de stockage et références de taille de fichier

Lors du passage de milliers à des millions d’enregistrements, les disparités de stockage s’élargissent considérablement.

Dans les benchmarks standard utilisant des enregistrements spatiaux ouverts du monde réel (tels que les empreintes de bâtiments OpenStreetMap, les limites TIGER du recensement américain et les journaux AIS mondiaux des navires), GeoParquet réalise régulièrement des réductions de stockage de 70 % à 85 % par rapport au GeoJSON brut, et surpasse .geojson.gz de 20 % à 40 % supplémentaires.

Pourquoi GeoParquet est-il tellement plus petit ?

1. Encodage par dictionnaire : Les attributs de chaîne répétés (par ex., les codes d’état, les classifications d’utilisation des sols) sont indexés en de petits pointeurs entiers plutôt que stockés à plusieurs reprises comme de longues chaînes.
2. Coordonnées binaires compactes : Un point 2D dans GeoJSON occupe environ 30 à 45 octets de texte ASCII ([-122.4194155, 37.7749295]). En WKB, cette même paire de coordonnées nécessite exactement 16 octets.
3. Algorithmes de compression modernes : Zstandard (Zstd) et Snappy compressent les tableaux d’octets columnaires beaucoup plus efficacement que le Gzip standard ne peut compresser le texte en lignes entrelacées.

4. Performance des requêtes et flux de travail cloud‑native

Le principal différenciateur pour les grands ensembles de données n’est pas seulement le stockage — c’est la latence des requêtes et l’utilisation de la mémoire.

1. Lectures sélectives via projection de colonnes

Imaginez un jeu de données national de parcelles de 15 Go contenant 60 attributs (noms de propriétaires, identifiants fiscaux, historique des titres, codes de zonage et limites multipolygones complexes).

• En GeoJSON : Si vous souhaitez calculer la valeur moyenne évaluée des propriétés par code postal, votre moteur analytique doit télécharger et analyser les 15 Go complets, y compris des millions de sommets de limites complexes.
• En GeoParquet : Les moteurs analytiques tels que DuckDB, Apache Sedona, Polars ou AWS Athena lisent uniquement les colonnes zip_code et assessed_value. Au lieu de transférer 15 Go, votre moteur télécharge et analyse moins de 80 Mo.

2. Requêtes HTTP Range sur le stockage cloud

GeoParquet fonctionne de manière transparente comme un format géospatial cloud‑native.

Comme les fichiers Parquet stockent les décalages internes et les métadonnées dans le pied de page du fichier, les bibliothèques clientes peuvent émettre des requêtes HTTP GET Range: bytes=... vers des stockages d’objets cloud tels qu’Amazon S3, Google Cloud Storage ou Azure Blob Storage. Au lieu de télécharger un fichier de plusieurs gigaoctets complet, le client lit le pied de page, identifie les décalages exacts où se trouvent les enregistrements pertinents, et ne télécharge que les sous‑ensembles nécessaires.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. Écosystème logiciel et prise en charge des outils

Historiquement, l’avantage principal de GeoJSON était le support universel des outils. Bien que cela reste vrai pour les environnements de navigateur, l’écosystème de GeoParquet a mûri rapidement :

• GIS de bureau : prise en charge native en lecture/écriture dans QGIS 3.28+, ArcGIS Pro et GDAL/OGR 3.5+.
• Moteurs analytiques & langages : capacités rapides de lecture/écriture vectorisées sur Python (GeoPandas, pyarrow), R (sf), DuckDB (via l’extension spatiale), Apache Sedona et Snowflake.
• Pipelines Big Data : intégration native avec Apache Spark, Trino, Presto et Databricks.
• Cartes Web côté client : des bibliothèques WebAssembly légères (telles que parquet-wasm et duckdb-wasm) permettent désormais aux navigateurs web d’interroger directement les fichiers GeoParquet sur les appareils clients, sans serveur middleware GIS dédié.

6. Matrice de décision pratique : quand utiliser quoi ?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

Choisissez GeoJSON si :

• Votre jeu de données est compris entre 50 Mo et 100 Mo.
• Vous renvoyez des réponses de charge utile légères depuis une API REST vers les clients frontaux.
• Vous créez des cartes web légères avec Leaflet, MapLibre ou Mapbox GL JS sans couches de traduction intermédiaires.
• Vous avez besoin d’une édition ou d’une inspection manuelle rapide dans un éditeur de code ou de texte standard.

Choisissez GeoParquet si :

• Votre jeu de données dépasse 100 Mo, ou contient des centaines de milliers d’entités spatiales complexes.
• Vous stockez des actifs vectoriels dans un stockage d’objets cloud (S3, GCS, MinIO, Azure Blob).
• Vous exécutez des analyses SQL spatiales, de l’ingénierie des caractéristiques ou des pipelines d’apprentissage automatique en utilisant Python, DuckDB, Spark ou Databricks.
• Vous souhaitez réduire les coûts de stockage, éviter les frais de sortie réseau et éliminer les plantages de mémoire.

7. Exemple de migration : conversion de GeoJSON en GeoParquet

Convertir les actifs spatiaux existants en GeoParquet ne nécessite que quelques lignes de code.

Utilisation de Python (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

Utilisation de GDAL / OGR (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

Utilisation de DuckDB

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. Résumé : Le verdict sur les grands ensembles de données

Pour les petits jeux de données et les points de terminaison web directs, GeoJSON reste un format utilitaire fiable et sans tracas.

Cependant, pour les grands jeux de données, GeoParquet est objectivement supérieur dans chaque catégorie opérationnelle. Il offre des empreintes de fichiers plus petites, un encombrement de stockage nettement réduit, des lectures spatiales quasi instantanées, et une intégration native avec les entrepôts de données cloud modernes.

Si vos pipelines géospatiaux ploient sous le poids de fichiers GeoJSON surdimensionnés, passer à GeoParquet est l’une des améliorations d’infrastructure les plus efficaces que vous puissiez réaliser.

Foire aux questions (FAQ)

Q1. GeoParquet est-il une norme SIG officiellement reconnue ? Oui, GeoParquet est une norme ouverte officielle maintenue sous la direction du Open Geospatial Consortium (OGC).

Q2. Puis-je rendre un fichier GeoParquet directement dans des bibliothèques de cartographie web comme Leaflet ou Mapbox GL JS ? Bien qu’il ne soit pas analysé nativement comme GeoJSON, vous pouvez rendre GeoParquet dans les navigateurs en utilisant des paquets WebAssembly comme parquet-wasm ou en convertissant les fichiers en tuiles vectorielles (PMTiles/MVT) lors de l’ingestion.

Q3. GeoParquet prend-il en charge plusieurs systèmes de référence de coordonnées (CRS) ? Oui, contrairement à GeoJSON (qui est strictement limité à WGS 84 / EPSG:4326 selon la RFC 7946), GeoParquet permet des définitions de CRS personnalisées directement dans les métadonnées intégrées du fichier.

Q4. Comment GeoParquet se compare-t-il à FlatGeobuf pour les grands ensembles de données spatiales ? FlatGeobuf est optimisé pour le streaming de fonctionnalités spatiales directement vers des cartes web interactives en utilisant l’indexation spatiale R-Tree, tandis que GeoParquet est conçu pour l’analyse columnaire haute performance, la compression et le stockage massif dans des lacs de données.

Q5. Puis-je ouvrir des fichiers GeoParquet dans un logiciel SIG de bureau comme QGIS ? Oui, les versions modernes de QGIS (version 3.28 et supérieures) prennent en charge le glisser‑déposer, la visualisation et le style des fichiers GeoParquet sans nécessiter de plugins tiers.

Voir aussi

Formats de fichiers SIG sur FileFormat.com

Top 5 des formats de fichiers SIG pour Google Maps

Actualités des formats de fichiers

Forums des formats de fichiers