documentation

Le service d’extraction vecteur de la Géoplatefome est disponible au travers d’une API REST répondant au standard OGC API Processes.

Il permet à un utilisateur authentifié de le Géoplateforme de réaliser un export de donnée 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 faire l’export. 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.

La liste des données extractible est conditionnée à l’utilisateur connecté. Ce dernier peut disposer de données accessibles à l’ensemble des utilisateurs de la Geoplateforme 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.

Le 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.

L’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 de récréation de ce lot de donnée à votre périmètre de travail est plus rapide à mettre en œuvre via le service d’extraction.

Par exemple :

• Vous travaillez pour un EPCI qui est à cheval sur 2 ou 3 départements et vous souhaitez télécharger la BD TOPO® de votre territoire : il sera plus rapide de réaliser l’extraction de la BD TOPO® à l’emprise de votre territoire que de télécharger les 3 départements complets pour ne conserver que les quelques communes qui vous intéressent.
• Vous travaillez à l’échelle d’une région et le lot de données qui vous intéresse n’est disponible qu’au niveau départemental : il est vraisemblablement plus intéressant de continuer à utiliser le service de téléchargement en récupérant chaque département pour les agréger ensuite localement.

La documentation swagger permettant d’accéder aux détails des routes et paramètres pour réaliser une extraction vecteur est accessible ici :

• Pour l’API Entrepôt (partie « Accéder aux ressources extractibles » et « Pour un producteur de données ») : https://data.geopf.fr/api/swagger-ui/index.html
• Pour l’API Extraction vecteur (le reste de cette documentation) : https://data.geopf.fr/extraction/swagger-ui/index.html

Chaque 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.

Par ailleurs le service est configuré de telle sorte que, pour l’ensemble des utilisateurs déclenchant une extraction, 20 extractions peuvent tourner en simultanée. 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.

Capabilities

L’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 urls de niveau immédiatement inférieur :

• Lien vers le swagger
• Lien vers l’url de conformité
• Lien vers la liste des process d’extraction
• Lien vers la liste des travaux d’extraction

Conformance

L’url de conformance (ou conformité) renvoie vers les pages des différentes parties du standard ogc avec lesquelles cette API est conforme.

L’accès à cette information n’est pas strictement nécessaire à l’exécution d’une extraction vecteur.

Pour connaitre la liste des données qui lui sont acessibles en extraction, un utilisateur dispose de deux routes API entrepôt :

• GET 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ères.
• GET https://data.geopf.fr/api/users/me/stored_data/{stored_data} : A 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ée.

Pour l’ensemble des paramètres et valeurs de ces paramètre vous êtes invités à consulter le swagger.

Néanmoins, ces routes ayants des usages qui vont au-delà de la seule API extraction, on va faire ici un zoom sur quelques paramètres qui peuvent être mobilisés à bon compte pour faciliter l’identification d’une ressource à extraire.

Paramètres et valeur(s) d’intérêt pour identifier une donnée extractible

Les paramètres qu’on mentionne ici sont exclusivement à mobiliser dans la requête :

GET https://data.geopf.fr/api/users/me/stored_data

Ils sont listés dans l’ordre d’apparition dans le swagger.

• « type » + valeur « 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 » pour 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ôts, 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.

Attributs d’intérêt d’une donnée extractible pour préparer l’extraction

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) :

{
  "creation": "2025-09-03T14:14:23.666532Z",
  "name": "Pays et écorégions",
  "type": "VECTOR-DB",
  "open": false,
  "srs": "EPSG:4326",
  "contact": "email",
  "extent": {
    "geometry": {
      "type": "MultiPolygon",
      "coordinates": [
        ... une série de coordonnées en WGS84...
          ]
        ]
      ]
    },
    "type": "Feature"
  },
  "size": 9912320,
  "status": "GENERATED",
  "_id": "c746ce1d-e38c-42c4-a9a3-ef34d5bbea40",
  "type_infos": {
    "relations": [
      {
        "name": "ecoregions",
        "type": "TABLE",
        "attributes": {
          "id": "integer",
          "fid": "bigint",
          "nnh": "integer",
          "geom": "geometry(MultiPolygon,4326)",
          "color": "character varying",
          "realm": "character varying",
          ...
        },
        "primary_key": [
          "ogc_fid"
        ]
      },
      {
        "name": "pays",
        "type": "TABLE",
        "attributes": {
          "id": "integer",
          "un": "integer",
          "fid": "bigint",
          "lat": "double precision",
          ...
        },
        "primary_key": [
          "ogc_fid"
        ]
      }
    ]
  }
}

