Formats de données

Le choix des formats utilisés pour publier les données ouvertes sont une composante importante de l’accessibilité de l’information. .

Ce document vise à décrire les formats de données, ainsi que certaines bonnes pratiques à suivre pour le portail de données ouvertes de la Ville de Montréal. Les données antérieures à la publication de ce document (Février 2016) seront adaptées dans la mesure du possible tandis que les nouvelles données devront suivre ces recommandations à moins de contrainte technologique majeure.

Table des matières

Formats ouverts – une introduction #

Comme les données, les formats de données peuvent être catégorisés selon leur degré d’ouverture:

  • Ouvert: La spécification technique permettant de lire et de créer ce format est disponible publiquement et gratuitement permettant à n’importe qui de développer un outil utilisant ce format de données. Le format est également soumis à mécanisme de maintenance public et ouvert à la participation. Exemples: le HTML (géré par le W3C), JSON ou encore CSV.
  • Propriétaire: La spécification technique est disponible publiquement mais la maintenance et l’évolution est assurée par un unique propriétaire créant un risque de menottage technologique. Exemple: le format Shapefile (développé par ESRI) ou le PDF (développé par Adobe)
  • Fermé: La spécification technique n’est pas disponible, permettant seulement au créateur du format et à un nombre limité d’éditeurs de créer des logiciels adaptés à ce format.

Pour les données ouvertes, la Ville de Montréal privilégie les formats ouverts tout en supportant également quelques formats propriétaires réputés comme étant des standards de facto dans certains domaines, comme le format Shapefile pour les données géospatiales.

Accessibilité à tous #

Un des principes gouvernant l’ouverture des données est de rendre les données accessibles au plus grand nombre, critère ayant un impact sur le choix des formats. Tandis que les développeurs vont souvent demander des interfaces de programmation (API), ces dernières demandent des compétences en développement non accessible à la majorité des utilisateurs qui préférera un fichier de type tableau.

Continuum formats de données

Toutefois dans certaines situations, par exemple des données volumineuse ou en temps réel, il arrive que seule une approche plus complexe, comme une API, est la seule option disponible. Dans la démarche d’ouverture des données, il a été décidé de privilégier les utilisateurs ayant le moins de connaissance et optionnellement de supporter des besoins plus avancé. Sur le continuum ci-dessus, les usages à gauche sont prioritaires puisqu’ils représentent plus d’utilisateurs potentiels tout en permettant une évaluation automatisée des données.

Considérations générales #

Outre les règles identifiées précédemment et spécifiques aux différents formats, quelques règles générales sont à considérer.

Encodage #

Pour tous les formats de fichier sauvegardés sous forme de texte, l’encodage utilisé doit être l’UTF-8. Cet encodage de caractères informatiques développé par l’ISO est conçu pour respecter l’ensemble du répertoire universel de caractères codés. Dans le contexte québécois, UTF-8 permet de respecter les exigences du français intégral, c’est-à-dire l’ensemble des caractères propres à la langue française.

Si le fichier ne peut être enregistré en UTF-8, l’encodage utilisé doit être mentionné dans la fiche descriptive du jeu de données.

Nom des fichiers #

Des noms de fichier structurés et uniformes permet de mieux gérer les données tandis que le respect de certains règles assure que tous les outils peuvent accéder aux données, même ceux ne supportant, par exemple, les caractères accentués

Voici la structure de base recommandée pour nommer les fichiers :

préfixe-identifiant-suffixe.extension

(exemple : pv-villemarie-2013.csv)

