baseadressenationale / api-depot Goto Github PK

Dans le sprint 2 du prototype d'identifiant unique de l'adresse, l'utilisateur va déposer une BAL en V1.
Créer la fonctionnalité permettant de calculer et d'exploiter un différentiel entre les BAL V0 et V1 pour déterminer des évènements.

Contexte : BaseAdresseNationale/ban-bal#1

L'API ne supporte actuellement pas les langues régionales car la version du validateur qu'elle encapsule ne les supporte pas.
Il faut attendre la résolution de BaseAdresseNationale/validateur-bal#49 et la publication d'une nouvelle version, et mettre à jour la dépendance.

Contexte

Le moissonnage de Base Adresse Locale de Viviers-les-Montagnes (Tarn) s’effectue sans erreurs et pourtant, aucune révision n’est créée.

Investigation

Il y a deux sources pour le même organisme :

• https://plateforme-bal.adresse.data.gouv.fr/moissonneur/sources/datagouv-634ec5dc87d9f04196aa5350
• https://plateforme-bal.adresse.data.gouv.fr/moissonneur/sources/datagouv-63b6ce15bec8f8c2063ec9d9

Il s’agit en réalité d’une ancienne page https://www.data.gouv.fr/fr/datasets/base-adresse-locale-de-viviers-les-montagnes-tarn/ qui n’existe plus (404). C’est désormais https://www.data.gouv.fr/fr/datasets/base-adresse-locale-de-viviers-les-montagnes-tarn-1/  (à noter le -1 en plus à la fin de l’URL).

Cette particularité ne devrait pas poser de problème, mais il est préférable de ne pas l'écarter.

Il est nécessaire de comprendre pourquoi aucune révision n’est liée aux harvests alors que celui-ci indique pas d’erreur ou blocage.

(status: completed et updateStatus: updated)

La route de différentiel de calcul de différentiel entre une révision et la révision current
doit être rendue plus générique afin de comparer deux révisions et pas forcément une révision avec la current.

Modifier cette route pour avoir une comparaison entre deux révisions peut importe les id de révision. Attention l'ordre est important.

Contexte

Un utilisateur nous a remonté que l'adresse email renseignée lors de la demande d'habilitation était en réalité celle d'une commune déléguée.

En effet, l'adresse email récupérée pour la commune de Val d'Oust (56197) est [email protected]. Or celle-ci correspond à l'adresse email de la Chapelle Caro.

Réellement, les 3 mairies et leurs 3 adresses emails sont renvoyées par l'API, mais rien ne permet de les distinguer.

https://etablissements-publics.api.gouv.fr/v3/communes/56197/mairie

Dans le sprint 2 du prototype de l'identifiant unique.

Un fichier d'évènements indiquant des précisions telles que "suppression simple d'adresse"... pourra être fourni en même temps ou à part du fichier BAL à l'étape 3.

prendre en compte ce fichier d'évènements pour compléter les évènements calculés automatiquement via le calcul différentiel entre les V0 et V1.

Pour le sprint 1 du prototypage de l'identifiant unique.

L'utilisateur va envoyer son fichier à l'API de dépôt et à l'étape 3, il faut vérifier que les uuid fournis dans la BAL n'existent pas dans la BAN pour éviter une collision.
NB :

• Renvoyer une erreur précise.

Contexte

Il a été constaté qu'il est possible que des révisions publiées en même temps (une différence inférieure à la seconde) entre en concurrence. Cela a pour effet qu'elles changent mutuellement la propriété current à false. En conséquence, la commune ne dispose plus de révision courante.

Il est donc nécessaire de mettre en place un "verrou" empêchant ses publications concurrentes en rejetant l'une des deux ou alors en reprogrammant la publication à l'aide d'un cron par exemple.

Actuellement, quatre communes sont concernées :

• 84112
• 61189
• 18204
• 26082

Modifier la route diff-bal: PUT /revisions/{idrevisision}/files/diff-bal
Il faut utiliser la table files avec le champ type=diff
Ca permettra d'utiliser les fonctions faisant appel aux donnees de la table file

exemple de fichier json en body
{
"countDeleted": 2,
"deletedIds": [
"fcbe3db6-b995-48af-9f69-b3fe67d5c0ff",
"655e9126-8c77-4818-bde9-258c97fc1741"
]
}