Parmi les attributs en résultat certains sont particulièrement utiles pour préparer son extraction.

Ces attributs intéressants, sont listés ci-dessous dans l’ordre dans lequel on les trouve dans la réponse :

• « srs » : Donne le code EPSG de la projection des données qu’on va extraire. Cette information est particulièrement utile dans le cas où on prévoit d’employer un filtre spatial. En effet 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.
• « extent » : 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 » / « relations » : C’est le cœur de la réponse qui va nous intéresser pour préparer l’export puisque c’est dans cette partie qu’on va trouver la liste de tables exportables :
  • Attribut « name » : « une_valeur ». Le nom de la table sera systématiquement en minuscule et sans espace ni caractères spéciaux.
  • Attribut « attributes » : 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 :

GET https://data.geopf.fr/extraction/processes

On récupère une liste de processus d’extraction décrits par :

• Un « _id » identifiant de manière unique un processus d’extraction lié à une donnée particulière.
• Un « title » mentionnant « Extraction Vecteur depuis » + l’attribut « name » de la donnée extractible identifiée plus haut.
• Une « description » reprenant la description de la donnée extractible identifiée plus haut.
• Un ensemble de deux « 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é.
• Restent deux attributs propres au standard API Processes : "outputTransmission", "jobControlOptions" de type tableau et qui vaudront toujours respectivement "reference" et "async-execute"

L’information clé à extraire ici est la valeur de bon « _id » qui correspond à celui de la donnée qu’on souhaite extraire.

Or un « _id » est toujours composé de la même manière : « _id du traitement générique d’extraction » _ « _id 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’id de l’extraction en accolant « 8ab6236b-21d8-471a-a07b-f84a5921f9f5 » puis « _ » puis « _id de la donnée d’intérêt ».

Sur l’API d’extraction Vecteur, la route est :

GET https://data.geopf.fr/extraction/processes/{processID}

Permet d’obtenir, en plus des informations précédentes, les informations suivantes :

• « version » : 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’info à retenir ici est qu’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, la 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.

Première remarque : la configuration de l’extraction et son déclenchement se font en un seul et même appel API via la route :

POST 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.

On trouvera au-dessous de ce corps de requête type, un descriptif détaillé et exhaustif des différents paramètres et leur contenu.

{
	"inputs": {
		"relations": {
			"table_1" : { 
				"attributes" : [ 
                                                                 "attribut1",									                       "attribut2",										         "attribut3",
                                                                    ...,										                        "attribut_geometrie"
				],
				"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'" 
			},
			"table_2" : { 
				"attributes" : [
                                                                "attribut1",
                                                                "attribut2",
                                                                "attribut3",
                                                                  ...,
				       "attribut_geometrie"
				 ],
				"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))" 
			}
		},
		"format": "GPKG",
                            "append": true,
                            "compression" :"7zip",
		"srs" :"EPSG:3857",
		"lifetime" : 336
	},
	"outputs": {
		"logs": {},
		"summary": {},
		"extractedData": {}
	}
}

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" : { 
    				"attributes" :[ une liste nommant les attributs qu’on veut conserver
    						 ],
    				"filters" : "syntaxe de filtrage" 
    			}
    

    • Le nom technique de la table et la liste des attributs, pour rappel est identifié via la rubrique Accéder aux ressources extractibles et obtenir les infos clés (nom des tables, projection, structure attributaire)
    • La liste des « attributes » débute par un [ et se termine par un ]. Elle reprend le nom technique de chaque attribut, entre doubles quotes, chaque attribut étant séparé sur précédent par une virgule.
      Si on souhaite exporter tous les attributs, on doit mentionner explicitement chaque attribut.
      La syntaxe SQL 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.
    • Le 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.
      L’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 : 12 et de Postgis : 3.3.

