![\"Paramétrage](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/acceder-aux-geodonnees/limites-d-usage/rate-limiting-fme.png\")
Le service de validation de la Géoplateforme est disponible au travers d’une API REST.
\nIl permet à un utilisateur authentifié de la Géoplateforme de réaliser une validation d’une donnée fournie en tant qu’archive selon un standard ou une norme : standard PCRS ou standard PLU par exemple.\nEn sortie de cette API, l’utilisateur récupère :
\nCe système de validation est aussi mobilisable directement en tant que traitement au sein de la Géoplateforme - Entrepôt, afin, par exemple, de constituer une étape de prérequis avant intégration en base.
\nL’usage de ce service ou de ce traitement est à privilégier lorsque la donnée que vous produisez est soumise au respect d’un standard ou d’une norme. L’API ou le traitement validation vous donne un moyen exhaustif de vous assurer de la bonne conformité de votre donnée à ce standard.
\nEn tant que producteur d’une donnée agrégée répondant à un standard, il peut être utile d’inclure le traitement de validation comme étape préalable obligatoire à destination des producteurs de données locales afin qu’eux-mêmes ne fournissent au processus d’agrégation qu’une donnée normalisée.
\nLa documentation swagger permettant d’accéder aux détails des routes et paramètres pour réaliser une validation est accessible ici :
\nhttps://data.geopf.fr/validation/swagger-ui/index.html
\nLa documentation swagger permettant d’accéder aux détails des routes et paramètres pour réaliser une validation via un traitement d’entrepôt est accessible ici :
\nhttps://data.geopf.fr/api/swagger-ui/index.html
\nL’usage de l’API Validation nécessite de disposer d’un compte Géoplateforme mais n’est pas assorti à la détention d’un espace de travail sur la Géoplateforme - Entrepôt.
\nUn utilisateur ne peut, dans ce contexte, lancer que 60 validations parallèles sur son compte.
\nDans le cadre de la validation en tant que traitement de datastore, l’utilisateur doit bien entendu disposer d’un espace de travail associé au bon niveau de droit pour lui permettre d’y déposer une donnée et exécuter un traitement.
\nSi vous ne disposez pas du traitement validation associé à votre datastore, vous êtes invités à contacter geoplateforme@ign.fr qui apportera la modification nécessaire et ce quelle que soit votre formule tarifaire.
\nLe service de validation attend pour fonctionner des standards rédigés au format JSON et qui associent les critères à vérifier et le niveau de sévérité de chacun des critères.
\nPour ses propres besoins, l’IGN entretient ses propres fichiers JSON sur certains de ces standards avec un niveau de sévérité des différents critères qui correspond à ses propres besoins ou ceux de ses commanditaires.
\nPour les documents d’urbanisme, les standards sont accessibles à :
\nhttps://github.com/IGNF/validator-config-gpu/tree/master/config
\nChoisir ensuite le modèle de standard visé et pointer sur la racine de ce standard, sur le fichier files.json.
Par exemple : https://github.com/IGNF/validator-config-gpu/blob/master/config/cnig_PLU_2025/files.json
\nPour les autres standards implémentés, se rendre sur : https://github.com/IGNF/validator/tree/master et pointer vers les différents plug-ins disponibles.
\nL’usage de l’API Validation démarre par l’envoi du lot de données à valider et le paramétrage de la durée de rétention du rapport de validation (et du lot de données mis au standard le cas échéant).
\nCette création se fait au moyen de la route :
\nPOST https://data.geopf.fr/validation/api/validations
retention prend comme valeur un entier en jours et vient en paramètre de l’URL. Il définit la durée pendant laquelle le résultat (log, rapport, donnée source, donnée normalisée) sera disponible.
Le body du POST est constitué par le lot de données à valider, envoyé au format archive (.zip, .7z, .tat, et .tar.gz). Ce body est soumis en multipart/form-data.
L’utilisateur reçoit en retour un corps de réponse en JSON du type :
\n{\n \"validationID\": \"9a68f97a-4f20-47a3-a88e-d5d94ca6a329\",\n \"status\": \"created\",\n \"dataset_name\": \"22232_PLU_20200124.zip\",\n \"arguments\": {},\n \"created\": \"2026-01-12T15:19:10.037805858Z\",\n \"message\": \"Validation créée\"\n}Il convient d’extraire de cette réponse le validationID qui va servir pour la suite.
À cette étape intervient le paramétrage des critères de validation (quel standard ? production d’un lot de données normalisé ?) à proprement parler et le déclenchement effectif de cette validation.
\nCe paramétrage s’effectue au moyen de la route :
\nPATCH https://data.geopf.fr/validation/api/validations/{validationID}
Où :
\nvalidationID est l’identifiant de la validation, récupéré à l’étape « Créer une validation »{\n \"model\": \"https://github.com/IGNF/validator-config-gpu/blob/master/config/cnig_PLU_2025/files.json\",\n \"srs\": \"EPSG:2154\",\n \"max-errors\": 20,\n \"normalize\": true,\n \"plugins\": \"CNIG\",\n \"encoding\": \"UTF-8\"\n}model est le lien URL vers un fichier JSON modèle de validation (cf. « Quels schémas de standard appeler et où les localiser ? »)srs est le code EPSG de la projection dans laquelle se trouve les données dans l’archive livréemax-errors est un entier paramétrant le nombre maximal d’erreurs qu’on souhaite avoir dans le rapport d’erreur, attention au fait qu’en plaçant trop bas cette valeur, le rapport risque de ne pas être exhaustifnormalize est un booléen prenant :\nplugins : tous les standards urbanisme doivent s’accompagner de l’appel au plug-in CNIG, pour les autres standards, se référer au plug-in dans lequel ils sont stockésencoding est une chaîne de caractères définissant l’encodage des données qui ont été livrées (généralement UTF-8)Au lancement de la requête, l’utilisateur récupère un corps de réponse du type :
\n{\n \"validationID\": \"9a68f97a-4f20-47a3-a88e-d5d94ca6a329\",\n \"status\": \"progress\",\n \"dataset_name\": \"22232_PLU_20200124.zip\",\n \"arguments\": {\n \"model\": \"https://github.com/IGNF/validator-config-gpu/blob/master/config/cnig_PLU_2025/files.json\",\n \"srs\": \"EPSG:2154\",\n \"max-errors\": 20,\n \"normalize\": true,\n \"plugins\": \"CNIG\",\n \"encoding\": \"UTF-8\"\n },\n \"created\": \"2026-01-12T15:19:10.037806Z\",\n \"message\": \"Validation lancée\",\n \"started\": \"2026-01-12T15:28:23.531767571Z\"\n}On y retrouve, en plus du validationID :
created et started qui sont des mentions d’horodatage de création et de lancement effectif de la validationstatus qui donne au moyen de valeurs fixes (ici created) l’état de la validationarguments qui reprend les paramètres de la validation déclarés lors de la requête PATCHmessage donne, en français uniquement, une phrase synthétique de l’état dans lequel se trouve le traitementSuivant le volume de donnée livré et la complexité du standard mobilisé sur la validation, cette dernière peut mettre un certain temps à s’exécuter.
\nIl peut donc être pertinent de venir interroger à pas de temps régulier la requête :
\nGET https://data.geopf.fr/validation/api/validations/{validationID}
Pour prendre connaissance de l’état de la validation. Le corps de réponse (en JSON) de cette requête est du type :
\n{\n \"validationID\": \"9a68f97a-4f20-47a3-a88e-d5d94ca6a329\",\n \"status\": \"failure\",\n \"dataset_name\": \"22232_PLU_20200124.zip\",\n \"arguments\": {\n \"model\": \"https://github.com/IGNF/validator-config-gpu/blob/master/config/cnig_PLU_2025/files.json\",\n \"srs\": \"EPSG:2154\",\n \"max-errors\": 20,\n \"normalize\": true,\n \"plugins\": \"CNIG\",\n \"encoding\": \"UTF-8\"\n },\n \"created\": \"2026-01-12T15:19:10.037806Z\",\n \"message\": \"Validation terminée\",\n \"started\": \"2026-01-12T15:28:23.531768Z\",\n \"finished\": \"2026-01-12T15:30:29.245168Z\"\n}La validation est terminée lorsqu’un horodatage finished est mentionné. Le statut correspondant peut être success ou failure.
Une validation en statut success ne signifie pas que le lot de données validé ne contient aucune erreur relative au standard mais simplement que le processus de validation est allé jusqu’à son terme sans encombre. De la même façon, un statut failure ne préjuge pas du fait que la donnée à valider contient ou non des erreurs. Cela signifie que le processus de validation a rencontré une erreur due généralement à une incohérence des paramètres soumis avec ce qui est trouvé dans la donnée : PLU validé avec un standard PCRS, erreur de projection, d’encodage…
Si la vérification termine en succès, on retrouve directement à ce niveau les critères de validation et les points qui sont ressortis en erreur dans un argument results.
Toutes les informations sur les résultats suivantes sont uniquement accessibles pendant la durée de rétention fixée à l’étape « Créer une validation ».
\nQue la validation se soit terminée en failure ou en success, le log est toujours consultable via la route :
GET https://data.geopf.fr/validation/api/validations/{validationID}/logs
Le retour en JSON donne les grandes étapes de la validation et le niveau de l’erreur le cas échéant.
\nLe rapport de validation est accessible uniquement en cas de validation dont le statut de sortie est success.
Il est récupérable via :
\nGET https://data.geopf.fr/validation/api/validations/{validationID}/results.csv
Cette requête produit un fichier results.csv délivré via une réponse en multipart/form-data.
\nLa donnée normalisée n’est disponible que si la validation a terminé en success et si lors de l’exécution de l’étape « Lancer une validation », l’argument normalize a été placé à true.
À ces deux conditions seulement, l’appel à la route :
\nGET https://data.geopf.fr/validation/api/validations/{validationID}/files/normalized
Déclenche en retour d’appel un corps en multipart/form-data qui permet de récupérer un ZIP de la donnée transmise en incluant en plus les champs manquants au bon type dans les différentes tables du lot de données pour lesquelles la validation est applicable.
\nÀ des fins d’historique ou pour reproduire les critères d’une validation déjà lancée par le passé, il peut être utile de rechercher une validation.
\nC’est possible au moyen de la route :
\nGET https://data.geopf.fr/validation/api/validations
Il est possible de filtrer ces recherches par :
\nstatus : un statut de validation parmi les valeurs : created, progress, success, failure et deleteddataset_name : permet de préciser, éventuellement avec le caractère joker « * » un jeu de données ayant fait l’objet d’une validationUne validation ayant dépassé sa période de rétention sera toujours accessible en filtrant par ce statut deleted.
Cet appel, comme la plupart des routes « catalogue » des API Géoplateforme, donne des résultats paginés. La pagination est pilotable par :
\npage qui vaut 1 au minimumlimit qui vaut 10 par défaut et 50 au maximumCompte tenu du fait qu’en théorie la donnée source est déjà disponible côté client, la fonction dont il est question ici n’est pas forcément d’un usage très courant, mais peut rendre service en cas de fausse manipulation.
\nEn l’occurrence, l’API de validation met à disposition une route qui permet de re-télécharger les données qu’un utilisateur a lui-même soumis à validation.
\nCet accès se fait par la route :
\nGET https://data.geopf.fr/validation/api/validations/{validationID}/files/source
Il déclenche en retour d’appel un corps en multipart/form-data qui permet de récupérer un ZIP de la donnée transmise.
\n\nCes informations sont uniquement accessibles pendant la durée de rétention fixée à l’étape « Créer une validation ».
\nEn cas de nécessité, une route permettant d’interrompre une validation déjà lancée est disponible via :
\nPOST https://data.geopf.fr/validation/api/validations/{validationID}/abort
Actionner cette route fait passer la validation en statut deleted et toutes les ressources associées à cette validation (donnée à valider, log…) sont supprimées de la plateforme.
La suppression d’une validation revient à anticiper les effets de l’écoulement du temps de rétention.
\nElle a pour effet de faire passer la validation au statut deleted et de supprimer toutes les ressources (donnée à valider, log…) qui y sont associées.
Cette suppression est déclenchée par la route :
\nDELETE https://data.geopf.fr/validation/api/validations/{validationID}
Pour utiliser la validation en tant que traitement, l’utilisateur doit disposer d’un espace de travail Géoplateforme sur lequel le traitement suivant est disponible :
\n{\n \"name\": \"Validateur Archive\",\n \"description\": \"Script de validation pour les livraisons archives\",\n \"_id\": \"75dad665-45e6-493a-88da-c604d59aac45\"\n}Un storage de type upload adapté pour stocker les données issues du validateur doit aussi être disponible sur le datastore utilisé.
Ce dernier point est normalement déjà effectif dans la mesure où dans le cas de la validation utilisée comme traitement, les données d’entrée sont lues à partir du stockage upload du datastore considéré et les données de sortie sont écrites sur ce même espace.
Il convient donc de porter une attention particulière au quota disponible sur ce stockage.
\nEnfin, dans le cas d’une validation exécutée en tant que traitement, la livraison de type archive doit avoir été effectuée classiquement selon les étapes habituelles :
\n.zip, .7z, .tat, et .tar.gz)Pour utiliser le traitement de validation sans normalisation de donnée, on fournira à l’exécution de traitement un corps de requête du type :
\n{\n \"processing\": \"cc923709-e34c-4fab-8ebd-7414a0ddbabf\",\n \"inputs\": {\n \"upload\": [\"66a31282-d9cb-42c6-916f-a2b58c120a0c\"]\n },\n \"output\": {\n \"upload\": { \"id\": \"66a31282-d9cb-42c6-916f-a2b58c120a0c\"}\n },\n \"parameters\": {\n \"model\": \"https://raw.githubusercontent.com/IGNF/validator-config-gpu/refs/heads/master/config/cnig_PLU_2017/files.json\",\n \"is_compressed\": true,\n \"max-errors\": 20,\n \"normalize\": false,\n \"plugins\": \"CNIG\",\n \"encoding\": \"UTF-8\"\n }\n}L’appel en lui-même se fait, comme pour tout traitement, via l’appel API Entrepôt.
\nPar rapport à l’exécution via l’API Validation on notera les différences suivantes :
\ninputs et output prennent dans les deux cas un type upload renseigné par l’identifiant de la livraison qui va être validée"is_compressed": true dans le cas où on fournit une archive compressée, sans quoi l’instruction de dézippage ne sera pas effectuée et le traitement sortira en erreurparameters en fournissant la syntaxe suivante :\"callback\": {\n \"type\": \"email\",\n \"to_address\": [\n \"une_adresse_electronique\",\n \"une_autre_adresse_electronique\"\n ]\n}Cette instruction permet aux détenteurs des adresses électroniques mentionnées de recevoir un courriel de notification de fin de traitement que l’issue soit positive ou non.
\nLe rapport de validation est stocké directement dans le dossier de la livraison fournie en entrée.
\n\nPour ne pas préjuger de l’usage futur de la livraison ainsi validée, en sortie de traitement de validation, la livraison est laissée en statut OPEN et devra donc être fermée à nouveau pour être réinjectée dans un traitement d’intégration à la Géoplateforme.
Cette précision faite, la récupération du rapport de validation s’effectue en deux appels :
\nGET https://data.geopf.fr/api/datastores/{datastore_id}/uploads/{upload_id}/tree permet de détailler l’arborescence modifiée de la livraison initiale. L’utilisateur reçoit en retour, une réponse du type :[\n {\n \"type\": \"DIRECTORY\",\n \"name\": \"source\",\n \"size\": 28162296,\n \"children\": [\n {\n \"type\": \"FILE\",\n \"name\": \"22232_PLU_20200124.zip\",\n \"size\": 28154363\n },\n {\n \"type\": \"FILE\",\n \"name\": \"__results.jsonl\",\n \"size\": 7933\n }\n ]\n }\n]source/__results.jsonl. Cette information est utile pour le second appel.GET https://data.geopf.fr/api/datastores/{datastore_id}/uploads/{upload_id}/data?path=mon_path/__results.jsonl permet grâce aux informations précédentes, d’obtenir un corps de réponse multipart/form-data donnant accès au rapport de validation. Cette requête prend en paramètre, en plus des classiques identifiants de datastore et de livraison, le chemin d’accès identifié ci-dessus, via un paramètre path.Pour utiliser le traitement de validation avec normalisation de donnée, on fournira à l’exécution de traitement un corps de requête du type :
\n{\n \"processing\": \"cc923709-e34c-4fab-8ebd-7414a0ddbabf\",\n \"inputs\": {\n \"upload\": [\"66a31282-d9cb-42c6-916f-a2b58c120a0c\"] \n },\n \"output\": {\n \"upload\": { \"name\": \"Ma donnée normalisée\"}\n },\n \"parameters\": {\n \"model\": \"https://raw.githubusercontent.com/IGNF/validator-config-gpu/refs/heads/master/config/cnig_PLU_2017/files.json\",\n \"is_compressed\": true,\n \"max-errors\": 20,\n \"normalize\": true,\n \"plugins\": \"CNIG\",\n \"encoding\": \"UTF-8\"\n }\n}L’appel en lui-même se fait, comme pour tout traitement, via l’appel API Entrepôt.
\nPar rapport à l’exécution via l’API Validation on notera les différences suivantes :
\ninputs et output prennent un type upload renseigné par l’identifiant de la livraison qui va être validée.output prend un type upload renseigné par un nom au choix pour créer un second jeu de données en sortie, jeu de données qui sera le jeu de données d’entrée modifié par l’ajout des éléments de normalisation. Après l’exécution de cette requête, le corps de réponse permet d’obtenir l’identifiant de la donnée d’upload normalisée qui sera produite. Cette information est à mettre de côté pour la phase « Récupération de la donnée normalisée ».is_compressed à true dans le cas où on fournit une archive compressée, sans quoi l’instruction de dézippage ne sera pas effectuée et le traitement sortira en erreurnormalize à true pour produire la donnée normalisée en sortieparameters en fournissant la syntaxe suivante :\"callback\": {\n \"type\": \"email\",\n \"to_address\": [\n \"une_adresse_electronique\",\n \"une_autre_adresse_electronique\"\n ]\n}Le rapport de validation est stocké directement dans le dossier de la livraison créée en sortie.
\n\nPour ne pas préjuger de l’usage futur de la livraison ainsi validée, en sortie de traitement de validation, la livraison est laissée en statut OPEN et devra donc être fermée à nouveau pour être réinjectée dans un traitement d’intégration à la Géoplateforme.
Cette précision faite, la récupération du rapport de validation s’effectue en deux appels :
\nGET https://data.geopf.fr/api/datastores/{datastore_id}/uploads/{upload_id}/tree permet de détailler l’arborescence modifiée de la livraison initiale. L’utilisateur reçoit en retour, une réponse du type :[\n {\n \"type\": \"DIRECTORY\",\n \"name\": \"validation\",\n \"size\": 28162296,\n \"children\": [\n {\n \"type\": \"FILE\",\n \"name\": \"22232_PLU_20200124.zip\",\n \"size\": 28154363\n },\n {\n \"type\": \"FILE\",\n \"name\": \"__results.jsonl\",\n \"size\": 7933\n }\n ]\n }\n]validation/__results.jsonl. Cette information est utile pour le second appel.GET https://data.geopf.fr/api/datastores/{datastore_id}/uploads/{upload_id}/data?path=mon_path/__results.jsonl permet grâce aux informations précédentes, d’obtenir un corps de réponse multipart/form-data donnant accès au rapport de validation. Cette requête prend en paramètre, en plus des classiques identifiants de datastore et de livraison, le chemin d’accès identifié ci-dessus, via un paramètre path.La récupération du jeu de données normalisé suit exactement le même processus que celui de récupération du rapport de validation.
\nIl convient simplement d’adapter la partie du chemin qui sera récupéré.
\n", "date_published": "2026-08-07T09:54:14Z" }, { "id": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/extraction/", "url": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/extraction/", "title": "Extraction", "content_html": "Le service d’extraction vecteur de la Géoplateforme est disponible au travers d’une API REST répondant au standard OGC API Processes.
\nIl permet à un utilisateur authentifié de la Géoplateforme de réaliser un export de données vecteur en sélectionnant lui-même quelles tables, quels champs attributaires de ces tables et/ou quelle emprise spatiale de ces tables il souhaite exporter. L’utilisateur choisit en plus quelle est la projection de sortie de ses données ainsi que le format de donnée qu’il récupère parmi : Shapefile, GeoPackage, GeoJSON, GeoParquet, GML ou PGDUMP.
\nLa liste des données extractibles est conditionnée à l’utilisateur connecté. Ce dernier peut disposer de données accessibles à l’ensemble des utilisateurs de la Géoplateforme tout comme il peut disposer de données extractibles spécifiquement pour son profil. Ce choix de mise à disposition est fait par le producteur de données. Cet aspect fait l’objet de la dernière rubrique de la présente documentation.
\nLe fonctionnement de l’API d’extraction vecteur de la Géoplateforme est donc intimement lié à celui de l’API Entrepôt de la Géoplateforme.
\nL’usage de ce service est à privilégier lorsque les lots de données prêts à télécharger (via le service de téléchargement de la Géoplateforme) ne correspondent pas à votre périmètre de travail ou que le temps nécessaire à la récréation de ce lot de données selon votre périmètre de travail est plus court via le service d’extraction.
\nPar exemple :
\nLa documentation swagger permettant d’accéder aux détails des routes et paramètres pour réaliser une extraction vecteur est accessible ici :
\nChaque compte utilisateur de la Géoplateforme ne peut exécuter qu’une seule extraction en même temps. Une extraction est considérée comme terminée et le quota réinitialisé dès lors que l’extraction s’est terminée en succès ou en échec.
\nPar ailleurs le service est configuré de telle sorte que, pour l’ensemble des utilisateurs déclenchant une extraction, 20 extractions peuvent tourner en simultané. Cela implique la constitution d’une file d’attente dès lors que ce quota est rempli et donc des temps de mise à disposition des extractions de chacun qui peuvent être conjoncturellement rallongés.
\nL’URL de capabilities correspond à la racine du service : https://data.geopf.fr/extraction
Conformément au standard OGC API Processes, cette URL référence les URL de niveau immédiatement inférieur :
\nL’URL de conformance (ou conformité) renvoie vers les pages des différentes parties du standard OGC avec lesquelles cette API est conforme.
\nL’accès à cette information n’est pas strictement nécessaire à l’exécution d’une extraction vecteur.
\nPour connaitre la liste des données qui lui sont accessibles en extraction, un utilisateur dispose de deux routes API Entrepôt :
\nGET https://data.geopf.fr/api/users/me/stored_data : Permet d’obtenir la liste de l’ensemble des données qui me sont accessibles, possiblement en restreignant cette liste selon différents critèresGET https://data.geopf.fr/api/users/me/stored_data/{stored_data} : À partir de la route précédente, on obtient un identifiant de données _id qui sera placé en paramètre obligatoire permettant d’avoir le détail de cette donnéePour l’ensemble des paramètres et valeurs de ces paramètres vous êtes invités à consulter le swagger.
\nNéanmoins, ces routes ayant des usages qui vont au-delà de la seule API d’extraction, on va faire ici un zoom sur quelques paramètres qui peuvent être mobilisés à bon escient pour faciliter l’identification d’une ressource à extraire.
\nLes paramètres que l’on mentionne ici sont exclusivement à mobiliser dans la requête :
\nGET https://data.geopf.fr/api/users/me/stored_data
Ils sont listés dans l’ordre d’apparition dans le swagger.
\ntype et VECTOR-DB : Permet de restreindre la liste des résultats aux seules données mobilisables par l’API d’extraction : des données de type vecteur.name : Permet d’identifier une donnée par son nom. Le caractère joker « % » permet la recherche sur un contenu partiel. La chaine de texte à préciser est insensible à la casse. Ainsi, une chaine %BD%TOPO% trouvera des données comme Ma BDTOPO, BD TOPO ou encore BDTOPO_septembre_2025.lon et lat : Où des coordonnées latitude - longitude (EPSG : WGS84 en degrés décimaux) d’un point d’intérêt sont intersectées avec l’emprise des données : si le point est intersecté, la donnée est listée, sinon elle n’est pas listée.before et/ou after : Permet de ne conserver que les données créées avec une certaine actualité de date.page et limit : Comme tous les résultats de l’API Entrepôt, les résultats de cette route sont paginés. La première page porte le numéro 1, et la limite est fixée à 10 éléments par défaut, 50 éléments au maximum. Pensez à bien parcourir les pages pour vous assurer que votre résultat attendu ne se situe pas en page 2 ou plus loin encore.Une fois la donnée d’intérêt identifiée ci-dessus et son _id récupéré, il peut être injecté dans la requête de détail :
GET https://data.geopf.fr/api/users/me/stored_data/{stored_data}
Où {stored_data} sera remplacé par la valeur de cet _id sans les doubles quotes.
On obtient en réponse, un contenu du type suivant (toujours en JSON) :
\n{\n \"creation\": \"2025-09-03T14:14:23.666532Z\",\n \"name\": \"Pays et écorégions\",\n \"type\": \"VECTOR-DB\",\n \"open\": false,\n \"srs\": \"EPSG:4326\",\n \"contact\": \"email\",\n \"extent\": {\n \"geometry\": {\n \"type\": \"MultiPolygon\",\n \"coordinates\": [\n // une série de coordonnées en WGS84\n ]\n },\n \"type\": \"Feature\"\n },\n \"size\": 9912320,\n \"status\": \"GENERATED\",\n \"_id\": \"c746ce1d-e38c-42c4-a9a3-ef34d5bbea40\",\n \"type_infos\": {\n \"relations\": [\n {\n \"name\": \"ecoregions\",\n \"type\": \"TABLE\",\n \"attributes\": {\n \"id\": \"integer\",\n \"fid\": \"bigint\",\n \"nnh\": \"integer\",\n \"geom\": \"geometry(MultiPolygon,4326)\",\n \"color\": \"character varying\",\n \"realm\": \"character varying\",\n // …\n },\n \"primary_key\": [\n \"ogc_fid\"\n ]\n },\n {\n \"name\": \"pays\",\n \"type\": \"TABLE\",\n \"attributes\": {\n \"id\": \"integer\",\n \"un\": \"integer\",\n \"fid\": \"bigint\",\n \"lat\": \"double precision\",\n // …\n },\n \"primary_key\": [\n \"ogc_fid\"\n ]\n }\n ]\n }\n}Parmi les attributs en résultat certains sont particulièrement utiles pour préparer son extraction.
\nCes attributs intéressants sont listés ci-dessous dans l’ordre dans lequel on les trouve dans la réponse :
\nsrs : Donne le code EPSG de la projection des données que l’on va extraire. Cette information est particulièrement utile dans le cas où on prévoit d’employer un filtre spatial.
Il sera intéressant pour des questions de performance, de fournir la géométrie de filtrage dans la même projection que celle des données stockées sur la Géoplateforme.
\nextent : Il s’agit de la géométrie en GeoJSON, décrivant de manière détaillée, l’emprise des données disponibles. Là aussi, si un filtre spatial est envisagé, il peut être utile de tester en amont, que la géométrie de filtrage envisagée recoupe la géométrie de la donnée source, au risque sinon de se retrouver avec un export vide.
type_infos et relations : C’est le cœur de la réponse qui présente un intérêt particulier pour préparer l’export puisque c’est dans cette partie que l’on va trouver la liste de tables exportables :
name : Le nom de la table sera systématiquement en minuscule et sans espace ni caractères spéciaux.attributes : Il s’agit d’un objet JSON dont le contenu est le nom de chaque champ et son type en base de données. Il faut donc prévoir d’extraire cette liste d’attributs qui devra être mentionnée, pour chaque table, soit en totalité, soit sur une sélection d’intérêt, dans la déclaration du processus d’extraction. L’information du type aura son intérêt en cas d’utilisation d’un ou plusieurs champs dans la clause de filtrage d’extraction pour adapter les fonctions et la syntaxe à mobiliser en fonction du type de champ. Idem pour le type de géométrie (et notamment la présence d’une coordonnée Z qui peut jouer sur le comportement de certaines fonctions spatiales).Lors de l’étape précédente on a donc isolé un identifiant de donnée extractible sous l’attribut _id et prenant la forme d’un UUID.
En basculant sur l’API d’extraction vecteur, la route est :
\nGET https://data.geopf.fr/extraction/processes
On récupère une liste de processus d’extraction décrits par :
\n_id identifiant de manière unique un processus d’extraction lié à une donnée particulièretitle mentionnant « Extraction vecteur depuis » + l’attribut name de la donnée extractible identifiée plus hautdescription reprenant la description de la donnée extractible identifiée plus haut.links pointant d’une part vers la route de détail de tel ou tel processus d’extraction, ainsi que la route de détail de la donnée extractible qui y est liéoutputTransmission et jobControlOptions de type tableau et qui vaudront toujours respectivement reference et async-executeL’information clé à extraire ici est la valeur du bon _id qui correspond à celui de la donnée que l’on souhaite extraire.
Or un identifiant _id est toujours composé de la même manière : « identifiant du traitement générique d’extraction » + « _ » + « identifiant de la donnée à extraire ». La valeur de _id du traitement générique d’extraction étant 8ab6236b-21d8-471a-a07b-f84a5921f9f5, il suffit donc de construire l’identifiant de l’extraction comme 8ab6236b-21d8-471a-a07b-f84a5921f9f5 + « _ » + « identifiant de la donnée d’intérêt ».
Sur l’API d’extraction vecteur, la route est :
\nGET https://data.geopf.fr/extraction/processes/{processID}
Elle permet d’obtenir, en plus des informations précédentes, les informations suivantes :
\nversion : La version du traitement, actuellement 1.0.0.inputs : Liste l’ensemble des paramètres pour configurer une extraction. Chacun de ces paramètres sera détaillé dans la rubrique « Paramétrer une extraction ». L’information à retenir ici est que l’on trouve pour chaque paramètre, son nom, une description de son impact et des valeurs attendues ainsi que de son caractère obligatoire ou pas, cette information est donnée par l’élément minOccur. Si minOccur est à 1, alors le paramètre est obligatoire, si minOccur vaut 0, le paramètre est facultatif.outputs : Définit le contenu des sorties, on retrouve systématiquement un log d’export, un résumé d’extraction en JSON et en cas de succès un résultat téléchargeable sur une instance du service de téléchargement Géoplateforme, correspondant à un flux ATOM XML.Grâce aux informations accumulées aux étapes précédentes, il est possible de paramétrer et déclencher sa première extraction.
\nLa configuration de l’extraction et son déclenchement se font en un seul et même appel API via la route :
\nPOST https://data.geopf.fr/extraction/processes/{processID}/execution
On configure, dans le corps de requête ci-dessous, une extraction type pour une donnée contenant deux tables de données.
\nOn trouvera au-dessous de ce corps de requête type, un descriptif détaillé et exhaustif des différents paramètres et leur contenu.
\n{\n \"inputs\": {\n \"relations\": {\n \"table_1\": {\n \"attributes\": [\n \"attribut1\",\n \"attribut2\",\n \"attribut3\",\n // …\n \"attribut_geometrie\"\n ],\n \"filters\": \"ST_intersects(attribut_geometrie,st_transform(st_setsrid('POLYGON ((893173.37413014 6245898.77978964,897816.865990493 6246039.4916642,897852.043959132 6241747.77949023,893208.552098779 6241501.53370976,893208.552098779 6241501.53370976,893173.37413014 6245898.77978964))'::geometry,2154),2154)) AND attribut1='Valeur texte de filtrage'\" \n },\n \"table_2\": {\n \"attributes\": [\n \"attribut1\",\n \"attribut2\",\n \"attribut3\",\n // …\n \"attribut_geometrie\"\n ],\n \"filters\": \"ST_intersects(attribut_geometrie,st_transform(st_setsrid('POLYGON ((893173.37413014 6245898.77978964,897816.865990493 6246039.4916642,897852.043959132 6241747.77949023,893208.552098779 6241501.53370976,893208.552098779 6241501.53370976,893173.37413014 6245898.77978964))'::geometry,2154),2154))\"\n }\n },\n \"format\": \"GPKG\",\n \"append\": true,\n \"compression\": \"7zip\",\n \"srs\": \"EPSG:3857\",\n \"lifetime\": 336\n },\n \"outputs\": {\n \"logs\": {},\n \"summary\": {},\n \"extractedData\": {}\n }\n}Dans la partie inputs du corps de requête, on va donc trouver les paramètres d’entrée du traitement. Cette partie sera la plus détaillée.
La partie outputs ayant un comportement autonome, on ne la détaillera pas, elle doit être reprise telle que mentionnée dans le corps de requête exemple pour chaque extraction.
Dans la partie inputs donc :
Le paramètre relations définit sous la forme d’un objet (sa déclaration commence par un caractère « { » et se termine par un caractère « } ») la liste des tables qui vont être exportées. Chaque table exportée devient elle-même un objet de la forme :
\"nom_technique_table\": { \n \"attributes\": [\n // une liste nommant les attributs que l’on veut conserver\n ],\n \"filters\": \"syntaxe de filtrage\" \n}Le nom technique de la table et la liste des attributs, pour rappel, sont identifiés via la rubrique « Accéder aux ressources extractibles et obtenir les infos clés (nom des tables, projection, structure attributaire) ».
\nLa liste des attributes débute par un « [ » et se termine par un « ] ». Elle reprend le nom technique de chaque attribut, entre doubles quotes, étant séparé du précédent par une virgule. Si on souhaite exporter tous les attributs, on doit mentionner explicitement chaque attribut.
La syntaxe SQL n’est pas autorisée dans cette partie. La géométrie étant un champ attributaire comme un autre, si on souhaite un export spatial, il faut mentionner le champ géométrie dans cette partie.
\nLe paramètre filters contient entre doubles quotes, une syntaxe PostgreSQL/PostGIS permettant de filtrer les objets d’une couche. Tout ce qu’il est possible de faire dans un WHERE PostgreSQL/PostGIS mono-couche est autorisé.
L’appel d’une sous-requête n’est pas permis. Les requêtes multi-tables ne sont pas permises. La combinaison de requêtes spatiales et/ou de requêtes spatiales avec des critères alphanumériques ou de date est tout à fait admise.
\nL’utilisateur est invité à se référer à la documentation en ligne de PostgreSQL/PostGIS pour en savoir plus sur les fonctions et syntaxes associées mobilisables et ce pour les versions suivantes de PostgreSQL : v12 et de PostGIS : v3.3.
\nPlus le critère de filtrage est complexe, plus l’export est long. Nous invitons donc chaque utilisateur à mesurer la complexité de ses critères de filtrage en recherchant l’optimisation de chaque processus.
\nLe paramètre format précise le format d’export des données. Seules sont autorisées les valeurs entre doubles quotes suivantes :
GPKG (GeoPackage)GML (Geography Markup Language)GEOJSONESRI SHAPEFILEPARQUET (GeoParquet)PGDUMP (Format de sauvegarde PostgreSQL/PostGIS compatible avec les utilitaires de remontée en base locale tels que pg_restore ou psql)Chaque format est à préciser tel que mentionné ci-dessus (sensible à la casse) et entre doubles quotes.
\nLe paramètre append doit être compris comme étant combiné (et donc dépendant) avec le paramètre format. Il s’agit d’un paramètre booléen qui prend donc en valeur soit true soit false. L’emploi de la valeur true n’est compatible qu’avec les formats qui peuvent être multicouches, à savoir GPKG et PGDUMP. Si la valeur true est employée avec un autre format, elle ne sera pas prise en compte, c’est-à-dire que le traitement ne déclenchera pas d’erreur, mais on obtiendra en sortie un fichier par table demandée dans l’objet relations.
Le paramètre compression prend comme unique valeur possible 7zip. En étant mentionné, il permet d’obtenir un résultat compressé, donc possiblement (suivant le format choisi) beaucoup moins volumineux et donc plus rapide à récupérer. À noter que la compression va automatiquement découper le résultat en fichiers d’archive de 4 Go chacun maximum. Donc si le résultat d’export fait 7 Go, l’utilisateur aura à récupérer en intégralité un fichier mon_fichier.001.7z et un fichier mon_fichier.002.7z avant de pouvoir exploiter l’export depuis son environnement.
Le paramètre srs permet de produire une extraction dans une projection différente de celle de la donnée stockée sur la Géoplateforme. La valeur attendue est un code EPSG entre double quotes sous la forme EPSG:code_proj. Attention au fait que toute demande de reprojection induit un allongement du temps d’export. Il convient donc de mentionner ce paramètre à bon escient, suivant la projection des données d’entrée et seulement en cas de réelle utilité.
Le paramètre lifetime permet de paramétrer la durée de rétention du résultat d’un export une fois celui-ci réalisé. La valeur de ce paramètre s’entend en heures. Sa valeur est comprise entre 7 et 336 (soit 14 jours). Passé l’expiration de ce délai, le résultat de l’extraction est automatiquement supprimé du point de diffusion et l’utilisateur devra renouveler sa demande d’extraction. Il convient là aussi à chacun de rechercher le strict délai de rétention qui convient à son cas de figure et ne pas faire porter à la Géoplateforme un fichier qui sera récupéré dès le lendemain de son extraction.
Lors de l’exécution de cette requête, un contrôle des informations saisies est réalisé : le nom des tables est-il cohérent avec le processus appelé ? Les attributs sont-ils là aussi bien présents ? Le format déclaré est-il connu ? etc. En revanche, aucune cohérence de la clause de filtrage n’est effectuée tant en termes de pure syntaxe PostgreSQL que de capacité de ce filtre à alimenter concrètement un export avec de la donnée. Autrement dit, il est possible que la clause de filtrage que l’utilisateur va déterminer déclenche un export vide.
\nEn retour de l’exécution de la requête d’extraction, l’utilisateur reçoit une réponse du type :
\n{\n \"jobID\": \"d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db\",\n \"status\": \"running\",\n \"message\": \"Extraction des données demandées en cours\",\n \"created\": \"2025-10-13T14:55:07.278666682Z\",\n \"updated\": \"2025-10-13T14:55:07.278666682Z\",\n \"links\": [\n {\n \"rel\": \"describedBy\",\n \"type\": \"application/json\",\n \"title\": \"Job d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db\",\n \"href\": \"/jobs/d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db\"\n }\n ],\n \"started\": \"2025-10-13T14:55:07.278666682Z\",\n \"processID\": \"8ab6236b-21d8-471a-a07b-f84a5921f9f5_50edff37-30c7-4ce6-8a4a-8ca960a43974\",\n \"type\": \"process\"\n}jobID : Cette information doit être conservée pour suivre l’exécution du traitement et récupérer les résultatsstatus : Donne l’état de déroulement du traitement, en sortie d’exécution le statut prendra la valeur runningmessage : Donne en texte clair l’état du traitement, ce message est seulement disponible en françaiscreated, updated et started : Des informations d’horodatage de déclenchement du traitement et de lancement concret de l’exécution du traitementlinks : Donne le lien vers la route d’API qui permet de suivre l’exécution du traitementprocessID : Rappel de l’identifiant du process d’exécution qui a été mobilisé pour l’exporttype : Information relative au standard OGC, toujours de valeur processUne fois le traitement d’extraction démarré par l’exécution de la requête précédente, il est possible, voire utile de suivre le déroulé des opérations via la route :
\nGET https://data.geopf.fr/extraction/jobs/{jobID}
L’utilisateur reçoit un retour qui ressemble trait pour trait au retour reçu à l’étape précédente et ce jusqu’à ce que l’extraction termine en échec ou en succès, auquel cas il obtiendra un retour de ce type :
\n{\n \"jobID\": \"38d43c19-d974-42ba-9d9b-11cf524b5b61\",\n \"status\": \"failed\",\n \"message\": \"Erreur lors de l’extraction des données\",\n \"created\": \"2025-11-25T13:37:20.845151Z\",\n \"finished\": \"2025-11-25T13:40:27.769106Z\",\n \"updated\": \"2025-11-25T13:40:28.459020Z\",\n \"links\": [\n {\n \"rel\": \"self\",\n \"type\": \"application/json\",\n \"title\": \"Job 38d43c19-d974-42ba-9d9b-11cf524b5b61\",\n \"href\": \"/jobs/38d43c19-d974-42ba-9d9b-11cf524b5b61\"\n },\n {\n \"rel\": \"describedBy\",\n \"type\": \"application/json\",\n \"title\": \"Résultats du job 38d43c19-d974-42ba-9d9b-11cf524b5b61\",\n \"href\": \"/jobs/38d43c19-d974-42ba-9d9b-11cf524b5b61/results\"\n }\n ],\n \"started\": \"2025-11-25T13:37:20.845151Z\",\n \"processID\": \"8ab6236b-21d8-471a-a07b-f84a5921f9f5_50edff37-30c7-4ce6-8a4a-8ca960a43974\",\n \"type\": \"process\"\n}En plus des informations détaillées à l’étape précédente on retrouve :
\nfinished, un élément d’horodatage de la fin du traitement. En cas de demande d’extraction récurrente il est utile d’observer le différentiel created - finished pour le cas échéant adapter l’horaire de déclenchement de son extractionstatus qui a évolué soit vers une valeur successful soit vers une valeur failedlinks, un second élément dans le tableau de réponse, décrit par "rel": "describedBy" et qui permet d’obtenir directement la route d’API à exécuter pour prendre connaissance du résultat ou du log d’erreur en cas d’échecUne fois le traitement terminé à l’étape précédente, on peut donc exécuter la route d’obtention des résultats via :
\nGET https://data.geopf.fr/extraction/jobs/{jobID}/results
On reçoit alors un retour du type :
\n{\n \"logs\": \"[\\\"2025-12-04 10:32:19,317INFO||gpf-extraction-vector-db||7||Ouverture du fichier de configuration\\\",\\\"2025-12-04 10:32:19,331INFO||cli||224||Extraction de données vecteurs\\\",\\\"2025-12-04 10:32:19,568INFO||cli||224||Création de l’utilisateur temporaire\\\",\\\"2025-12-04 10:32:19,613INFO||cli||224||Début des traitements : 2025-12-04T10:32:19Z\\\",\\\"2025-12-04 10:44:17,555INFO||cli||224||Fin des traitements : 2025-12-04T10:44:17Z\\\",\\\"2025-12-04 10:44:17,556INFO||cli||224||Génération et upload du fichier de métadonnées\\\",\\\"2025-12-04 10:44:17,649INFO||cli||224||Copie des données vers le S3\\\",\\\"2025-12-04 10:45:24,393INFO||core||612||Calcul et upload du fichier __descriptor.json\\\",\\\"2025-12-04 10:45:25,991INFO||core||612||Mise à jour des informations de la données stockée\\\",\\\"2025-12-04 10:45:25,991INFO||cli||224||Suppression de l’utilisateur temporaire\\\"]\",\n \"summary\": {\n \"rel\": \"describedBy\",\n \"type\": \"application/json\",\n \"title\": \"Informations sur le processus d’extraction\",\n \"href\": \"https://data.geopf.fr/extraction/telechargement/download/extraction_b1f8cdc1-7dd3-4536-a4aa-d484c8023878/data/extraction.json\"\n },\n \"extractData\": {\n \"rel\": \"describedBy\",\n \"type\": \"application/atom+xml\",\n \"title\": \"Résultats du processus d’extraction\",\n \"href\": \"https://data.geopf.fr/extraction/telechargement/resource/extraction_b1f8cdc1-7dd3-4536-a4aa-d484c8023878/data\"\n }\n}logs : Donne un résumé des grandes étapes du traitement en cas de succès ou un focus sur l’erreur rencontrée.summary : Donne accès à un résumé JSON de l’extraction : horodatage de début et de fin, format demandé, liste des tables extraites notamment.extractData : Donne accès au lien de téléchargement des ressources extraites. La manipulation de cette URL est identique à celle réalisée pour le service de téléchargement générique de la Géoplateforme. L’utilisateur est invité à se reporter à la documentation dédiée se rapportant à ce service pour plus d’informations.Si l’utilisateur a raté l’étape « Exploiter la réponse de la demande d’exécution de traitement » ou pour toute nécessité de se référer à un traitement déjà lancé, il est possible de retrouver un traitement via la route :
\nGET https://data.geopf.fr/extraction/jobs
Cette recherche est filtrable par :
\nAAAA-MM-JJTHH:mm:ss.00ZAAAA-MM-JJTHH:mm:ss.00Z/AAAA-MM-JJTHH:mm:ss.00Z en notant que l’intervalle peut être ouvert des deux côtés en remplaçant la date par « .. » ce qui donne AAAA-MM-JJTHH:mm:ss.00Z/.. pour trouver les exécutions lancées après telle date ou ../AAAA-MM-JJTHH:mm:ss.00Z pour les exécutions avant telle dateEn cas de nécessité, un utilisateur peut stopper l’exécution d’un traitement via la route :
\nDELETE https://data.geopf.fr/extraction/jobs/{jobID}
L’ensemble des résultats liés éventuellement à ce traitement sont supprimés.
\nLe quota d’extraction disponible à l’utilisateur est instantanément libéré.
\nUne trace de ce traitement annulé est conservée via la route GET https://data.geopf.fr/extraction/jobs, les traitements annulés pouvant être retrouvés en filtrant sur le statut DISMISSED.
Un producteur de données peut choisir de rendre sa donnée exportable via l’API d’extraction soit à l’ensemble des utilisateurs de la Géoplateforme, soit aux membres de certaines communautés.
\nDans tous les cas, à l’échelle de l’entrepôt Géoplateforme, le niveau qui est rendu extractible est le niveau stored_data. Vous êtes invités à vous référer à la documentation dédiée aux concepts de la Géoplateforme si vous souhaitez en savoir plus à ce sujet.
Pour rendre une donnée extractible à l’ensemble des utilisateurs Géoplateforme, le producteur de données doit ouvrir la stored_data de type VECTOR-DB considérée.
Cette ouverture se fait a posteriori de la génération de ladite stored_data au moyen de la route :
PATCH https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}
À ce stade, il faut noter que la stored_data, au moment où elle a été générée, a rarement été configurée pour présenter un nom et une description agréable à un utilisateur final. Il se trouve que la route nommée précédemment permet de remédier à cela. Il est donc conseillé de profiter de l’ouverture pour régler un nom et une description qui soient utiles aux utilisateurs de l’API d’extraction pour identifier correctement la donnée à extraire.
Cette modification est normalement sans impact sur vos chaines de diffusion dans la mesure où seul _id est utilisé.
Attention toutefois si vous utilisez le SDK, qui lui peut mobiliser le nom de la stored_data.
Avec le corps de requête suivant (en JSON) le producteur de données peut ouvrir sa donnée et modifier son nom et sa description en un seul appel :
\n{\n \"name\": \"Un nom informatif avec espaces, majuscules ou accents si nécessaire\",\n \"description\": \"Une description synthétique en toutes lettres\",\n \"open\": true\n}Pour rendre visible à certaines communautés, une donnée stockée, le producteur va jouer sur sa visibilité.
\nMais au préalable, ce qui a été dit au paragraphe précédent sur le nom et la description de la stored_data, donc première étape, améliorer ces informations via :
PATCH https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}
Avec le corps de requête suivant :
\n{\n \"name\": \"Un nom informatif avec espaces, majuscules ou accents si nécessaire\",\n \"description\": \"Une description synthétique en toutes lettres\",\n \"open\": true\n}On répète à ce stade la même alerte que plus haut :
\nCette modification est normalement sans impact sur vos chaines de diffusion dans la mesure où seul _id est utilisé.
Attention toutefois si vous utilisez le SDK, qui lui peut mobiliser le nom de la stored_data.
Ce rappel fait, on peut désormais modifier la visibilité de la donnée via la route dédiée :
\nPOST https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility
Avec le corps de requête suivant (en JSON) :
\n[\n \"3fa85f64-5717-4562-b3fc-2c963f66afa6\",\n \"4ea85f64-5857-4562-bb2c-2c963f66art3\"\n]Où les valeurs entre quotes sont des identifiants de communautés dont l’ensemble des membres auront droit d’extraire la donnée en question.
\nCette route de modification de visibilité est associée à une route listant à quelles communautés une donnée est visible :
\nGET https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility
Ainsi qu’une route pour révoquer cette ouverture :
\nDELETE https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility
Qui fonctionnent exactement sur le même principe.
\n", "date_published": "2026-08-07T09:54:14Z" }, { "id": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/tutoriels-api/", "url": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/tutoriels-api/", "title": "Tutoriels API", "content_html": "", "date_published": "2026-08-07T07:54:58Z" }, { "id": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/statistiques/", "url": "https://cartes.gouv.fr/aide/fr/guides-utilisateur/utiliser-les-services-de-la-geoplateforme/statistiques/", "title": "Statistiques d’utilisation", "content_html": "L’API de statistiques d’utilisation de la Géoplateforme permet d’obtenir, entre deux dates, le nombre de requêtes (hits) ayant sollicité la Géoplateforme et le volume de données (octets) que la Géoplateforme a émis en réponse.
\nLes nombres de hits et d’octets sont agrégés par mois. Des agrégats par pas de 5 minutes sont également disponibles mais uniquement sur les 30 derniers jours par rapport à la date du jour.
\nL’API propose des requêtes destinées aux producteurs de données (qui diffusent leurs données depuis leurs datastores) et aux utilisateurs (qui accèdent aux données via les géoservices).
\nElle est interrogeable en méthode GET en étant authentifié via son compte Géoplateforme/cartes.gouv.fr.
\nSon swagger est accessible ici : swagger des statistiques d’utilisation.
\nL’API propose au producteur des requêtes, présentes dans les modules Organismes, Communautés et Entrepôts du Swagger, pour connaître la consommation des données associées à ces concepts.
\nDans la Géoplateforme, un organisme est défini comme une entité regroupant des communautés, avec des informations globales telles que le numéro SIRET.
\nAu grain d'un organisme, l’API propose les requêtes suivantes :
\nDans la Géoplateforme, une communauté est définie comme un groupe d'utilisateurs avec certains droits sur la communauté en elle-même et sur son éventuel entrepôt associé.
\nAu grain d’une communauté, l’API propose les requêtes suivantes :
\nDans la Géoplateforme, un entrepôt est défini comme un ensemble de données, fichiers statiques, configurations.
\nAu grain d’un entrepôt, l’API propose les requêtes suivantes :
\nPour l’utilisateur des géoservices, l’API propose des requêtes, présentes dans le module Utilisateur du Swagger, pour connaître les hits et octets de consommation de données en accès restreint.
\nLes agrégats proposés sont :
\nPour certaines API, une limite d’usage fixée en nombre de requêtes par seconde et par IP est mise en place.
\nCe mécanisme, dit de « rate limiting », concerne la plupart des API de la Géoplateforme à l’exception notable de l’API « Diffusion d’images tuilées WMTS » et son pendant « Diffusion de tuiles vectorielles TMS ». Il a pour objectif de garantir les engagements de disponibilité des API, en bloquant les usages individuels les plus massifs qui seraient susceptibles de mettre à mal l’infrastructure.
\nLorsqu’une IP sollicite une API au-delà de la limite d’usage fixée :
\nLes limites d’usage fixées sont les suivantes :
\n| API | Limite d’usage par IP |
|---|---|
| Diffusion d’images WMS-Raster | 40 requêtes/s |
| Diffusion d’images WMS-Vecteur | 50 requêtes/s |
| Diffusion d’objets WFS | 30 requêtes/s |
| Téléchargement | 10 requêtes/s |
| Téléchargement partiel | 200 requêtes/s |
| Découverte des métadonnées CSW | 15 requêtes/s |
| Géocodage | 50 requêtes/s |
| Autocomplétion | 10 requêtes/s |
| Calcul altimétrique | 5 requêtes/s |
| Calcul d’itinéraire | 10 requêtes/s |
| Calcul d’isochrone/isodistance | 5 requêtes/s |
| Recherche | 10 requêtes/s |
| Diffusion de tuiles vectorielles pg_tileserv | 400 requêtes/s |
| LiDAR « vraie pyramide » | 200 requêtes/s |
| LiDAR « COPC » au vol (partiel) | 200 requêtes/s |
| LiDAR téléchargement COPC | 10 requêtes/s |
Prenons l’exemple du géocodage d’un fichier de 1 000 lignes au moyen d’un script faisant appel à l’API de géocodage de la Géoplateforme.
\nSi le script sollicite l’API de géocodage sans précaution particulière, avec une fréquence qui dépasse la limite d’usage de 50 requêtes par seconde et par IP, alors :
\nSolution : paramétrer le script de telle sorte que la fréquence d’appel à l’API de géocodage ne dépasse pas 50 requêtes par seconde, en instaurant par exemple un plafond à 40 ou 45 requêtes par seconde.
\nÀ titre d’illustration, pour une utilisation de l’ETL FME édité par Safe Software, le paramétrage de la fréquence d’appel peut être effectué comme suit :
\n
L’outil « Mesurer une distance » permet de dessiner une ligne sur la carte et d’en connaître en temps réel la longueur.
\nCliquez sur l’icône de l’outil :
\n![\"Icône](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-distance/01_mesurer-une-distance.png\")
Vous pouvez alors cliquer sur la carte pour commencer à créer la ligne. Chaque nouveau clic permet d’ajouter un sommet supplémentaire à la ligne :
\n![\"Création](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-distance/02_creer-la-ligne.png\")
Pour finir, double-cliquez à l’endroit où vous souhaitez terminer la ligne (attention : cliquer sur le point précédent ou à un endroit très proche finira également la ligne). Cela figera la ligne, et vous pourrez en créer une nouvelle de la même façon :
\n![\"Finalisation](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-distance/03_finaliser-la-ligne.png\")
Vous pouvez vous déplacer sur la carte pendant la création de la ligne en restant appuyé sur le clic gauche et en déplaçant le curseur.
\nPar contre si vous cliquez sur un autre outil, vous sortirez de « Mesurer une distance » et les lignes créées disparaîtront.
L’outil « Mesurer une surface » permet de dessiner une zone sur la carte et d’en connaître en temps réel la surface.
\nCliquez sur l’icône de l’outil :
\n![\"Icône](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-surface/01_mesurer-une-surface.png\")
Vous pouvez alors cliquer sur la carte pour commencer à créer la zone. Chaque nouveau clic permet d’ajouter un sommet supplémentaire à la zone :
\n![\"Création](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-surface/02_creer-la-surface.png\")
Pour finir, double-cliquez à l’endroit où vous souhaitez terminer la zone (attention : cliquer sur le point précédent ou à un endroit très proche finira également la zone). Cela figera la surface, et vous pourrez en créer une nouvelle de la même façon :
\n![\"Finalisation](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-une-surface/03_finaliser-la-surface.png\")
Vous pouvez vous déplacer sur la carte pendant la création de la surface en restant appuyé sur le clic gauche et en déplaçant le curseur.
\nPar contre si vous cliquez sur un autre outil, vous sortirez de « Mesurer une surface » et les zones créées disparaîtront.
L’outil « Mesurer un angle » permet de dessiner une ligne sur la carte et de connaître son angle par rapport au Nord géographique.
\nCliquez sur l’icône de l’outil :
\n![\"Icône](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-un-angle/01_mesurer-un-angle.png\")
Vous pouvez alors cliquer sur la carte pour commencer à créer la ligne :
\n![\"Création](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-un-angle/02_commencer-la-ligne.png\")
Cliquez une seconde fois pour finir la ligne. Cela figera la ligne, et vous pourrez en créer une nouvelle de la même façon :
\n![\"Finalisation](\"https://cartes.gouv.fr/aide/img/guides-utilisateur/visualiseur-cartographique/utiliser-les-outils-de-mesure/mesurer-un-angle/03_terminer-la-ligne.png\")
Vous pouvez vous déplacer sur la carte pendant la création de la ligne en restant appuyé sur le clic gauche et en déplaçant le curseur.
\nPar contre si vous cliquez sur un autre outil, vous sortirez de « Mesurer un angle » et les lignes créées disparaîtront.
Cette étape supplémentaire permet une diffusion à plus grande échelle de données vecteur. Seules les parties nouvelles sont détaillées.
\nhttps://data.geopf.fr/api/datastores/{datastore}/processings[\n {\n \"name\": \"Intégration de données vecteur livrées en base\",\n \"description\": \"Ce traitement permet de stocker dans les bases de données PostgreSQL de la plateforme des données vecteur livrées. Les formats pris en charge sont le CSV, le Shapefile, le Geopackage et le GeoJSON. Il est également possible de préciser un autre système afin de réaliser une reprojection à l'intégration\",\n \"_id\": \"0de8c60b-9938-4be9-aa36-9026b77c3c96\"\n },\n {\n \"name\": \"Recopie d'une archive livrée\",\n \"description\": \"Génération ou mise à jour d'une donnée stockée ARCHIVE à partir d'une archive livrées. Si un fichier livré existait déjà dans la donnée en sortie, celui ci va écraser l'ancienne version\",\n \"_id\": \"12cdc646-3976-4f18-b273-f34fca37e2a6\"\n },\n {\n \"name\": \"Calcul de pyramide raster\",\n \"description\": \"Génération ou mise à jour d'une pyramide de tuiles raster à partir d'une livraison d'images géo-référencées\",\n \"_id\": \"2ae50661-986c-4f47-a3f0-e380417b522c\"\n },\n {\n \"name\": \"Calcul ou mise à jour de pyramide raster par moissonnage WMS\",\n \"description\": \"Il n'y a pas besoin de donnée en entrée. Sont fournis en paramètres toutes les informations sur le service WMS et le jeu de données à moissonner, ainsi que la zone sur laquelle faire le moissonnage\",\n \"_id\": \"6a54dc92-fc93-4c8e-9f02-046bf889550e\"\n },\n {\n \"name\": \"Fusion de pyramides raster\",\n \"description\": \"Ce traitement permet de générer une pyramide raster par composition de plusieurs pyramides indépendantes. Seules les dalles présentes dans plusieurs entrées seront recalculées. Celles présentes dans une seule entrée seront référencées. La pyramide en sortie a donc des dépendances avec celles en entrée.\",\n \"_id\": \"7cdca031-9e86-4804-8764-9b1d783b087d\"\n },\n {\n \"name\": \"Calcul de pyramide vecteur\",\n \"description\": \"Génération ou mise à jour d'une pyramide de tuiles vectorielles à partir d'une donnée vecteur en base\",\n \"_id\": \"aa5f9391-0bdb-4b97-9209-fcde351b82f6\"\n }\n]\nhttps://data.geopf.fr/api/datastores/{datastore}/processings/aa5f9391-0bdb-4b97-9209-fcde351b82f6{\n \"name\": \"Calcul de pyramide vecteur\",\n \"description\": \"Génération ou mise à jour d’une pyramide de tuiles vectorielles à partir d’une donnée vecteur en base\",\n \"input_types\": {\n \"upload\": [],\n \"stored_data\": [\"VECTOR-DB\", \"ROK4-PYRAMID-VECTOR\"]\n },\n \"output_type\": {\n \"stored_data\": \"ROK4-PYRAMID-VECTOR\",\n \"storage\": [\"S3\"]\n },\n \"parameters\": [\n {\n \"name\": \"composition\",\n \"description\": \"Tables à exporter et niveaux limites d’utilisation\",\n \"mandatory\": false,\n \"constraints\": {\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"required\": [\"table\", \"bottom_level\", \"top_level\"],\n \"properties\": {\n \"layer\": {\n \"type\": \"string\"\n },\n \"table\": {\n \"type\": \"string\"\n },\n \"filter\": {\n \"type\": \"string\"\n },\n \"top_level\": {\n \"type\": \"string\"\n },\n \"attributes\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"bottom_level\": {\n \"type\": \"string\"\n }\n }\n }\n },\n {\n \"name\": \"bottom_level\",\n \"description\": \"Niveau du bas de la pyramide (obligatoire si pas de composition fournie)\",\n \"mandatory\": false\n },\n {\n \"name\": \"width\",\n \"description\": \"Nombre de tuiles dans une dalle, dans le sens de la largeur\",\n \"mandatory\": false,\n \"default_value\": 16\n },\n {\n \"name\": \"top_level\",\n \"description\": \"Niveau du haut de la pyramide (obligatoire si pas de composition fournie)\",\n \"mandatory\": false\n },\n {\n \"name\": \"tippecanoe_options\",\n \"description\": \"Options de l’outil tippecanoe pour la généralisation des données vecteur\",\n \"mandatory\": false\n },\n {\n \"name\": \"area\",\n \"description\": \"WKT de la zone sur laquelle le moissonnage doit se faire, en EPSG:4326 (obligatoire si la base vecteur en entrée n’a pas d’étendue)\",\n \"mandatory\": false\n },\n {\n \"name\": \"height\",\n \"description\": \"Nombre de tuiles dans une dalle, dans le sens de la hauteur\",\n \"mandatory\": false,\n \"default_value\": 16\n },\n {\n \"name\": \"parallelization\",\n \"description\": \"Nombre de scripts d’écriture des dalles en parallèle\",\n \"mandatory\": false,\n \"default_value\": 1\n }\n ],\n \"_id\": \"aa5f9391-0bdb-4b97-9209-fcde351b82f6\",\n \"required_checks\": []\n}Les niveaux sur lesquels on transforme les données vecteur en tuiles vectorielles sont importants : en calculant un niveau trop résolu (trop bas), le temps de génération et le volume occupé par la pyramide en sortie sera inutilement grand. En utilisant une table volumineuse dans des niveaux trop hauts, les tuiles seront très lourdes car contenant trop de données (ou vidées de la majorité des objets). Il faut donc prêter une attention particulière aux niveaux d’utilisation des tables.
\nDans notre exemple ici, on choisit un cas simple : les pays sont présents dans tous les niveaux, et les écorégions ne seront présentes que jusqu’au niveau 5. On ne filtre pas les données et on ne change pas les noms des tables dans les tuiles. On veut tous les attributs.
\n\nhttps://data.geopf.fr/api/datastores/{datastore}/processings/executions{\n \"processing\": \"aa5f9391-0bdb-4b97-9209-fcde351b82f6\",\n \"inputs\": {\n \"stored_data\": [\"{stored data}\"]\n },\n \"output\": {\n \"stored_data\": {\n \"name\": \"Pays et éco-régions\",\n \"storage_tags\": [\"PYRAMIDE\"]\n }\n },\n \"parameters\": {\n \"composition\": [\n {\n \"table\": \"ecoregions\",\n \"bottom_level\": \"9\",\n \"top_level\": \"5\",\n \"attributes\": [\"*\"]\n },\n {\n \"table\": \"pays\",\n \"bottom_level\": \"9\",\n \"top_level\": \"0\",\n \"attributes\": [\"*\"]\n }\n ]\n }\n}Description des paramètres en entrée :
\ninputs/stored_data : Il s’agit ici d’une liste (présence des caractères « [ ] ») qui prend comme valeur au moins un identifiant entrepôt de stored_data de type VECTOR-DB (voir étape précédente)
output/stored_data/name : Le nom défini ici est un nommage libre.
Cette information n’est lisible que par un autre utilisateur membre de cet entrepôt, pas par l’utilisateur final. Vous êtes donc invité à renseigner ici des informations parlantes pour vous - producteur de donnée.
\nCette information est modifiable après coup.
\noutput/stored_data/storage_tags : Il s’agit ici d’une liste (présence des caractères « [ ] ») qui prend comme valeur au moins un tag associé au stockage qui va accueillir la donnée de sortie.
Vous pouvez retrouver ces tags via la route GET /datastores/{datastore}/storages (rubrique Entrepôt du swagger) dans l’attribut de réponse labels associé à chaque stockage.
Pour une donnée de type tuiles vecteur pré-calculées en sortie, seul le stockage S3 est accessible, ce qui correspond au label, donc au storage_tag : PYRAMIDE.
parameters : C’est là que toute la configuration du traitement prend corps :
composition : Définit les couches qui vont être tuilées avec pour chaque couche :\ntable : Le nom technique de la relation à tuiler, tel que défini dans la stored_data.layer : Le nom technique de la relation telle qu’elle sera présentée dans le flux. Paramètre optionnel, utile à définir en cas de renommage.filter : Critère de filtrage pour ne diffuser que le objets correspondant au critère de filtrage. Utilisez une syntaxe de type PostgreSQL : "filter": "mon_champ='ma valeur'".top_level : Niveau haut (le plus dézoomé, le chiffre le plus faible) de la pyramide auquel la couche sera tuilée et donc visible.bottom_level : Niveau bas (le plus zoomé, le chiffre le plus grand) de la pyramide auquel la couche sera tuilée et donc visible.attributes : Liste des attributs, entre doubles quotes et séparés par des virgules à diffuser dans le flux. Pour diffuser tous les attributs, déclarez le caractère « * » .top_level : Niveau haut (le plus dézoomé, le chiffre le plus faible) de la pyramide auquel la couche sera tuilée et donc visible. Permet de définir un niveau global à l’ensemble de la pyramide.\nCe paramètre est obligatoire s’il n’est pas défini pour chaque table dans la composition.
\nS’il est précisé en plus de la composition, il est préférable d’adopter une valeur cohérente au regard de celles définies dans la composition : à savoir égale au plus grand top_level de la composition.
bottom_level : Niveau bas (le plus zoomé, le chiffre le plus grand) de la pyramide auquel la couche sera tuilée et donc visible. Permet de définir un niveau global à l’ensemble de la pyramide.\nCe paramètre est obligatoire s’il n’est pas défini pour chaque table dans la composition.
\nS’il est précisé en plus de la composition, il est préférable d’adopter une valeur cohérente au regard de celles définies dans la composition : à savoir égale au plus petit bottom_level de la composition.
area : WKT de la zone sur laquelle le moissonnage doit se faire, en EPSG:4326. Ce paramètre est obligatoire si la base vecteur en entrée n’a pas d’étendue et est utile si la donnée est disséminée à travers le globe (France + DOM par exemple).tippecanoe_options : Plus d’informations sur ces options et leur syntaxe peuvent être trouvées sur la documentation de l’outil.\nLa caractéristique à retenir d’une tuile vectorielle générée avec Tippecanoe est qu’elle ne peut contenir plus de 5 000 objets, et ce quelle que soit la tuile ou son niveau.
\nC’est la première cause d’échec de traitement par les utilisateurs
\nLes options sont donc essentielles pour adapter le jeu de donnée en entrée à cette contrainte. Elles proposent différentes méthodes de généralisation à petite échelle pour assurer une représentation fiable de la donnée tout en limitant le nombre d’objets par tuile.
\nVous êtes invités à vous référer au swagger pour avoir les détails et options complètes sur cette partie.
\n\nComme pour la livraison il vous est possible de configurer l’envoi d’un courriel automatique à la fin du traitement.
\nPour ce faire, il suffit d’ajouter l’élément JSON ci-dessous après l’élément parameters dans le corps de requête de déclaration d’exécution.
\"callback\": {\n \"type\": \"email\",\n \"to_address\": [\n \"example@mail.fr\"\n ]\n}À la fin du traitement, des informations concernant la donnée finale sont remontées afin d’apparaître au niveau de l’API (taille, étendue, système de coordonnées, grille et niveaux).
\n\nhttps://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored data pyramide}{\n \"name\": \"Pays et éco-régions\",\n \"type\": \"ROK4-PYRAMID-VECTOR\",\n \"srs\": \"EPSG:3857\",\n \"contact\": \"contact@ign.fr\",\n \"extent\": {\n \"type\": \"Polygon\",\n \"coordinates\": [\n [\n [175, -85],\n [175, 83.623596],\n [-175, 83.623596],\n [-175, -85],\n [175, -85]\n ]\n ]\n },\n \"last_event\": {\n \"title\": \"Génération\",\n \"date\": \"2023-07-12T09:04:07.271074\",\n \"initiator\": {\n \"_id\": \"{user}\"\n }\n },\n \"tags\": {},\n \"storage\": {\n \"type\": \"S3\",\n \"labels\": []\n },\n \"size\": 79570364,\n \"status\": \"GENERATED\",\n \"_id\": \"{stored data pyramide}\",\n \"type_infos\": {\n \"tms\": \"PM\",\n \"levels\": [\"0\", \"1\", \"2\", \"3\", \"4\", \"5\", \"6\", \"7\", \"8\", \"9\"]\n }\n}Dès le lancement de l’exécution du traitement, dans le corps de réponse ou à chaque interrogation de la requête d’état d’exécution vous disposez dans le corps de réponse de ces requêtes de l’élément JSON :
\n\"output\": {\n \"stored_data\": {\n \"name\": \"Pays et éco-régions\",\n \"type\": \"ROK4-PYRAMID-VECTOR\",\n \"status\": \"GENERATING\",\n \"_id\": \"{stored data}\"\n }\n}Ce qui vous donne l’élément _id à isoler pour identifier ensuite votre stored_data de sortie.
La stored_data de sortie n’est exploitable et interrogeable qu’une fois l’exécution du traitement terminée avec succès.
Les données de la pyramide de tuiles vectorielles sont diffusables selon l’API Tile Map Service. Cette API est disponible sur un point d’accès de type WMTS-TMS.
https://data.geopf.fr/api/datastores/{datastore}/configurations{\n \"type\": \"WMTS-TMS\",\n \"name\": \"Pays et écorégions\",\n \"layer_name\": \"pays_ecoregions\",\n \"type_infos\": {\n \"title\": \"Mes écorégions\",\n \"abstract\": \"Grandes régions naturelles mondiales\",\n \"used_data\": [\n {\n \"bottom_level\": \"9\",\n \"top_level\": \"0\",\n \"stored_data\": \"{stored data}\"\n }\n ]\n }\n}La donnée n’est pas représentée côté serveur, il n’y a donc pas de fichier de style à préciser au niveau de la configuration.
\nhttps://data.geopf.fr/api/datastores/{datastore}[\n {\n \"name\": \"Service de diffusion WFS principal\",\n \"technical_name\": \"gpf-geoserver-wfs\",\n \"type\": \"WFS\",\n \"urls\": [\n {\n \"type\": \"WFS\",\n \"url\": \"https://data.geopf.fr/wfs/geoserver/ows\"\n }\n ],\n \"_id\": \"ae012611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-geoserver-wfs\"\n },\n {\n \"name\": \"Service de diffusion WMTS/TMS principal\",\n \"technical_name\": \"gpf-rok4-server-wmts-tms\",\n \"type\": \"WMTS-TMS\",\n \"urls\": [\n {\n \"type\": \"WMTS\",\n \"url\": \"https://data.geopf.fr/wmts\"\n },\n {\n \"type\": \"TMS\",\n \"url\": \"https://data.geopf.fr/tms/\"\n }\n ],\n \"_id\": \"ae032611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-rok4-server-wmts-tms\"\n },\n {\n \"name\": \"Service de diffusion WMS Raster principal\",\n \"technical_name\": \"gpf-rok4-server-wms-r\",\n \"type\": \"WMS-RASTER\",\n \"urls\": [\n {\n \"type\": \"WMS\",\n \"url\": \"https://data.geopf.fr/wms-r/wms\"\n }\n ],\n \"_id\": \"ae042611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-rok4-server-wms-r\"\n },\n {\n \"name\": \"Service de diffusion WMS Vecteur principal\",\n \"technical_name\": \"gpf-geoserver-wms-v\",\n \"type\": \"WMS-VECTOR\",\n \"urls\": [\n {\n \"type\": \"WMS\",\n \"url\": \"https://data.geopf.fr/wms-v/geoserver/ows\"\n }\n ],\n \"_id\": \"ae022611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-geoserver-wms-v\"\n },\n {\n \"name\": \"Service de Téléchargement principal\",\n \"technical_name\": \"gpf-download\",\n \"type\": \"DOWNLOAD\",\n \"urls\": [\n {\n \"type\": \"DOWNLOAD\",\n \"url\": \"https://data.geopf.fr/telechargement/\"\n }\n ],\n \"_id\": \"ae052611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-download\"\n },\n {\n \"name\": \"Service de diffusion CSW\",\n \"technical_name\": \"gpf-geonetwork\",\n \"type\": \"METADATA\",\n \"urls\": [\n {\n \"type\": \"METADATA\",\n \"url\": \"https://data.geopf.fr/csw\"\n }\n ],\n \"_id\": \"ae062611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true,\n \"metadata_fi\": \"gpf-geonetwork\"\n },\n {\n \"name\": \"Service de téléchargement private\",\n \"technical_name\": \"gpf-download-private\",\n \"type\": \"DOWNLOAD\",\n \"urls\": [\n {\n \"type\": \"DOWNLOAD\",\n \"url\": \"https://data.geopf.fr/private/telechargement/\"\n }\n ],\n \"_id\": \"b5bf7ab2-8998-4829-8c80-cd2ec02e6e58\",\n \"open\": false,\n \"metadata_fi\": \"gpf-download-private\"\n },\n {\n \"name\": \"Service de diffusion WFS privé\",\n \"technical_name\": \"gpf-geoserver-wfs-private\",\n \"type\": \"WFS\",\n \"urls\": [\n {\n \"type\": \"WFS\",\n \"url\": \"https://data.geopf.fr/private/wfs/\"\n }\n ],\n \"_id\": \"d02feec9-1169-403f-bfc3-7ba6d6015ed4\",\n \"open\": false,\n \"metadata_fi\": \"gpf-geoserver-wfs-private\"\n },\n {\n \"name\": \"Service de diffusion WMS Vecteur privé\",\n \"technical_name\": \"gpf-geoserver-wms-v-private\",\n \"type\": \"WMS-VECTOR\",\n \"urls\": [\n {\n \"type\": \"WMS\",\n \"url\": \"https://data.geopf.fr/private/wms-v/\"\n }\n ],\n \"_id\": \"519c8bb1-9b7f-414a-9850-1a73dfd467ed\",\n \"open\": false,\n \"metadata_fi\": \"gpf-geoserver-wms-v-private\"\n },\n {\n \"name\": \"Service de diffusion WMS Raster privé\",\n \"technical_name\": \"gpf-rok4-server-wms-r-private\",\n \"type\": \"WMS-RASTER\",\n \"urls\": [\n {\n \"type\": \"WMS\",\n \"url\": \"https://data.geopf.fr/private/wms-r/\"\n }\n ],\n \"_id\": \"66866100-48eb-4340-bbc9-f5c7d9707928\",\n \"open\": false,\n \"metadata_fi\": \"gpf-rok4-server-wms-r-private\"\n },\n {\n \"name\": \"Service de diffusion WMTS/TMS privé\",\n \"technical_name\": \"gpf-rok4-server-wmts-tms-private\",\n \"type\": \"WMTS-TMS\",\n \"urls\": [\n {\n \"type\": \"TMS\",\n \"url\": \"https://data.geopf.fr/private/tms/\"\n },\n {\n \"type\": \"WMTS\",\n \"url\": \"https://data.geopf.fr/private/wmts/\"\n }\n ],\n \"_id\": \"7e0a92d1-8213-4ce0-8903-eb4c305a1849\",\n \"open\": false,\n \"metadata_fi\": \"gpf-rok4-server-wmts-tms-private\"\n }\n]\nCette étape est l’étape clé pour décider si le flux que vous vous apprêtez à publier va être publié en open data ou au contraire seulement aux utilisateurs accrédités. Dans l’écosystème Géoplateforme on appelle ce dernier mode, le mode privé.
\nSi vous souhaitez publier en open data, vous allez chercher, dans la réponse ci-dessus, un endpoint du type de la configuration créée (pour le tutoriel, WMTS-TMS) dont l’élément open est à true.
Si vous souhaitez publier en mode privé, vous allez chercher, dans la réponse ci-dessus, un endpoint du type de la configuration créée (pour le tutoriel, WMTS-TMS) dont l’élément open est à false.
Le tutoriel est déroulé en mode open data. Pour accéder à une donnée publiée en privé, référez vous au tutoriel sur le contrôle des accès.
\nhttps://data.geopf.fr/api/datastores/{datastore}/configurations/{configuration wmts-tms}/offerings{\n \"endpoint\": \"ae032611-13eb-4a18-8d04-9b7604a031cc\",\n \"open\": true\n}L’exemple ci-dessus présente une publication en mode open data.
\nSi vous choisissez de publier en mode privé, le corps de requête sera :
\n{\n \"endpoint\": \"7e0a92d1-8213-4ce0-8903-eb4c305a1849\",\n \"open\": false\n}Pour accéder à une donnée publiée en privé, référez vous au tutoriel sur le contrôle des accès.
\nOn peut vérifier la présence de notre couche pays_ecoregions dans le GetCapabilities du service TMS. On peut également avoir des détails sur cette couche.
On peut également récupérer nos données dans QGIS. Il faut ajouter une source de donnée « Tuile vectorielle » et préciser comme URL https://data.geopf.fr/tms/1.0.0/pays_ecoregions/{z}/{x}/{y}.pbf
L’affichage des tuiles vectorielles implique l’application d’un style côté client. Il suffit donc de fournir un style accessible pour faciliter la consommation de telles données. On va exploiter la fonctionnalité des annexes pour mettre à disposition une URL publique pour un tel style.
\nCe style d’exemple est au format Mapbox.
\n\nhttps://data.geopf.fr/api/datastores/{datastore}/annexes| Corps de requête Multipart |
|---|
| file = <pays_ecoregions.json> |
| paths = styles/mapbox/pays_ecoregions.json |
| published = true |
{\n \"paths\": [\"/styles/mapbox/pays_ecoregions.json\"],\n \"size\": 10768,\n \"mime_type\": \"application/json\",\n \"published\": true,\n \"_id\": \"{annexe}\"\n}Nous avons demandé à ce que cette annexe soit directement publiée. Nous pouvons donc maintenant y accéder publiquement. On va pouvoir définir une couche « Tuile vectorielle » dans QGIS, en précisant la source des tuiles et l’URL du style :
\nhttps://data.geopf.fr/tms/1.0.0/pays_ecoregions/{z}/{x}/{y}.pbfhttps://data.geopf.fr/annexes/{technical_name}/styles/mapbox/pays_ecoregions.json![\"Définition](\"https://cartes.gouv.fr/aide/img/guides-developpeur/vecteur/alimentation-diffusion/qgis_tms_definition.png\")
En zoomant en dessous du niveau 5, on voit bien nos régions écologiques et les limites des pays, avec le style mis en ligne.
\n![\"Visualisation](\"https://cartes.gouv.fr/aide/img/guides-developpeur/vecteur/alimentation-diffusion/qgis_tms_visualisation.png\")