Contexte

Il peut arriver qu'une commune demande la dé-publication d'une BAL. Bien que cette pratique soit fortement déconseillée, elle peut être nécessaire dans le cas d'une suppression massive des adresses par exemple.

La suppression d'une révision par une action d'un administrateur est donc nécessaire.

Mise en place

• Identification grâce à un token admin
• Ajout d'une route de suppression DELETE /revisions/:revisionId

Action

Cette route doit :

• supprimer les fichiers associés à la révision concernée
• supprimer la révision
• passer la révision précédente (la plus récente et valide connue pour la commune) en current

la route /revisions/:revisionIdV0/:revisionIdV1/calc-diff
doit être vérifiée par des tests unitaires
Vérifier le résultat attendu (détection de changement de position, de changement de sémantique, ajout ou suppression d'adresse)

Bonjour,

Je teste sur le webservice de démo, et avec une donnée un peu bidon (pour le moment), j'obtiens une erreur de validation (c'était le but):

{"valid": false, "errors": ["position.valeur_invalide", "row.incoherence_numero"]}

Dans "errors", je retrouve des chaînes qui ressemblent à des clés i18n. Elles sont relativement lisibles, mais serait-il possible:

• d'avoir la liste de toutes les clés error possibles ?
• d'avoir la correspondance avec les libellés en français correspondant à l'erreur?

Idéalement, il faudrait aussi que l'erreur indique sur quel(s?) enregistrement l'erreur se produit, car là, c'est un peu nébuleux, si on a des milliers d'adresses dans le CSV qui est envoyé.
Je ne sais pas jusqu'où votre API peut gérer cela, mais si chaque "error" pouvait être un objet JSON, avec une propriété "key" pour la clé i18n, une propriété "label" avec le texte en français, et par exemple la liste des cle_interop qui sont concernées par cette erreur, cela pourrait permettre un feedback utilisateur bien plus intéressant pour les intégrateurs !

Merci !

Contexte

Il arrive que des révisions existant sans information sur la publication.

L'API de dépôt et le validateur indiquent que l'attribut voie_nom_bre ne peut être vide.

Or, en toute logique il me semble évident que l'attribut supplémentaire et optionnel voie_nom_bre puisse être une chaîne vide car la "traduction" / remise en bonne dénomination peut ne pas être complète du premier coup sur une commune.

Bonjour,