Quelques critères à respecter:

  • Les seuls caractères acceptés sont les alphanumériques ainsi que le tiret “-”, le tiret souligné “_” et le point “.”
  • Aucun espace
  • Tout en minuscules
  • Aucuns signes diacritiques (accents et ponctuation). (par exemple: à, è, î)
  • Aucun caractère spécial (par exemple: ?&%*!|#… ¾)
  • Au besoin employer le format de date suivant : année-mois-jour pour faciliter le tri numérique.

Compression #

Les formats de compresseur (zip, gzip, rar) et les conteneurs (tar) doivent être évités car ils limitent la possibilité de prévisualiser les données sur le portail. Toutefois, voici quelques exceptions à prendre en considération :

  • Certains jeux sont accompagnés de plusieurs images. Dans ce cas précis, il est acceptable de compresser les fichiers au format ZIP.
  • Certains formats, tels que le Shapefile, sont standardisés sous un format compressé.

Format de certaines informations fréquentes #

Les jeux de données contiennent différents types d’information (texte, nombre, date, etc.) de manière récurrente. Selon le type d’information, certaines recommandations doivent être respectées pour assurer l’intégrité, simplifier l’interprétation et accroître l’interopérabilité.

Date et heure #

Lorsqu’une donnée représente une date ou une heure, elle doit être fournie selon la norme ISO8601. Voici les spécifications techniques :

  • Format de la date : AAAA-MM-JJ
  • Format de l’heure : HH:MM:SS
  • Lorsque la date et l’heure sont dans le même champ, on utilise la valeur « T » pour les séparer AAAA-MM-JJTHH:MM:SS. Au besoin, il est possible d’ajouter le fuseau horaire: 2016-02-01T16:46:07+00:00

Nombre #

Les particularités suivantes sont à prendre en considération:

    • Les valeurs décimales sont séparées par un point « . »;
    • Pas de séparateur de milliers;
    • L’unité est mentionner dans le dictionnaire de donnée et est omise dans le champ de valeur (par exemple pour un montant de 1 000$, la valeur dans le champ de données est 1000).

Booléen #

Il est proposé d’utiliser des valeurs simples et évidentes à interpréter. Par exemple, les combinaisons suivantes peuvent être retenues:

  • TRUE, FALSE;
  • 1, 0;

Valeurs inconnues ou non disponibles #

Peu importe la nature d’une donnée (date, heure, nombre, booléen, texte), lorsque la valeur n’est pas connue, quelle que soit la raison, il est fortement recommandé de laisser le champ vide plutôt que de mettre une valeur par défaut qui introduirait des erreurs d’interprétation.

Formats de données sélectionnés #

Les formats sélectionnés pour la publication des données dépendent des grandes catégories de données habituellement rencontrés. Sans prétendre à l’exhaustivité, la présente section couvre la majorité des types de données et formats correspondants présent sur le portail de données ouvertes de la Ville de Montréal.

Le tableau ci-dessous présente un récapitulatif tandis le sous-section à suivre détaillent chaque format.

Type de donnée Format obligatoire Format recommandé Format acceptable
Tabulaire CSV XLSX ODS
Géospatiale vectorielle CSV, GeoJSON Shapefile KML, KMZ, GML, WFS
Hiérarchique JSON XML
Géospatiale image (raster) GeoTiff WMS
3D / Dessin assisté
par ordinateur
CityGML DXF
Images** JPG, PNG, Tiff
Documents textuels** PDF, DOCX, ODT

** Type de fichier à éviter sur le portail de données ouvertes

Données tabulaires #

Les données tabulaires représentent la structure la plus fréquente et la plus simple à savoir des données pouvant être représentées sous forme d’un tableau simple comportant des lignes et des colonnes.

Comma separated value (CSV) – obligatoire #

Format ouvert de choix pour les données tabulaires, le CSV est supporté par la grande majorité des outils de traitement de données, allant des outils de tableur comme MS Excel aux bases de données et autres systèmes d’analyse.

La spécification du CSV est assez peu contraignante, rendant parfois difficile l’utilisation de ce format. Voici quelques règles à suivre pour assurer une comptabilité maximale de ce format avec les outils existants:

  • la première ligne du fichier désigne l’entête des colonnes;
  • les données débutent dès la seconde ligne;
  • les entêtes ne comportent pas de caractères accentués ni d’espace;
  • les éléments (colonnes) sont séparés par des virgules « , »;
  • les guillemets anglais « ” » sont utilisés pour délimiter les champs de texte;
  • chaque ligne contient le même nombre de champs que l’en-tête (pas de champ surnuméraire ou manquant)

Format dans le portail de données ouvertes : CSV

Office Open XML Spreadsheet (XLSX) – recommandé #

Le format propriétaire de tableur de la suite MS Office est recommandé dans la mesure où une large partie de la population dispose de MS Excel ou d’outils compatibles. Cette approche peut surtout être utile pour les ensembles de données peu volumineux (p.ex. moins de 10 000 lignes) où un tableur peut être suffisant pour comprendre l’information.

Lorsque le format XLSX est choisis comme format complémentaire, il est à prendre en considération que:

  • le fichier ne doit contenir aucun formatage;
  • la première ligne désigne l’entête des colonnes et les entêtes ne comportent pas de caractères accentués ni d’espace;
  • l’utilisation d’onglets doit être évitée;
  • l’utilisation de fonctions dynamiques doit être évitée;
  • la fusion de cellules est à proscrire.

Format dans le portail de données ouvertes : XLSX

Open document spreadsheet (ODS) – Acceptable #

Sous les mêmes conditions que pour le format XLSX, le format Open Document Spreadsheet peut être utilisé pour publier des données tabulaires.

Format dans le portail de données ouvertes : ODS

Données géospatiales vectorielles #

Les données géospatiales sont des données contenant une information géographique sous forme de coordonnées spatiales.

CSV – Obligatoire #

Si l’ensemble de données a également une structure tabulaire, ce qui est généralement le cas, la représentation CSV est obligatoire selon les règles du CSV listées plus haut auxquelles s’ajoutent les paramètres suivants:

  • Si l’information géospatiale représente uniquement des points:
    • une colonne latitude et une colonne longitude
  • Si l’information géospatiale n’est pas ponctuelle:
    • Pas de colonne pour l’information géospatiale ou
    • Une colonne géospatiale dont le contenu est au format Well Know Text (WKT), ou
    • Une colonne géospatiale dont le contenu est au format GeoJSON

Quelle que soit la représentation choisie, les positions spatiales doivent utiliser le système géodésique WGS84 (latitude et longitude tels qu’affichés par les GPS par exemple)

Format dans le portail de données ouvertes : CSV

GeoJSON – Obligatoire (en transition)#

GeoJSON est une extension géospatiale du format du format ouvert JavaScript Object Notation (JSON) très populaire dans le développement web et d’application. De ce fait, des nombreuses librairies techniques peuvent utiliser et produire ce format qui nécessite toutefois des connaissances en développement pour être utilisé.

Tout comme pour le format CSV, les positions spatiales doivent utiliser le système géodésique WGS84 (latitude et longitude tels qu’affichés par les GPS par exemple)

Note: pour l’heure plusieurs système ne sont pas en mesure des données au format GeoJSON, des travaux sont en cours pour mieux supporter ce format de données

Format dans le portail de données ouvertes : JSON

Shapefile – Recommandé #

Le format propriétaire Shapefile est supporté par la grande majorité des outils de géomatique et est devenu avec le temps un standard de facto pour les données géospatiales.

Le système géodésique est libre puisque la majorité des outils utilisant Shapefile sont capable de gérer différentes projections.

Format dans le portail de données ouvertes : SHP (bien que le format Shapefile soit généralement présenté sous forme d’un conteneur ZIP, l’utilisation du format SHP permet de faciliter la recherche).

Format dans le portail de données ouvertes : SHP

Autres formats acceptables

KML/KMZ #

Le format Keyhole Markup Language (KML) et sa version compressée (KMZ) sont utilisés par Google Maps et Earth pour les données géospatiales. Ces formats sont dont relativement facile à utiliser avec les produits Google mais demeurent limités.

Format dans le portail de données ouvertes : KML ou KMZ

GML #

Le format ouvert Geographical Markup Language (GML) développé par l’Open Geospatial Consortium est très riche mais aussi très complexe et mal supporté par plusieurs outils notamment depuis le passage de la version 2.0 à la version 3.0.

Format dans le portail de données ouvertes : GML

WFS #

Le format ouvert Web Service Feature (WFS) est un service web d’accès aux données géospatiales vectorielles, idéalement à utiliser en conjonction avec WMS

Format dans le portail de données ouvertes : WFS

Données hiérarchiques #

Les jeux de données hiérarchiques, c’est-à-dire ne pouvant pas être représentés sous forme d’un tableau simple, doivent être diffusés dans des formats permettant de reproduire les relations complexes entre les données.

Cette structure de données nécessite quasiment toujours des compétences en développement pour être utilisées. De ce fait, la structure hiérarchique est à éviter autant que possible ou comme approche complémentaire à des données tabulaires.

Plusieurs stratégies sont possibles pour transformer des données hiérarchiques en données tabulaires:

  • Scinder un unique fichier en plusieurs fichiers avec des relations, à l’image des tables de base de données
  • Ajouter certaines dimensions hiérarchiques sous forme de nouvelles dimensions tabulaire, ce qui a généralement pour effet d’augmenter de nombre de lignes.

Si l’approche hiérarchique s’avère tout de même la plus pertinente, deux représentations sont disponibles.

Javascript Object Notation (JSON) – Obligatoire #

JavaScript Object Notation (JSON) désigne une structure de données permettant de représenter des données hiérarchiques. Dans le contexte du portail de données ouvertes, le format JSON est recommandé puisqu’il est destiné à représenter de l’information brute et structurée, il est simple à interpréter et facile à intégrer pour la majorité des langages de programmation. Il est particulièrement indiqué pour les développements Web et d’applications mobiles.

Format dans le portail de données ouvertes : JSON

eXtensible Markup Language (XML) – Acceptable #

Extensible Markup Language (XML) est un langage informatique de balisage dont l’objectif est le stockage et l’échange de contenu complexe. Par son extensibilité, le XML est également très flexible mais est moins bien supporté que le JSON pour les usages Web et d’applications mobiles.

Format dans le portail de données ouvertes : XML

Données géospatiales raster (images) #

GeoTIFF – Obligatoire #

Le format GeoTIFF est une extension géospatiale du format d’image Tagged Image File Format permettant d’inclure la référence spatiale et la projection geospatiale de l’image, le tout permettant donc de “tuiler” plusieurs images pour représenter des régions.

Format dans le portail de données ouvertes : TIFF

WMS – Recommandé #

Le Web Map Service (WMS) est un service web permettant d’accéder dynamiquement à des images raster, utilisé par la majorité des outils de géomatique.

Format dans le portail de données ouvertes : WMS

Autres formats acceptables #

CityGML #

Le CityGML est un format ouvert permettant la représentation d’informations 3D notamment pour représenter des constructions. C’est une extension du format GML

Format dans le portail de données ouvertes : GML

DXF #

Le format Drawing Exchange Format est un format propriétaire de représentation 3D développé par Autodesk et utilisé par de nombreux outils de dessin assisté par ordinateur.

Format dans le portail de données ouvertes : DXF

Images: JPG, PNG, TIFF #

De manière générale, les images ne sont pas considérées comme des données et n’ont pas nécessairement leur place sur un portail de données ouvertes. Une approche pour publier des données ouvertes concernant des photos ou des images est de publier un fichier tabulaire contenant une liste d’images ou de photos avec leurs attributs (p.ex date, lieu, etc.) et un lien (URL) vers l’image.

S’il est nécessaire de publier des images sur le portail, les formats JPG, PNG et TIFF sont acceptables.

Documents textuels: PDF, DOCX et ODT #

De manière générale, les documents textuels ne sont pas considérés comme des données et n’ont pas nécessairement leur place sur un portail de données ouvertes. Pour des raisons historiques, le portail de données ouvertes sert à rendre disponibles des comptes-rendus et des rapports. De manière générale, cette approche est à éviter, mais si de tels fichiers textuelles sont considérés pertinents, il peuvent être proposé dans différents formats.

  • PDF est un format propriétaire non modifiable pouvant être utilisé dans la mesure où le fichier est chapitré et est accessible
  • Open Office XML Word processing (DOCX) est un format propriétaire largement supporté par les éditeurs de texte
  • Open Document Text (ODT) est format ouvert supporté par plusieurs éditeurs de texte.

Interfaces programmables #

Dans certains cas, soit à cause de la nature même des données, soit pour faciliter le travail des utilisateurs de données, une interface programmable (API) peut être développée pour rendre les données disponibles. Voici quelques recommandations sur les API publiques:

  • L’API ne doit pas être le seul moyen d’accéder à la donnée. Des données sous forme fichier doivent être disponibles en plus de l’API.
  • Favoriser la représentation JSON plutôt que XML
  • Favoriser un paradigme connu, idéalement REST, permettant aux utilisateurs de facilement comprendre la structure d’information et la dynamique d’échange
  • Si possible, ne pas mettre de clé d’accès à l’API. Si pour des raisons de performance une clé est nécessaire (limitation du volume de demande), il faut mettre en place un mécanisme pour rejoindre les utilisateurs