Nous attirons l’attention sur le fait que plus le critère de filtrage est complexe, plus l’export sera long. Nous invitons donc chaque utilisateur à mesurer la complexité de ses critères de filtrage en recherchant l’optimisation de chaque processus.

• Le paramètre « format » précise le format d’export des données. Seuls sont autorisées les valeurs entre doubles quotes suivantes :
  • « GPKG » (Geopackage)
  • « GML » (Google Markup Language)
  • « GEOJSON »
  • « ESRI SHAPEFILE »
  • « PARQUET » (Géoparquet)
  • « PGDUMP » (Format de sauvegarde Postgresql/Postgis compatible avec les utilitaires de remontée ne 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.
• Le paramètre « append » doit se comprendre comme combiné (et donc dépendant) du 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. A 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 Geoplateforme. 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ée 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.

A noter : 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 ?... 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. Dit autrement il est possible que la clause de filtrage que l’utilisateur va déterminer déclenche un export vide.

En retour de l’exécution de la requête d’extraction, l’utilisateur reçoit une réponse du type :

{
	"jobID": "d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db",
	"status": "running",
	"message": "Extraction des données demandées en cours",
	"created": "2025-10-13T14:55:07.278666682Z",
	"updated": "2025-10-13T14:55:07.278666682Z",
	"links": [
		{
			"rel": "describedBy",
			"type": "application/json",
			"title": "Job d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db",
			"href": "/jobs/d9f4c2d7-c73c-405c-9a8c-c33e6f29c9db"
		}
	],
	"started": "2025-10-13T14:55:07.278666682Z",
	"processID": "8ab6236b-21d8-471a-a07b-f84a5921f9f5_50edff37-30c7-4ce6-8a4a-8ca960a43974",
	"type": "process"
}

• « jobID » : Cette information doit être conservée pour suivre l’exécution du traitement et récupérer les résultats (voir plus bas).
• « status » : Donne l’état de déroulement du traitement. En sortie d’exécution le statut prendra la valeur « running ».
• « message » : Donne en texte clair l’état du traitement. Ce message est seulement disponible en français.
• « created », « updated » et « started » : Des informations d’horodatage de déclenchement du traitement et de lancement concrète de l’exécution du traitement.
• « links » : Donne le lien vers la route d’API qui permet de suivre l’exécution du traitement.
• « processID » : Rappel de l’identifiant du process d’exécution qui a été mobilisé pour l’export.
• « type » : Information relative au standard OGC, toujours de valeur « process ».

Une 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 :

GET 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 :

{
	"jobID": "38d43c19-d974-42ba-9d9b-11cf524b5b61",
	"status": "failed",
	"message": "Erreur lors de l'extraction des données",
	"created": "2025-11-25T13:37:20.845151Z",
	"finished": "2025-11-25T13:40:27.769106Z",
	"updated": "2025-11-25T13:40:28.459020Z",
	"links": [
		{
			"rel": "self",
			"type": "application/json",
			"title": "Job 38d43c19-d974-42ba-9d9b-11cf524b5b61",
			"href": "/jobs/38d43c19-d974-42ba-9d9b-11cf524b5b61"
		},
		{
			"rel": "describedBy",
			"type": "application/json",
			"title": "Résultats du job 38d43c19-d974-42ba-9d9b-11cf524b5b61",
			"href": "/jobs/38d43c19-d974-42ba-9d9b-11cf524b5b61/results"
		}
	],
	"started": "2025-11-25T13:37:20.845151Z",
	"processID": "8ab6236b-21d8-471a-a07b-f84a5921f9f5_50edff37-30c7-4ce6-8a4a-8ca960a43974",
	"type": "process"
}

En plus des informations détaillées à l’étape précédente on retrouve :

• « finished » : Elé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 extraction.
• « status » a évolué soit vers une valeur « successful » soit vers une valeur « failed ».
• Dans « links » : On retrouve 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’échec.

Une fois le traitement terminé à l’étape précédente, on peut donc exécuter la route d’obtention des résultats via :

GET https://data.geopf.fr/extraction/jobs/{jobID}/results

On reçoit alors un retour du type :

{
	"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\"]",
	"summary": {
		"rel": "describedBy",
		"type": "application/json",
		"title": "Informations sur le processus d'extraction",
		"href": "https://data.geopf.fr/extraction/telechargement/download/extraction_b1f8cdc1-7dd3-4536-a4aa-d484c8023878/data/extraction.json"
	},
	"extractData": {
		"rel": "describedBy",
		"type": "application/atom+xml",
		"title": "Résultats du processus d'extraction",
		"href": "https://data.geopf.fr/extraction/telechargement/resource/extraction_b1f8cdc1-7dd3-4536-a4aa-d484c8023878/data"
	}
}

• « 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.

Retrouver une extraction

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 :

GET https://data.geopf.fr/extraction/jobs

Cette recherche est filtrable par :

• Une liste d’identifiants de processes.
• Une liste de statuts d’exécution du traitement.
• Une date et heure ou un intervalle de date au format ISO 8601 sur lequel le traitement s’est exécuté. En ce qui concerne la syntaxe attendue pour le filtrage de date, on a :
  • Pour une seule date, il faut fournir une valeur du type AAAA-MM-JJTHH:mm:ss.00Z
  • Pour un intervalle la syntaxe sera AAAA-MM-JJTHH:mm:ss.00Z/AAAA-MM-JJTHH:mm:ss.00Z en notant que l’intervalle peut être ouvert des deux côté en remplaçant la date par « .. » ce qui donne AAAA-MM-JJTHH:mm:ss.00Z/.. : pour trouver les exécution lancées après telle date ou ../ AAAA-MM-JJTHH:mm:ss.00Z pour les exécutions avant telle date.
• Une durée minimale ou maximale de traitement (fournie en seconde).
• Comme toute route d’API Geoplateforme, les résultats sont paginés : Première page à 1, limite d’éléments par page à 10 par défaut, 50 maximum. On récupère en résultat, pour un traitement, le même retour que celui décrit dans « Suivre le déroulé de l’extraction ».

Stopper une extraction en cours

En cas de nécessité, un utilisateur peut stopper l’exécution d’un traitement via la route :

DELETE https://data.geopf.fr/extraction/jobs/{jobID}

L’ensemble des résultats liés éventuellement à ce traitement sont supprimés.

Le quota d’extraction disponible à l’utilisateur est instantanément libéré.

Une 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ée 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.

Dans 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 Geoplateforme si vous souhaitez en savoir plus à ce sujet.

Rendre une donnée extractible via l’API d’extraction vecteur à tous les utilisateurs

Pour rendre une donnée extractible à l’ensemble des utilisateurs Géoplateforme, le producteur de donnée doit ouvrir la stored_data de type VECTROR-DB considérée.

Cette ouverture se fait à postériori 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}

