CCTP
ANNEXE5_ Cahier des prescriptions pour la remise de données SIG 2 (1).pdf · 1 791 mots · du marché « Prestations intellectuelles pour le projet de territoire Nîmes Métropole 2040 : construction de la vision… », dossier de consultation officiel.
Cahier des prescriptions pour la remise de données SIG
Edition 2026
1. Objet du document
Le présent document définit les règles de préparation, d'organisation et de
transmission des données géographiques dans le cadre d'un échange avec le
service Système d'information géographique (SIG).
L'objectif est de fournir un livrable :
• complet, avec l'ensemble des données et fichiers associés ;
• structuré, selon une arborescence et une nomenclature communes ;
• documenté, afin d'en comprendre rapidement le contenu ;
• interopérable, notamment entre QGIS et ArcGIS Pro ;
Le projet transmis doit pouvoir être ouvert et reconstitué dans ArcGIS Pro avec un
minimum de retraitement si nécessaire.
2. Principes d’échange
Le producteur des données doit vérifier avant transmission que :
1. toutes les couches nécessaires sont présentes dans le livrable ;
2. les couches s'ouvrent sans erreur ;
3. le système de coordonnées est correctement défini ;
4. les géométries sont valides ;
5. les champs sont nommés et renseignés de manière cohérente ;
6. les fichiers de symbologie, de styles et de mise en page sont joints ;
7. les sources externes ou chemins locaux sont supprimés, documentés ou
remplacés par des chemins relatifs ;
8. les données temporaires, doublons et versions intermédiaires ont été retirés ;
9. le contenu du livrable est décrit dans un fichier de documentation.
Lorsque plusieurs formats sont fournis, une source de référence doit être clairement
désignée. Les autres formats sont alors considérés comme des formats d'échange
ou de consultation.
3. Formats de données attendus
3.1 Format recommandé pour une base locale de projet
Le format à privilégier pour regrouper les données vectorielles d'un projet est le
GeoPackage, avec l'extension .gpkg.
Ce format permet de réunir dans un fichier unique :
• plusieurs couches vectorielles ;
• des tables non géographiques ;
• les systèmes de coordonnées ;
• les index spatiaux ;
• certains styles QGIS ;
• éventuellement des données raster (lorsque leur volume reste raisonnable).
Le GeoPackage offre une meilleure portabilité que le Shapefile et limite le nombre de
fichiers à manipuler. Il accepte également des noms de champs plus longs et des
types de données plus riches.
Si possible : Les données sont idéalement testées dans ArcGIS Pro avant
transmission, notamment lorsqu'elles contiennent des vues, des relations, des styles
internes ou des fonctionnalités propres à QGIS.
3.2 Dans le cas d’une Géodatabase fichier ArcGIS
Une géodatabase fichier, avec l'extension .gdb, peut être fournie lorsque le livrable
est directement destiné à ArcGIS Pro ou lorsqu'il nécessite des fonctions propres à
l'environnement Esri.
Elle est notamment adaptée aux éléments suivants :
• domaines de valeurs ;
• sous-types ;
• classes de relations ;
• topologies ;
• jeux de classes d'entités ;
• règles ou structures propres à ArcGIS ;
• noms de champs longs et types de données avancés.
La géodatabase doit être transmise dans son intégralité. Il s'agit d'un dossier
composé de plusieurs fichiers internes : aucun fichier ne doit être retiré, renommé ou
déplacé séparément.
En cas de transfert, l'ensemble du livrable doit être regroupé dans une
archive .zip.
3.3 Shapefile
Le Shapefile peut être utilisé comme format d'échange simple, notamment pour des
couches vectorielles ne nécessitant ni relations complexes, ni noms de champs
longs, ni structure avancée.
Une couche Shapefile est constituée de plusieurs fichiers indissociables.
Extension Contenu Caractère
.shp Géométrie Obligatoire
.shx Index des géométries Obligatoire
.dbf Données attributaires Obligatoire
.prj Système de coordonnées Obligatoire
.cpg Encodage des caractères Obligatoire
+ autres fichiers avec les Métadonnées ou index À conserver si
extensions.qmd, .sbn, .sbx complémentaires présents
Le Shapefile ne doit pas être utilisé comme base principale lorsque le projet
comporte une structure de données élaborée.
3.4 Données raster
Les rasters doivent être transmis de préférence au format GeoTIFF .tif, avec leur
géoréférencement intégré.
Pour les rasters volumineux, il convient de prévoir :
• une compression adaptée ;
• des pyramides ;
• des statistiques et valeurs calculées ;
• un système de coordonnées explicitement renseigné.
3.5 Tables de données sans géométrie
Les tableaux doivent être fournis de préférence :
• dans le GeoPackage ou la géodatabase du projet ;
• au format .csv pour un échange simple ;
• au format .xlsx lorsque la mise en forme ou la présence de plusieurs feuilles
est nécessaire.
Pour un fichier .csv :
• utiliser l'encodage UTF-8 ;
• conserver une ligne unique d'en-tête ;
• ne pas fusionner de cellules ;
• stabiliser le séparateur utilisé ;
• normaliser les dates ;
• prévoir un identifiant unique permettant les jointures ;
• éviter les formules ou mises en forme porteuses d'information.
4. Compatibilité entre QGIS et ArcGIS Pro
Les fonctions propres à QGIS ne sont pas toujours directement interprétables par
ArcGIS Pro. La fourniture du fichier de projet QGIS ne suffit donc pas à garantir la
reprise complète du projet.
Le livrable doit distinguer :
• les données sources ;
• le projet QGIS ;
• les styles et symbologies ;
• les mises en page ;
• les ressources externes ;
• la documentation.
Les éléments suivants doivent faire l'objet d'une attention particulière :
• expressions QGIS utilisées dans la symbologie ou l'étiquetage ;
• champs virtuels ;
• jointures temporaires ;
• relations non enregistrées dans la base ;
• traitements dynamiques ;
• extensions QGIS nécessaires ;
• couches issues de fichiers placés hors du dossier du projet ;
• services web nécessitant une authentification ;
Tout mécanisme non directement transposable dans ArcGIS Pro doit être décrit
dans le fichier de documentation.
5. Système de coordonnées
Toutes les couches doivent disposer d'un système de coordonnées défini, et non
simplement affecté visuellement dans le projet QGIS.
Sauf prescription contraire du service SIG, le système de référence recommandé
pour les données métropolitaines est :
Élément Valeur
RGF93 /
Système
Lambert-93
Code EPSG 2154
6. Structure des données attributaires
6.1 Identifiant unique
Chaque couche doit comporter un champ d'identification unique et stable. Le nom
recommandé est OBJECT_ID
Cet identifiant :
• ne doit pas être vide ;
• ne doit pas contenir de doublon ;
• ne doit pas dépendre du numéro de ligne ou d'un identifiant interne
temporaire ;
• doit rester stable lors des mises à jour ;
• doit être utilisé pour les jointures et les échanges correctifs.
6.2 Noms des champs
Les noms de champs doivent respecter les règles suivantes :
• utiliser des lettres majuscules non accentuées, des chiffres et le caractère _ ;
• commencer par une lettre ;
• ne pas employer d'espace ;
• éviter les accents, apostrophes et caractères spéciaux ;
• utiliser des noms explicites et stables ;
• ne pas utiliser de mots réservés tels que DATE, USER, OBJECTID ou
SHAPE ;.
7. Symbologie et représentation cartographique
7.1 Principe général
La symbologie doit être transmise séparément des données afin de faciliter sa
reprise. Les styles intégrés à QGIS ne sont pas systématiquement compatibles avec
ArcGIS Pro.
Le livrable doit comprendre, selon les besoins :
Format Usage
.qml Style de couche QGIS
.sld Style d'échange standard, lorsque la symbologie est compatible
.lyrx Fichier de couche ArcGIS Pro
Format Usage
.stylx Bibliothèque de styles ArcGIS Pro
.pdf ou .png Rendu cartographique de référence
.qpt Modèle de mise en page QGIS, si utilisé
Lorsque le projet est produit dans QGIS, les fichiers .qml doivent être fournis pour
conserver la symbologie d'origine.
Si une reprise exacte dans ArcGIS Pro est exigée, il est recommandé de joindre
également un fichier .lyrx validé dans ArcGIS Pro.
Un « pack » de PNG/SVG peut également être fourni si une symbologie spécifique
développée en interne est utilisée (selon les droits)
8 Éléments à documenter
La documentation doit préciser :
• le champ utilisé pour la classification ;
• la méthode de classification ;
• les valeurs, classes et libellés ;
• les couleurs utilisées, de préférence en RVB ou en code hexadécimal ;
• les épaisseurs de traits ;
• les tailles de symboles ;
• les niveaux de transparence ;
• les règles d'affichage selon l'échelle ;
• les règles d'étiquetage ;
• les polices nécessaires ;
• l'ordre d'affichage des couches.
Lorsque la symbologie est complexe, un rendu PDF ou PNG constitue la référence
visuelle permettant de la reconstruire dans ArcGIS Pro.
9. Projet QGIS
Le projet QGIS doit être fourni au format .qgz.
Il doit respecter les règles suivantes :
• utiliser des chemins relatifs ;
• référencer uniquement des ressources présentes dans le livrable, sauf
exception documentée ;
• ne pas contenir de couche temporaire ou en mémoire ;
• ne pas dépendre d'un lecteur réseau propre au producteur ;
• ne pas faire appel à un dossier utilisateur local ;
• supprimer les couches cassées ou inutilisées ;
• organiser les couches dans des groupes explicites ;
• utiliser des noms de couches compréhensibles ;
• enregistrer une emprise et un système de coordonnées cohérents ;
• identifier les extensions indispensables au fonctionnement du projet.
10. Documentation attendue
10.1 Fichier README
Un fichier README.txt doit être placé à la racine du projet. Il doit contenir au
minimum :
Information Contenu attendu
Projet Nom et code du projet
Producteur Organisme, service et contact
Date Date de livraison
Version Numéro de version
Objet Description synthétique du livrable
Référence Jeu de données faisant foi
Projection Nom et code EPSG
Logiciel Logiciel et version utilisés
Information Contenu attendu
Contenu Liste des dossiers et fichiers principaux
Dépendances Polices, extensions, services ou ressources externes
Restrictions Conditions d'utilisation et éventuelles limites
Contrôles Vérifications réalisées avant transmission
10.2 Dictionnaire des données
Chaque couche doit disposer d'un dictionnaire décrivant sa structure attributaire.
Champ Description
Couche Nom de la couche concernée
Nom du champ Nom technique
Alias Libellé lisible
Type Texte, entier, décimal, date ou booléen
Longueur Longueur maximale
Obligatoire Oui ou non
Description Signification du champ
Valeurs autorisées Liste ou domaine de valeurs
Exemple Exemple de contenu
Source Origine de l'information
11. Données liées et ressources externes
Tous les fichiers indispensables au fonctionnement du projet doivent être inclus :
• images utilisées dans les mises en page ;
• logos ;
• icônes SVG/PNG ;
• bibliothèques de styles ;
• polices spécifiques, sous réserve des droits de diffusion ;
• fichiers de jointure ;
• documents associés ;
• modèles de mise en page ;
• scripts nécessaires ;
• fichiers de configuration autorisés.
Lorsqu'une donnée ne peut pas être intégrée au livrable en raison de sa taille, de sa
licence ou de sa confidentialité, elle doit être décrite dans le fichier README avec :
• son nom ;
• son emplacement ou URL ;
• son producteur ;
• sa version ou date ;
• ses conditions d'accès ;
• son rôle dans le projet.
Les services WMS, WMTS, WFS, Feature Service ou autres flux web doivent être
documentés
Texte extrait tel quel de la pièce officielle, qui seule fait foi. La mise en page du document d'origine peut différer.