Commit 6ff33d3d authored by Christophe Benz's avatar Christophe Benz
Browse files

Update CI: do not commit generated files, generate them for each pipeline

parent 70c3ff4e
Pipeline #1229 passed with stages
in 1 minute and 48 seconds
stages:
- build_docker_image
- generate
- commit
- build
- deploy
variables:
CI_DOCKER_IMAGE: $CI_REGISTRY_IMAGE:latest
CI_REPOSITORY_SSH_USER: git
CI_REPOSITORY_DOMAIN: git.opendatafrance.net
CI_REPOSITORY_SSH_URL: ${CI_REPOSITORY_SSH_USER}@${CI_REPOSITORY_DOMAIN}:${CI_PROJECT_PATH}.git
LC_ALL: fr_FR.UTF-8
PDF_FILE: Socle Commun des Données Locales.pdf
TZ: Europe/Paris
......@@ -21,9 +16,6 @@ Build Docker image:
- Dockerfile.ci
refs:
- master
except:
variables:
- $GENERATE_ASSETS
image: docker:stable
services:
- docker:dind
......@@ -33,61 +25,35 @@ Build Docker image:
before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
script:
- docker build -t $CI_DOCKER_IMAGE -f Dockerfile.ci .
- docker push $CI_DOCKER_IMAGE
- docker build -t $CI_REGISTRY_IMAGE:latest -f Dockerfile.ci .
- docker push $CI_REGISTRY_IMAGE:latest
tags:
- docker-privileged
Generate assets:
Generate files:
stage: generate
only:
variables:
- $GENERATE_ASSETS
image: $CI_DOCKER_IMAGE
image: $CI_REGISTRY_IMAGE:latest
variables:
CATALOG_URL: https://git.opendatafrance.net/scdl/catalog/raw/master/catalog.json
CONTRIBUTING_MD_URL: https://git.opendatafrance.net/scdl/catalog/raw/master/CONTRIBUTING.md
before_script:
- pip3 install --requirement requirements.txt
script:
- wget "$CONTRIBUTING_MD_URL"
- mkdir schemas templates
- python3 ./scripts/generate_assets_from_schema_catalog.py "$CATALOG_URL" schemas templates
- python3 ./scripts/generate_files_from_schema_catalog.py "$CATALOG_URL" schemas templates
docs.template/SUMMARY.j2 SUMMARY.md
artifacts:
name: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
paths:
- CONTRIBUTING.md
- SUMMARY.md
- schemas/
- templates/
Commit generated assets:
stage: commit
only:
variables:
- $GENERATE_ASSETS
image: $CI_DOCKER_IMAGE
before_script:
- eval $(ssh-agent -s)
- ssh-add <(echo "$COMMIT_SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- ssh-keyscan -t rsa $CI_REPOSITORY_DOMAIN >> ~/.ssh/known_hosts
- git config --global user.name "GitLab Continuous Integration"
- git config --global user.email "<>"
script:
- git clone --branch $CI_COMMIT_REF_NAME $CI_REPOSITORY_SSH_URL
- rm -rf $CI_PROJECT_NAME/docs/schemas $CI_PROJECT_NAME/docs/templates
- mv SUMMARY.md schemas templates $CI_PROJECT_NAME/docs/
- cp $CI_PROJECT_NAME/docs.template/schemas/README.md $CI_PROJECT_NAME/docs/schemas
- cd $CI_PROJECT_NAME
- git add -A
- git commit -m "Update generated assets" || true
- git push
Build Gitbook:
stage: build
except:
variables:
- $GENERATE_ASSETS
image: $CI_DOCKER_IMAGE
image: $CI_REGISTRY_IMAGE:latest
script:
- ./scripts/build_gitbook.sh
artifacts:
......@@ -98,19 +64,16 @@ Build Gitbook:
Deploy Gitbook:
stage: deploy
except:
variables:
- $GENERATE_ASSETS
only:
- master
image: $CI_DOCKER_IMAGE
image: $CI_REGISTRY_IMAGE:latest
variables:
SERVER_DIRECTORY: scdl-documentation-static
SERVER_HOST: scdl.opendatafrance.net
SERVER_USER: validata
before_script:
- eval $(ssh-agent -s)
- ssh-add <(echo "$DEPLOY_SSH_PRIVATE_KEY")
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- ssh-keyscan -t rsa $SERVER_HOST >> ~/.ssh/known_hosts
script:
......
......@@ -5,5 +5,6 @@
{%- for schema in schemas %}
- [{{ schema.title }}](schemas/{{ schema.name }}.md)
{%- endfor %}
- [Télécharger en PDF](télécharger.md)
- [Badge Validata](badge.md)
\ No newline at end of file
- [Contribuer au SCDL](CONTRIBUTING.md)
- [Badge Validata](badge.md)
- [Télécharger en PDF](télécharger.md)
\ No newline at end of file
# Comment contribuer au Socle commun des données locales (SCDL) ?
Tous les schémas du SCDL sont référencés dans le [Catalogue des schémas SCDL](https://git.opendatafrance.net/scdl/catalog/).
L'ajout d'un schéma au catalogue se fait en proposant d'amender le fichier [catalog.json](https://git.opendatafrance.net/scdl/catalog/blob/master/catalog.json) sous forme de _merge request_.
## Critères d'acceptation
[OpenDataFrance](http://opendatafrance.net/) se réserve le droit d'accepter ou de refuser l'ajout d'un schéma au sein du SCDL.
Pour candidater, un schéma doit :
- être écrit en JSON conformément aux spécifications [Table Schema](https://frictionlessdata.io/specs/table-schema/). Les métadonnées du schéma doivent employer [les propriétés qui ont été standardisées](https://github.com/frictionlessdata/specs/blob/master/specs/patterns.md#table-schema-metadata-properties), avec au minimum :
- `name` : identifiant, ou "slug" ;
- `title` : nom courant ;
- `description` ;
- `homepage` : page d'accueil ou dépôt Git ;
- `path` : URL de cette version du schéma ;
- `created` : date de création ;
- `lastModified` : date de publication de cette version ;
- `version` : le numéro de version au format [SemVer](https://semver.org/lang/fr/) ;
- être nommé `schema.json` ;
- être accompagné d'un fichier `README.md` complet, présentant notamment le contexte de sa création ;
- être mis à disposition en ligne sur une URL stable.
Optionnel :
- être mis à disposition dans un dépôt Git afin de bénéficier de la gestion des versions (voir ci-dessous) ;
- un fichier `CHANGELOG.md` peut être publié au même endroit que le fichier `schema.json` afin d'apporter des informations sur les différentes mises à jour du schéma ;
- des données tabulaires d'exemple sous forme de fichiers CSV, valides ou invalides, peuvent également être ajoutées dans un dossier séparé (et référencées dans le schéma grâce à la propriété `resources`).
## Cycle de vie d'un schéma SCDL
### Contribution
Concerne la création initiale ou la mise à jour d'un schéma.
Une contribution se fait toujours dans une branche, la branche `master` étant protégée. Plusieurs branches peuvent coexister lorsque différentes évolutions n'ont pas la même nature.
Lorsqu'un changement est cassant, penser à mettre à jour le fichier d'exemple valide pour qu'il reste valide.
Le contributeur ne doit pas nécessairement mettre à jour `CHANGELOG.md` ni le numéro de version dans `schema.json` (à faire lors de l'intégration et de la publication).
Lorsque le contributeur n'est pas membre de l'équipe, il travaillera dans un fork du dépôt du schéma.
Lorsqu'une branche est prête à être proposée, le contributeur ouvre une _merge request_.
### Intégration
Concerne la revue et l'acceptation des changements proposés par un contributeur.
L'intégrateur est celui qui a les droits d'écriture sur la branche `master`. Après vérification de la _merge request_, il peut fusionner la branche dans `master`. Ainsi `master` accumule un certain nombre de modifications par rapport à la dernière version publiée.
Conséquence : le fichier `catalog.json` ne doit pas référencer les schémas depuis `master` mais depuis des URLs contenant un _tag_ (cf ci-dessous).
L'intégrateur doit tenir à jour une section prévisionnelle dans le `CHANGELOG.md` de type "X.Y.Z -> next" où "X.Y.Z" est la dernière version publiée et "next" est un marqueur qui sera remplacé par le nouveau numéro de version lors de la publication. Cette section doit être placée tout en haut du fichier (le plus récent en premier).
### Publication d'une version ("release")
Cette dernière étape consiste à rendre visibles et utilisables, notamment sur Validata, les changements accumulés dans `master` depuis la dernière version publiée. Il s'agit de figer, à un instant _t_ et dans un ensemble cohérent, tous les fichiers du dépôt du schéma (schéma, documentation, fichiers exemples, etc.).
Les schémas SCDL suivent le principe du [_semantic versioning_](https://semver.org/lang/fr/).
L'objectif est d'attribuer un nouveau numéro de version au schéma. Pour cela :
- déterminer si l'ensemble des modifications depuis la version précédente est rétrocompatible ou non ("cassant")
- mettre à jour le numéro de version en conséquence (majeur, mineur ou patch) dans `schema.json`:
- `version`
- `lastModified` : date de mise à jour
- `path` et `resources` : mise à jour de l'URL avec le bon _tag_ de version
- ajouter ou modifier l'entrée dans le `CHANGELOG.md` (le plus récent en haut) qui décrit les changements rétrocompatibles et non-rétrocompatibles dans 2 listes séparées ([exemple](https://git.opendatafrance.net/scdl/adresses/blob/v1.1.2/CHANGELOG.md)
- faire un _commit_ de _release_ qui ne contienne que les 2 points précédents, dont le message est "Version X.Y.Z" (remplacer X.Y.Z)
- _tagger_ ce _commit_ avec `vX.Y.Z` (remplacer X.Y.Z)
- _pusher_ 2 fois : `git push origin master` et `git push --tags`
- [Socle Commun des Données Locales](README.md)
- [Recommandations relatives aux jeux de données](recommandations-relatives-aux-jeux-de-donnees.md)
- [Recommandations relatives aux schémas de validation](recommandations-relatives-aux-schemas-de-validation.md)
- [Schémas du SCDL](schemas/README.md)
- [Base adresse locale](schemas/adresses.md)
- [Catalogue simplifié](schemas/catalogue.md)
- [Délibérations](schemas/deliberations.md)
- [Équipements](schemas/equipements.md)
- [Infrastructures de recharge pour véhicules électriques](schemas/irve.md)
- [Marchés publics](schemas/marches-publics.md)
- [Subventions](schemas/subventions.md)
- [Télécharger en PDF](télécharger.md)
- [Badge Validata](badge.md)
\ No newline at end of file
# Base adresse locale
Spécification du modèle de données relatif aux adresses locales d’une collectivité (BAL)
## Contexte
En France, la création des voies et des adresses est une compétence exercée par les communes et s'appuie sur des décisions prises par les conseils municipaux. La mise en oeuvre de cette compétence peut néanmoins être déléguée à un [Etablissement Public de Coopération Intercommunale](https://fr.wikipedia.org/wiki/%C3%89tablissement_public_de_coop%C3%A9ration_intercommunale) (EPCI). Le regroupement de tout ou partie des adresses d’une collectivité dans une base de données permet d'outiller la gestion et la publication de cette ressource.
En 2016, dans le cadre du [groupe de travail "SIG et Topographie"](http://www.aitf.fr/groupe-travail/sig-topographie) rassemblant des ingénieurs territoriaux de différentes collectivités locales, l’Association des Ingénieurs Territoriaux de France (AITF) a défini un modèle d'échange de données entre les bases voie-adresse gérées localement et la Base Adresse Nationale (BAN). En l'absence d'un cadre réglementaire précis, cette spécification d'un modèle de données simple applicable à une Base Adresse Locale (BAL) permet de standardiser la publication en open data des adresses d'une collectivité.
La spécification SCDL du modèle de données relatif aux adresses locales d’une collectivité a donc été élaborée à partir de la proposition d’un [modèle de données simple visant à alimenter la BAN par des fichiers](https://cms.geobretagne.fr/sites/default/files/documents/aitf-sig-topo-adresse-fichier-echange-simplifie-v_1.1_0.pdf) de l'AITF. Si nécessaire, elle sera mise à jour, adaptée et consolidée à partir de cette même source.
#### Avertissement !
L'utilisation de cette spécification requiert de prêter une attention toute particulière aux points suivants :
* Contrairement aux recommandations applicables à toutes les spécifications SCDL, le modèle de l'AITF prévoit que le séparateur de colonnes du fichier tabulaire doit être le point-virgule et pas la virgule.
* De même, les règles de nommage sont légèrement différentes : le nom du fichier comporte la date de création du jeu de données, la désignation du producteur et son code SIREN. Le tout sans espace ni accent et en minuscules, soit : AAAAMMJJ\_producteur\_siren.csv. Exemple : '20151004\_rennes\_213502388.csv'
## Voir aussi
La spécification du modèle de données peut être utilement complétée par les documents suivants :
* [Fichier gabarit à télécharger au format xlsx](https://scdl.opendatafrance.net/docs/templates/scdl-adresses.xlsx)
* [Schéma de validation](https://git.opendatafrance.net/scdl/adresses/blob/master/schema.json)
Pour faciliter la production et améliorer la qualité des données au format Base Adresse Locale, la mission Etalab de la DINSIC, met à disposition des outils dédiés sur le portail adresse.data.gouv.fr :
* [Le validateur BAL](https://adresse.data.gouv.fr/bases-locales/validateur) permet de vérifier la conformité d'un fichier BAL
* [L'éditeur BAL](https://adresse.data.gouv.fr/bases-locales/editeur) permet de créer et/ou de modifier un fichier BAL
Les sources de ces outils sont disponibles sur le [dépôt Github de la mission Etalab](https://github.com/etalab/adresse.data.gouv.fr).
Pour poser une question, commenter, faire un retour d’usage ou contribuer à l’amélioration du modèle de données, vous pouvez :
* adresser un message à [scdl@opendatafrance.email](mailto:scdl@opendatafrance.email?subject=Base%20Adresse%20Locale)
* ouvrir un ticket sur le [dépôt GitLab d’OpenDataFrance](https://git.opendatafrance.net/scdl/adresses/issues)
## Carte d'identité du schéma
- nom : adresses
- page d'accueil : https://git.opendatafrance.net/scdl/adresses
- URL du schéma : https://git.opendatafrance.net/scdl/adresses/raw/v1.1.4/schema.json
- version : 1.1.4
- date de création : 30/05/2018
- date de dernière modification : 27/06/2019
- concerne le pays : FR
- valeurs manquantes représentées par : `[""]`
- contributeurs :
- OpenDataFrance (auteur)
- ressources :
- Exemple de fichier adresses invalide ([lien](https://git.opendatafrance.net/scdl/adresses/raw/v1.1.4/exemples/exemple_invalide.csv))
## Modèle de données
Ce modèle de données repose sur les 13 champs suivants correspondant aux colonnes du fichier tabulaire.
### `cle_interop`
- titre : Clé d'interopérabilité
- description : Cette clé combine le [code INSEE de la commune](https://fr.wikipedia.org/wiki/Code_Insee) sur 5 caractères (incluant 'A' ou 'B' pour la Corse) + le code de voie issu du [FANTOIR](https://fr.wikipedia.org/wiki/FANTOIR) de la DGFiP sur 4 caractères + le numéro d’adresse sur 5 caractères préfixé par des zéros + un suffixe s'il existe, qui peut être un indice de répétition ('bis', 'ter', 'qua', 'qui', etc... codés sur 3 caractères) et/ou un complément ('a', 'b', 'c', 'a1', 'b2', 'lesmimosas', etc... sans limitation du nombre de caractères). Chaque élément est séparé par un tiret du bas et les lettres sont en minuscule.
- type : chaîne de caractères
- exemple : `35238_3961_00007_bis`
- valeur obligatoire
- taille minimale : 16
- motif : `^[A-Za-z0-9_]+$`
### `uid_adresse`
- titre : Identifiant unique national d’adresse
- description : Cet identifiant unique d’adresse est géré et attribué par le service "guichet national d’identification" de la Base Adresse Nationale. Dans l'attente de la mise en place de ce service, les règles de création ou de gestion de cet identifiant ne sont pas connues. La valeur de ce champ est donc optionnelle et sera laissée vide aussi longtemps que le service d'identification ne sera pas opérationnel.
- type : chaîne de caractères (uuid)
- valeur optionnelle
### `voie_nom`
- titre : Nom complet de la voie
- description : Ce champ contient la concaténation du type et du nom de la voie ou le nom d'un lieu-dit, exprimés en majuscules et minuscules accentuées.
- type : chaîne de caractères
- exemple : `'Allée de Bréhat' pour une concaténation ou 'Le pré aux grenouilles' pour un lieu-dit`
- valeur obligatoire
- taille minimale : 3
- motif : `^[a-zA-Z0-9\-\'\s\d\u00C0-\u00FF]+$`
### `numero`
- titre : Numéro d’adresse
- description : Numéro d’adresse dans la voie et, dans le cas des voies sans adresse, la valeur “99999” est attendue
- type : nombre entier
- exemple : `130`
- valeur obligatoire
- valeur maximale : 99 999
### `suffixe`
- titre : Information suffixée qui complète et précise le numéro d’adresse
- description : Cette information peut être un indice de répétition ('bis', 'ter', 'qua', 'qui', etc... codés sur 3 caractères en minuscules) ou un complément comme le nom d'entrée d'immeuble ('a', 'b', 'c', 'a1', 'b2', 'lesmimosas', etc... codés en minuscules non accentuées, sans espace ni limite du nombre de caractères).
- type : chaîne de caractères
- exemple : `'ter' pour un indice de répétition ou 'lesmimosas' pour un nom d'entrée d'immeuble`
- valeur optionnelle
- motif : `^[a-z\d\u00DF-\u00FF]+$`
### `commune_nom`
- titre : Nom officiel de la commune
- description : Ce champ doit permettre d’identifier rapidement le territoire concerné et d'éviter les quiproquos.
- type : chaîne de caractères
- exemple : `Brest`
- valeur obligatoire
- motif : `^[A-Za-z\s\-\u00C0-\u00FF]+$`
### `position`
- titre : Code de position de l’adresse
- description : Ce code décrit la position d’une adresse à partir d’une liste de valeurs qui provient de la spécification INSPIRE v 3.1 sur le thème "Adresses". Les valeurs attendues sont, au choix, 'délivrance postale', 'entrée', 'bâtiment', 'cage d’escalier', 'logement', 'parcelle', 'segment', ou 'service technique'.
- type : chaîne de caractères
- exemple : `cage d’escalier`
- valeur obligatoire
- valeurs autorisées : `["délivrance postale","entrée","bâtiment","cage d’escalier","logement","parcelle","segment","service technique"]`
### `x`
- titre : Coordonnée X
- description : Coordonnée X du système légal en vigueur sur le territoire concerné, conformément à l’article 1 du [décret n° 2006-272](https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT000000813996) du 3 mars 2006. Le signe de séparation entre les parties entière et décimale du nombre est le point.
- type : nombre réel
- exemple : `145377.5`
- valeur optionnelle
### `y`
- titre : Coordonnée Y
- description : Coordonnée Y du système légal en vigueur sur le territoire concerné, conformément à l’article 1 du [décret n° 2006-272](https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT000000813996) du 3 mars 2006. Le signe de séparation entre les parties entière et décimale du nombre est le point.
- type : nombre réel
- exemple : `6835665.67`
- valeur optionnelle
### `long`
- titre : Longitude
- description : Coordonnée de longitude exprimée en [WGS 84](https://fr.wikipedia.org/wiki/WGS_84). Le signe de séparation entre les parties entière et décimale du nombre est le point.
- type : nombre réel
- exemple : `-4.502217943385534`
- valeur optionnelle
### `lat`
- titre : Latitude
- description : Coordonnée de latitude exprimée en [WGS 84](https://fr.wikipedia.org/wiki/WGS_84). Le signe de séparation entre les parties entière et décimale du nombre est le point.
- type : nombre réel
- exemple : `48.383985827041485`
- valeur optionnelle
### `source`
- titre : Nom de la source
- description : Ce nom peut désigner, au choix, la collectivité ayant créé juridiquement l’adresse (par délibération), l'entité ayant créé la donnée, ou l’entité ayant diffusé / publié la donnée.
- type : chaîne de caractères
- exemple : `Rennes Métropole`
- valeur obligatoire
- motif : `[a-zA-Z0-9\-\d\s\u00C0-\u00FF]+`
### `date_der_maj`
- titre : Date de dernière mise à jour
- description : Cette date est celle de la dernière mise à jour connue de la donnée. Elle ne correspond pas à la date de publication du jeu de données en open data. Elle est exprimée au format AAAA-MM-JJ suivant la norme internationale [ISO 8601](https://fr.wikipedia.org/wiki/ISO_8601).
- type : date
- exemple : `2014-10-01`
- valeur obligatoire
# Catalogue simplifié
Spécification du modèle de données relatif au catalogue des jeux de données publiés en open data par une collectivité
## Contexte
Le catalogue opendata d'une collectivité rassemble les métadonnées de description des jeux de données qu'elle publie. Il peut être généré automatiquement par la plateforme qui les héberge ou qui les moissonne. Plusieurs standards permettent de normaliser les métadonnées d'un catalogue \(INSPIRE pour les données géographiques, DCAT et ses déclinaisons pour tout type de données ouvertes\), mais les catalogues locaux, lorsqu'ils existent, qu'ils soient exposés via une API ou extraits sous forme de fichiers, dépendent souvent de la capacité technique de la solution utilisée et de son paramétrage \(formats différents, plus ou moins riches ou étendus, en fonction de la plateforme, catalogue unique et pas pour chaque producteur quand la plateforme est mutualisée, distinction ou non entre jeux de données et ressources, etc\). Sans compter que de nombreuses collectivités utilisent de simples sites web pour mettre à disposition leurs données.
La spécification d'un modèle de données simplifié doit permettre d'harmoniser ces catalogues locaux dans un format accessible à toutes les collectivités et faciliter leur consolidation dans un inventaire national, le "catalogue des catalogues des données locales ouvertes".
Cette spécification a été élaborée à partir des sources suivantes :
* [Guide de saisie des éléments de métadonnées INSPIRE](http://cnig.gouv.fr/wp-content/uploads/2014/01/Guide-de-saisie-des-%C3%A9l%C3%A9ments-de-m%C3%A9tadonn%C3%A9es-INSPIRE-v1.1-final-light.pdf) - Recommandation du Conseil National de l'Information Géographique \(2013\)
* [Guide de mise en oeuvre du schéma DCAT-AP](https://docs.google.com/document/d/1qMDqBjrTJVu3t9RH94aLSW7Z3jhH1SjoBrWhW9PZkJ4/) rédigé par Pascal Romain du Département de la Gironde pour OpenDataFrance à partir du draft final de la spécification de la Commission Européenne \(2014\)
* [Data Catalog Vocabulary \(DCAT\)](https://www.w3.org/TR/vocab-dcat/) - Recommandation W3C relative au vocabulaire des catalogues de données publiés sur le web \(2014\)
* [DCAT Application Profile for data portals in Europe](https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/releases) \([DCAT-AP v1.1](https://github.com/SEMICeu/DCAT-AP/raw/master/releases/1.1/dcat-ap_1.1.pdf) en 2015 et [DCAT-AP v1.2](https://joinup.ec.europa.eu/sites/default/files/distribution/access_url/2018-11/014bde52-eb3c-4060-8c3c-fcd0dfc07a8a/DCAT_AP_1.2.pdf) en 2018\) - Spécification de la Commission Européenne, basée sur le vocabulaire DCAT, visant à décrire les jeux de données du secteur public en Europe, également disponible sur le [dépôt Github de l'initiative SEMICeu](https://github.com/SEMICeu/DCAT-AP)
## Voir aussi
La spécification du modèle de données peut être utilement complétée par les documents suivants :
* [Fichier gabarit à télécharger au format xlsx](https://scdl.opendatafrance.net/docs/templates/scdl-catalogue.xlsx)
* [Schéma de validation](https://git.opendatafrance.net/scdl/catalogue/blob/master/schema.json)
Pour poser une question, commenter, faire un retour d’usage ou contribuer à l’amélioration du modèle de données, vous pouvez :
* adresser un message à [scdl@opendatafrance.email](mailto:scdl@opendatafrance.email?subject=Catalogue%20simplifié)
* ouvrir un ticket sur le [dépôt GitLab d’OpenDataFrance](https://git.opendatafrance.net/scdl/catalogue/issues/new)
## Carte d'identité du schéma
- nom : catalogue
- page d'accueil : https://git.opendatafrance.net/scdl/catalogue
- URL du schéma : https://git.opendatafrance.net/scdl/catalogue/raw/v0.1.2/schema.json
- version : 0.1.2
- date de création : 20/11/2018
- date de dernière modification : 28/06/2019
- valeurs manquantes représentées par : `[""]`
- contributeurs :
- OpenDataFrance (auteur)
- Thomas Bekkers (contributeur)
## Modèle de données
Ce modèle de données repose sur les 20 champs suivants correspondant aux colonnes du fichier tabulaire.
### `COLL_NOM`
- titre : Nom de la collectivité
- description : Nom officiel de la collectivité qui publie le catalogue simplifié de jeux de données limité à 140 caractères maximum.
- type : chaîne de caractères
- exemple : `Rennes Métropole`
- valeur obligatoire
### `COLL_SIRET`
- titre : Code SIRET de la collectivité
- description : Identifiant du [Système d'Identification du Répertoire des Etablissements](https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27identification_du_r%C3%A9pertoire_des_%C3%A9tablissements) (SIRET) de la collectivité qui publie le catalogue simplifié de jeux de données, composé de 9 chiffres SIREN + 5 chiffres NIC d’un seul tenant.
- type : chaîne de caractères
- exemple : `24350013900189`
- valeur obligatoire
- motif : `^\d{14}$`
### `ID`
- titre : Identifiant du jeu de donnée
- description : Cet identifiant est une chaîne de caractères qui correspond soit au nom du jeu de données, exprimé en minuscules sans accent ni espace (identifiant texte ou 'slug'), soit à un code d'identification généré automatiquement (identifiant machine ou 'hash').
- type : chaîne de caractères
- exemple : `prenoms-des-nouveaux-nes-a-rennes-en-2017 ou 53699116a3a729239d203b7f`
- valeur obligatoire
### `TITRE`
- titre : Titre du jeu de données
- description : Ce titre doit être un intitulé caractéristique et univoque permettant de désigner le jeu de données. Il est recommandé d'y faire figurer une indication de la zone géographique couverte et, lorsqu'elle se justifie, une indication de version ou de millésime.
- type : chaîne de caractères
- exemple : `Prénoms des nouveaux-nés à Rennes en 2017`
- valeur obligatoire
### `DESCRIPTION`
- titre : Description du jeu de données
- description : Cette description doit fournir un bref résumé narratif du contenu du jeu de données, rédigé de façon compréhensible pour l’utilisateur.
- type : chaîne de caractères
- exemple : `Liste annuelle des prénoms des nouveaux-nés enregistrés à l'état-civil de la ville de Rennes pour l'année 2017.`
- valeur obligatoire
### `THEME`
- titre : Thème du jeu de données
- description : En l'absence d'une nomenclature de classement par thèmes satisfaisante et adaptée au contexte local, le thème est exprimé sous la forme d'une chaîne de caractères libre dans la limite de 140 caractères maximum. Le manque de pertinence du [thésaurus EuroVoc](https://publications.europa.eu/fr/web/eu-vocabularies/th-dataset/-/resource/dataset/eurovoc) ou des [thèmes INSPIRE](https://inspire.ec.europa.eu/Themes/Data%20Specifications/2892) implique d'élaborer collectivement une [nomenclature spécifique](https://docs.google.com/document/d/1oDJsHw3bmABfto6HPgCPG1ztrV3CihuHjcfU8tQpvPc/) à partir d'un appariement des termes les plus utilisés sur les plateformes territoriales de données ouvertes.
- type : chaîne de caractères
- exemple : `Administration locale`
- valeur obligatoire
### `PRODUCTEUR_NOM`
- titre : Nom du producteur
- description : Nom officiel ou raison sociale du producteur du jeu de données limité à 140 caractères maximum.
- type : chaîne de caractères
- exemple : `Ville de Rennes`
- valeur obligatoire
### `PRODUCTEUR_SIRET`
- titre : Code SIRET du producteur
- description : Identifiant du [Système d'Identification du Répertoire des Etablissements](https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27identification_du_r%C3%A9pertoire_des_%C3%A9tablissements) (SIRET) du producteur du jeu de données, composé de 9 chiffres SIREN + 5 chiffres NIC d’un seul tenant.
- type : chaîne de caractères
- exemple : `21350238800019`
- valeur obligatoire
- motif : `^\d{14}$`
### `COUV_SPAT_MAILLE`
- titre : Maille de couverture spatiale
- description : La maille de couverture spatiale correspond à l'echelle territoriale que couvre le jeu de données. Pour simplifier le renseignement de ce champ, elle est désignée en choisissant une valeur parmi une liste pré-établie de valeurs possibles : 'Infracommunale', 'Communale', 'Intercommunale', 'Cantonale', 'Départementale', 'Régionale' ou 'Autre'.
- type : chaîne de caractères
- exemple : `Communale`
- valeur obligatoire
- valeurs autorisées : `["Infracommunale","Communale","Intercommunale","Cantonale","Départementale","Régionale","Autre"]`
### `COUV_SPAT_NOM`
- titre : Nom de couverture spatiale
- description : Le nom de couverture spatiale correspond au nom de l'échelle territoriale que couvre le jeu de données. Il est exprimé sous la forme d'une chaîne de caractères limitée à 140 caractères maximum.
- type : chaîne de caractères
- exemple : `Rennes`
- valeur obligatoire
### `COUV_TEMP_DEBUT`
- titre : Date de début de la couverture temporelle
- description : La couverture temporelle correspond à la période que couvre le jeu de données. Cette période est un intervalle entre deux dates. La date de début est donc le premier terme utilisé pour désigner cet intervalle, exprimé au format AAAA-MM-JJ suivant la norme internationale [ISO 8601](https://fr.wikipedia.org/wiki/ISO_8601).
- type : date
- exemple : `2017-01-01`
- valeur obligatoire
### `COUV_TEMP_FIN`
- titre : Date de fin de la couverture temporelle
- description : La couverture temporelle correspond à la période que couvre le jeu de données. Cette période est un intervalle entre deux dates. La date de fin est donc le second terme utilisé pour désigner cet intervalle, exprimé au format AAAA-MM-JJ suivant la norme internationale [ISO 8601](https://fr.wikipedia.org/wiki/ISO_8601).
- type : date
- exemple : `2017-12-31`
- valeur obligatoire
### `DATE_PUBL`
- titre : Date de la première publication
- description : Date de la publication initiale du contenu du jeu de données. Elle est exprimée au format AAAA-MM-JJ suivant la norme internationale [ISO 8601](https://fr.wikipedia.org/wiki/ISO_8601).
- type : date
- exemple : `2017-06-01`
- valeur obligatoire
### `FREQ_MAJ`
- titre : Fréquence de la mise à jour
- description : La fréquence de mise à jour correspond à la périodicité suivant laquelle des modifications sont apportées au jeu de données. Pour simplifier le renseignement de ce champ, elle est désignée en choisissant une valeur parmi une liste pré-établie de valeurs possibles : 'Inconnue', 'Ponctuelle', 'Irrégulière', 'Continuelle', 'Toutes les heures', 'Quotidienne ou plusieurs fois par jour', 'Hebdomadaire ou plusieurs fois par semaine', 'Mensuelle ou plusieurs fois par mois', 'Bimestrielle', 'Trimestrielle', 'Semestrielle', 'Annuelle', 'Biennale', 'Triennale', ou 'Quinquennale'.
- type : chaîne de caractères
- exemple : `Semestrielle`
- valeur obligatoire
- valeurs autorisées : `["Inconnue","Ponctuelle","Irrégulière","Continuelle","Toutes les heures","Quotidienne ou plusieurs fois par jour","Hebdomadaire ou plusieurs fois par semaine","Mensuelle ou plusieurs fois par mois","Bimestrielle","Trimestrielle","Semestrielle","Annuelle","Biennale","Triennale","Quinquennale"]`
### `DATE_MAJ`
- titre : Date de la dernière mise à jour
- description : Date de la dernière modification effective du contenu du jeu de données. Elle est exprimée au format AAAA-MM-JJ suivant la norme internationale [ISO 8601](https://fr.wikipedia.org/wiki/ISO_8601).
- type : date
- exemple : `2018-01-14`
- valeur obligatoire
### `MOTS_CLES`
- titre : Mots clés
- description : Un ou plusieurs mot(s) clé(s) utilisé(s) pour décrire le jeu de données en minuscules non accentuées. S'il y en a plusieurs, le séparateur est le point-virgule.
- type : chaîne de caractères
- exemple : `scdl;prenoms;etat-civil`
- valeur obligatoire
### `LICENCE`
- titre : Licence appliquée sur le jeu de données
- description : Désignation de la licence qui encadre la réutilisation du jeu de données. En France, le [décret n° 2017-638 du 27 avril 2017](https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT000034502557) restreint le choix exclusivement à deux licences. D'autres sont néanmoins utilisées par quelques producteurs ou acteurs territoriaux pour encadrer la réutilisation de certains jeux de données. Pour simplifier le renseignement de ce champ, la licence du jeu de données est désignée en choisissant une valeur parmi une liste pré-établie de valeurs possibles : 'Licence Ouverte-LO', 'Open Database License-ODBL', 'Creative Commons-CC', 'Spécifique ou autre'.
- type : chaîne de caractères
- exemple : `Licence Ouverte-LO`
- valeur obligatoire
- valeurs autorisées : `["Licence Ouverte-LO","Open Database License-ODBL","Creative Commons-CC","Spécifique ou autre"]`
### `NOMBRE_RESSOURCES`
- titre : Nombre de ressource(s)
- description : Nombre de ressource(s) mise(s) à disposition dans le jeu de données.
- type : nombre entier
- exemple : `3`
- valeur obligatoire
- valeur minimale : 1
### `FORMAT_RESSOURCES`
- titre : Format(s) des ressources
- description : Format(s) dans le(s)quel(s) la (ou les) ressource(s) du jeu de données est (sont) mise(s) à disposition. Ce(s) format(s) est (sont) exprimé(s) en minuscules non accentuées. S'il y en a plusieurs, le séparateur est le point-virgule.
- type : chaîne de caractères
- exemple : `csv;xls;json`
- valeur obligatoire
### `URL`
- titre : URL d'accès
- description : Cet élément fournit un lien, une adresse web la plus stable possible, vers la page du jeu de données (ou de la ressource si le jeu de données n'en comprend qu'une) et/ou vers des informations complémentaires le concernant.
- type : chaîne de caractères (uri)
- exemple : `https://data.rennesmetropole.fr/explore/dataset/prenoms-des-nouveaux-nes-a-rennes-en-2017`
- valeur obligatoire
# Délibérations
Spécification du modèle de données relatif aux délibérations adoptées par une collectivité locale
## Contexte
Au-delà des obligations légales de transmission au contrôle de légalité et de publicité des actes des autorités locales définies dans le Code Général des Collectivités Territoriales, la mise à disposition en open data des données relatives aux délibérations adoptées par une collectivité locale doit permettre d'améliorer la transparence des décisions publiques prises par les différentes instances habilitées quelque soit l'échelon territorial considéré.
Parmi les nombreux actes administratifs qui matérialisent les décisions des autorités locales (arrêtés réglementaires, arrêtés individuels, contrats et conventions, documents budgétaires et financiers, ou autres), les délibérations sont très souvent adoptées à l'issue d'un vote en assemblée. La répartition des suffrages permet de mesurer le niveau d'adhésion des représentants élus à la décision concernée.
Les processus de documentation, de transmission dématérialisée au contrôle de légalité et/ou de diffusion publique (publication web des documents) des délibérations peuvent être outillés par des logiciels de gestion informatisée. Toutes les collectivités ne sont cependant pas équipées de tels outils.
De fait, la spécification SCDL du modèle de données relatif aux délibérations adoptées par une collectivité locale a été élaborée en cherchant à garantir son accessibilité pour un usage par toutes les collectivités, mais aussi à préserver leur capacité à automatiser la production du jeu de données attendu.
## Voir aussi
La spécification du modèle de données peut être utilement complétée par les documents suivants :