A 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 soit utile aux utilisateurs de l’API 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ée peut ouvrir sa donnée et modifier son nom et sa description en un seul appel :

{
  "name": "Un nom informatif avec espaces, majuscules ou accents si nécessaire",
  "description": "Une description synthétique en toutes lettres",
  "open": true 
}

Rendre une donnée extractible via l’API d’extraction vecteur aux seuls utilisateurs d’une ou plusieurs communautés identifiées

Pour rendre visible à certaines communautés, une donnée stockée, le producteur va jouer sur sa visibilité.

Mais 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 :

{
  "name": "Un nom informatif avec espaces, majuscules ou accents si nécessaire",
  "description": "Une description synthétique en toutes lettres",
  "open": true 
}

On répète à ce stade la même alerte que plus haut :

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.

Ce rappel fait, on peut désormais modifier la visibilité de la donnée via la route dédiée :

POST https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility

Avec le corps de requête suivant (en json) :

[
  "3fa85f64-5717-4562-b3fc-2c963f66afa6", "4ea85f64-5857-4562-bb2c-2c963f66art3"
]

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.

Cette route de modification de visibilité est associée à une route listant à quelles communautés une donnée est visible :

GET https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility

Ainsi qu’une route pour révoquer cette ouverture :

DELETE https://data.geopf.fr/api/datastores/{datastore}/stored_data/{stored_data}/visibility

Qui fonctionnent exactement sur le même principe.