Fichiers BAL pour tests

MaelREBOUX commented 8 years ago

Voici 2 premiers fichiers de Base Adresse Local (BAL) pour tester : Rennes Métropole et Grenoble.

Je mettrai les prochains à la suite.

yohanboniface commented 8 years ago

Super :) @MaelREBOUX ils sont au format AITF 1.1, c'est bien ça?

cquest commented 8 years ago

Merci @MaelREBOUX ça fait du grain à moudre pour le super importeur de fichier AITF ;)

MaelREBOUX commented 8 years ago

@yohanboniface : oui : 1.1 Je me suis demandé à un moment s'il fallait le spécifier dans le nommage du fichier mais je préfère déporter ça sur les outils de contrôle.

yohanboniface commented 8 years ago

@MaelREBOUX quelques questions pour toi:

je ne vois pas de distinction entre création et modification d'adresse, est-ce à moi de le déterminer lors de l'import du fichier? Quid aussi de la gestion des conflits quand des données sont déjà dans la BAN?
pourquoi des numéros en 99999 et pas tout simplement une absence de numéro?
pour ce qui est de la clé d'intéropérabilité, il est prévu d'utiliser ou bien le code FANTOIR ou bien l'id BAN si je comprends bien? Est-ce à moi de déterminer quel type d'identifiant je reçois (taille/structure de la valeur)?
toujours sur la clé d'intéropérabilité: quid des numéros d'adresse non numériques? Pourquoi préfixer par des 0?
clé d'intéropérabilité encore: quid des prefixes qui ne sont ni bis/ter ni a/b/c? J'ai notamment souvenir d'indices de répétition numériques
je crois connaître ta réponse, mais je la pose quand même: aucun complément d'adresse n'est prévu via ce format?

yohanboniface commented 8 years ago

cf #75

yohanboniface commented 8 years ago

@MaelREBOUX autre remarque: je vois que les fichiers comportent un BOM. De mon point de vue, ce serait plus sain sans, et il faudrait quoi qu'il arrive le préciser dans la spec (vu qu'on en a une ;) ). Je vais gérer avec et sans de mon côté, mais je serai sûrement pas le seul utilisateur de ce format. ;)

yohanboniface commented 8 years ago

@MaelREBOUX autre question: dans le cas où j'ai un numéro 99999, comment je fais pour savoir si c'est une rue ou un lieu-dit?

yohanboniface commented 8 years ago

A propos de la clé d'interopérabilité deux remarques:

d'une part, c'est pas la même que celle qui est actuellement utilisée dans le code chez nous (on utilise https://github.com/etalab/cle-interoperabilite-adresse ), faudrait peut-être qu'on s'aligne ;)
d'autre part, je suis pas sûr qu'elle ait un intérêt dans ce fichier: je crois que ce serait plus simple d'ajouter une colonne INSEE et une colonne FANTOIR (optionnelle, sinon il faut uid_adresse), vu qu'on a déjà le numéro et le suffixe, et on peut reconstruire la clé à la volée; quoi qu'il en soit là je parse la clé pour récupérer l'INSEE et le FANTOIR séparément

cquest commented 8 years ago

On peut s'aligner de notre côté, ça serait plus cohérent. Et +1 pour le parsing, elle est construite aussi pour ça.

MaelREBOUX commented 8 years ago

je ne vois pas de distinction entre création et modification d'adresse, est-ce à moi de le déterminer lors de l'import du fichier? Quid aussi de la gestion des conflits quand des données sont déjà dans la BAN?

ce n'était pas dans le cahier des charges ;) Il s'agit du modèle de données simple. Je peux retenir ce besoin pour le modèle élaboré mais il faudrait, pour fournir cette info, que les systèmes de gestion des Bases Adresse Locales (BAL) puisse fournir cette info. A voir.

pourquoi des numéros en 99999 et pas tout simplement une absence de numéro?

convention : cf le document. Avec absence on saurait pas si ça veut qu'il y a vraiment une adresse mais qu'on en connaît pas son n°. Au moins là : c'est clair.

pour ce qui est de la clé d'intéropérabilité, il est prévu d'utiliser ou bien le code FANTOIR ou bien l'id BAN si je comprends bien? Est-ce à moi de déterminer quel type d'identifiant je reçois (taille/structure de la valeur)?

oui : code FANTOIR. l'attribut uid viendrait stocker l'uid de la BAN. La clé d'interop doit pouvoir être constituée hors BAN. Pour le moment. On fera évoluer le moment venu.

toujours sur la clé d'intéropérabilité: quid des numéros d'adresse non numériques? Pourquoi préfixer par des 0 ?

Pourquoi pas ? Non : c'était histoire d'avoir des longueurs de parties un peu homogène.

clé d'intéropérabilité encore: quid des prefixes qui ne sont ni bis/ter ni a/b/c? J'ai notamment souvenir d'indices de répétition numériques

suffixes plutôt. comme indiqué dans le doc : c'est libre mais cohérent avec l'attribut suffixe.

je crois connaître ta réponse, mais je la pose quand même: aucun complément d'adresse n'est prévu via ce format?

Ben si : c'est l'attribut suffixe. Nous en avons donné une définition dans notre document et on s'y tient. C'est un consensus qui a mis du temps pour concilier toutes les pratiques nationales. Je vous conseille de le reprendre.

je vois que les fichiers comportent un BOM

Euh là je botte en touche. Vu l'hétérogénéité des sources, je vous conseille de vous adapter.

dans le cas où j'ai un numéro 99999, comment je fais pour savoir si c'est une rue ou un lieu-dit

Tu le déduis. Ou pas. Ce sera du ressort du modèle élaboré. La BAN = des adresses. On a déjà étendu pour vous remonter des voies non adressées.

yohanboniface commented 8 years ago

@MaelREBOUX merci pour tes réponses. Elles sont prises en compte, notamment via #95

Une petite requête: aurais-tu moyen de me fournir des données dans le 90? C'est beaucoup plus rapide pour moi de tester (3500 rues versus 50000 dans le 35 par exemple). :)

Quelques réponses à tes réponses:

convention : cf le document. Avec absence on saurait pas si ça veut qu'il y a vraiment une adresse mais qu'on en connaît pas son n°. Au moins là : c'est clair.

Pas très fan de cette solution, notamment parce que '99999' est une valeur possible (théorique) pour un numéro. Je pense qu'il serait plus propre d'ajouter une colonne pour typer les lignes (point adresse, groupe…).

Pourquoi pas ? Non : c'était histoire d'avoir des longueurs de parties un peu homogène.

Pas fan non plus. Je suggère la valeur brute dans la prochaine évolution du format, c'est plus propre.

Ben si : c'est l'attribut suffixe. Nous en avons donné une définition dans notre document et on s'y tient. C'est un consensus qui a mis du temps pour concilier toutes les pratiques nationales. Je vous conseille de le reprendre.

Pas sûr qu'on se comprenne. Par "complément d'adresse", j'entends des trucs comme "bâtiment 13", "Entrée A" ou "Résidence des Poneys". Ce genre de données peut se trouver dans le champ "suffixe"? J'avais compris qu'il ne contenait que ce que l'IGN appelle l'indice de répétition (bis, ter, etc.). Je veux bien un autre éclairage du coup sur ce point :)

Par ailleurs, je confirme mon point de vue: ne pas mettre de colonne "clé d'interop", mais mettre les colonnes des différentes valeurs qu'elle contient; en d'autres termes ajouter INSEE et FANTOIR. Au consommateur de recréer la clé selon ses règles si besoin. Dans mon cas j'en ai pas besoin, et plutôt j'ai besoin de récupérer l'INSEE et le code FANTOIR.

yohanboniface commented 8 years ago

Quelle valeur dois-je attendre dans le bit FANTOIR de la clé d’interopérabilité pour les rues nouvellement créées (et donc qui n'ont pas de vrai FANTOIR)?

yohanboniface commented 8 years ago

Autre remarque: serait-il possible d'utiliser des valeurs simplifiées pour la colonne "position"? Je vois "cage d’escalier" ou "bâtiment" et ça me paraît casse-gueule: type d'apostrophe, accent ou pas, etc. Idéalement les valeurs INSPIRE directement (staircase identifier, building…). Bien sûr, je peux faire du nettoyage de mon côté, mais d'une part il restera des failles, d'autre part il me semble qu'un format d'interopérabilité doit être le plus robuste possible.

MaelREBOUX commented 8 years ago

2 autres fichiers de tests : Nice (20160324_bal_200030195) et Toulouse (20160317_bal_243100518)

yohanboniface commented 8 years ago

Merci :)

à l'usage, je me dis qu'il serait bien d'ajouter un label à destination des humains dans le nom des fichiers (xx_toulouse.zip, xxx_nice.zip); personnellement je m'y perds un peu dans les fichiers (oui, je peux me les ajouter à la main dans le cas présent ;) )
je redis que de mon côté ce serait vraiment pratique d'avoir des données pour le Territoire de Belfort, département très petit, qui me permet de facilement repartir de zéro
tu peux m'en dire un peu plus sur les fichiers de logs qui accompagnent les données? Je comprends pas bien d'où ils sortent, qui les a fait, en comparant à quelles données.

Merci :)

MaelREBOUX commented 8 years ago

il serait bien d'ajouter un label à destination des humains dans le nom des fichiers

Nous on est plutôt pour rajouter un libellé optionnel derrière le nom technique car je me suis arraché les cheveux pour savoir quoi était à qui à plusieurs reprises ! Mais c'est comme ça car on a eu une injonction de @cquest sur le fait d'avoir des code SIREN.

ce serait vraiment pratique d'avoir des données pour le Territoire de Belfort

Belfort ? Je peux tenter de voir si on a qqn de disponible là-bas.

tu peux m'en dire un peu plus sur les fichiers de logs

Ce fichier de log est généré par le traitement FME qui fait un test d'intégrité sur les données. C'est là pour info et affutage des vos outils.

cquest commented 8 years ago

ça peut paraitre bizarre le coup des SIREN, mais ça permet de gérer autant les communes que les EPCI ou autres sources...

MaelREBOUX commented 8 years ago

Je remet ici les 4 BAL précédemment mise en ligne + 2 nouvelles : Colmar agglomération et Ville de Mulhouse. Avec les noms pour mieux les identifier...

BAL.zip

ebuard commented 7 years ago

Les fichiers BAL tests ont été mi à disposition et testés lors de l'initialisation. On ferme ce ticket; on en rouvrira un si besoin sur des problèmes précis.

ban-archive / api-gestion-poc

Fichiers BAL pour tests #91