Nous sommes éditeur d'une solution open source de plateforme opendata (https://data-fair.github.io/4/) et aimerions bien développer un plugin pour que nos clients puissent exporter leurs BAL en passant par l'API push (https://github.com/BaseAdresseNationale/api-depot/wiki/Documentation).

Est il possible d'avoir accès à un environnement de test pour vérifier la bonne intégration de notre plugin ?

Merci d'avance.

Contexte

L'URL de l'API établissement publics a changé, c'est désormais : https://plateforme-bal.adresse.data.gouv.fr/api-annuaire/v3

Il est nécessaire de mettre à jour la variable d'environnement API_ETABLISSEMENTS_PUBLICS

Afin de pouvoir commencer à migrer la branche prototype vers master pour l'identifiant unique. Nous avons besoin de tester si uid_adresse fait partie des champs avant d'utiliser le calc-diff sinon nous devons renvoyer une erreur indiquant que cette route est uniquement réservée pour le calcul des différences entre 2 révisions ayant un uid_adresse

Bonjour,

Je teste l'envoi en Python d'un fichier CSV sur l'endpoint PUT /revisions/xxx/files/bal. le status_code renvoyé est 201 (Created) alors que la doc:
https://github.com/BaseAdresseNationale/api-depot/wiki/Documentation#%C3%89tape-2--t%C3%A9l%C3%A9versement-du-fichier-bal

Indique 200. Je ne sais pas si PUT devrait renvoyer un OK ou un Created, donc soit il faut corriger l'endpoint, soit il faut corriger la documentation

Merci !

Comportement attendu :

• Une bal est déposée
• Si elle est valide elle crée une nouvelle révision
• Si le fichier est invalide la publication est bloquée
• Si la nouvelle révision généré un déficit d'adresse trop important la publication est bloquée

Comportement observé :

• Une BAL invalide est déposée
• une nouvelle révision est créée
• la publication est effective
• la commune perd toutes ses adresses

Exemple : SI de Saint Quentin en Yvelines

Un CSV invalide est déposé via API, il est formaté avec un encodage exotique 'utf-8-sig'
Les carriages return des lignes ne sont pas parsés '\r\n', les caractères non-ascii non plus (ex: '\xc3\xa9')

Uploading bal-78423_en_erreur.csv…

Pourtant, aucune erreur n'est trigger pas le validateur.
Le fichier est parsé comme sans adresses est quand même publiée.

Montigny-le-Bretonneux - 78423
Page commune :
https://adresse.data.gouv.fr/commune/78423
Api dépot :
https://plateforme.adresse.data.gouv.fr/api-depot/communes/78423/revisions

Toutes communes du SI de Saint Quentin en Yvelines sont impactés.

Bonjour,

Je fais un test avec la donnée (fictive) suivante:

uid_adresse;cle_interop;commune_insee;commune_nom;commune_deleguee_insee;commune_deleguee_nom;voie_nom;lieudit_complement_nom;numero;suffixe;position;x;y;long;lat;cad_parcelles;source;date_der_maj
;61002_1658_00001;61002;Almenêches;;;Voie test;;1;;entrance;484157.65;6818412.33;0.0135;48.1297;;ban;2021-11-17

La "position" est donc "entrance". Je me réfère à ce document :

https://aitf-sig-topo.github.io/voies-adresses/files/AITF_SIG_Topo_Format_Base_Adresse_Locale_v1.2.pdf

Qui indique que les valeurs de "position" sont celles de la codelist "GeometrySpecificationValue" de la directive INSPIRE:

https://inspire.ec.europa.eu/codelist/GeometrySpecificationValue

Passer une valeur "entrance" me parait donc OK, mais c'est rejeté par l'API dépôt avec l'erreur "position.valeur_invalide".

Quelles sont les valeurs valides de "position" svp ?

Merci !

Pour le prototypage des identifiants uniques de l'adresse.
Prendre en compte les uuid pour la publication dans la BAN au même titre que les autres champs du CSV.

Contexte

Il a été constaté que l'API appelé pour récupérer les informations des mairies était https://etablissements-publics.api.gouv.fr/v3 hors cette URL est la fallback et cette celle-ci n'est plus à jour.

Correction
Modifier l'url dans le fichier .env.sample par https://plateforme.adresse.data.gouv.fr/api-annuaire/v3.

Dans la documentation, il est précisée à l’étape 4, que la révision est publiable si le paramètre ready = false mais après test de l'API le texte renvoyé par l’API à l’étape 3 le ready = true ?

Dans le sprint 2, l'utilisateur va fournir ou pas un fichier d'évènement en plus du fichier CSV BAL.

Pour déterminer les évènements :

• étape 1 : détection automatique par différentiel
• étape 2 : exploitation d'un fichier d'évènement livré avec le CSV
• étape 3 : demander la complétion des informations (prévoir la réponse à l'envoi et prévoir la route pour récupérer les informations complémentaires)

Ce ticket concerne l'implémentation de l'étape 3.

Contexte

À la création d'un nouveau client, un email est envoyé avec l'URL de l'API à utiliser.

Il y a visiblement une erreur sur la configuration du mail ou de la variable

Modifier la route compute POST /revisions/{idrevision}/compute

pour qu'elle prenne en compte une partie qui fait appel à :

• la fonction de différentiel cf ticket #29
• au fichier en base #30
  -> et compare les id supprimés

-> si on a égalité alors on permet d'avoir le ready true pour le publish.
-> si on a pas égalité on a un message d'erreur qui empèche d'aller plus loin

Dans la requête GET pour obtenir les révisions d’une commune, le code JSON renvoyé est entre [ ] contrairement aux requêtes POST ou PUT. Cet état de fait empêche notre FME de lire par défaut en JSON. Nous devons supprimer ces caractères au préalable. Est-ce normal ou une erreur ?

Context

L'api-depot envoi un mail a la création d'un client, lors d'un refresh token et lorsqu'on envoie le code pin de l'habilitation.
Or il n'y a pas de serveur smtp sur l'api-depot-demo, cela provoque une erreur 500

Contexte

La gestion des clients, mandataires et chefs de file ajoutés dernièrement n'a pas encore été documenté.

Voir :

• #41
• #45
• #48