search

ban-archive / api-gestion-poc

POC pour une API de gestion BAN
15 stars 11 forks source link

gestion du complément d'adresse #76

Closed christopheprudent closed 7 years ago

christopheprudent commented 8 years ago

ce complément d'adresse correspond à un libellé (postionné sur l'adresse postale entre le nom de la personne et celui concernant les informations de la voie, voir Normes de l'Adresse)

on peut distinguer deux typologies:

  1. le premier cas est en général une précision de la voie et/ou du numéro dans la voie (notion de sous-ensemble)
  2. le second cas correspond plutôt à un surensemble de voies : il s'agit par exemple des zones d'activités, voir de résidence ou lotissement très étendus

le premier cas pourra être hébergé dans l'entité POSITION, comme abordé à l'OpenLab-2; ce complément peut en effet être rattaché directement à une voie, ou à un numéro spécifique de cette voie par contre, le second cas correspond plutôt à l'entité DISTRICT, voir LOCALITY, et il peut lui-même être constitué de voies

en interne LA POSTE, il est constitué d’éléments optionnels qui peuvent être regroupés ainsi :

ces éléments sont ordonnancés, de gauche à droite ([Groupe 1] puis [Groupe 2] puis [Groupe 3]), avec pour chaque groupe une liste de mots clé

Groupe mot clé
1 ENTREE
1 HALL
2 BATIMENT
2 TOUR
2 ALLEE
2 VILLA
2 BLOC
2 ILOT
3 RESIDENCE
3 LOTISSEMENT
3 IMMEUBLE
3 FOYER
3 IHM
3 CITE
3 PARC
3 DOMAINE
3 MAS
3 CHALET
3 ZONE INDUSTRIELLE
3 ZONE ARTISANALE
3 ZONE D ACTIVITE
3 ZONE D AMENAGEMENT CONCERTE
3 ZONE D AMENAGEMENT DIFFERE
3 PARC D ACTIVITE
3 PARC INDUSTRIEL
3 ZONE
3 ZONE A URBANISER EN PRIORITE

concernant la norme adresse, voici les étapes réalisées pour respecter la taille du libellé (selon la norme utilisée, de 32 ou 38 caractères)

exemple: ENTREE 8 BATIMENT LES VIOLETTES RESIDENCE DES FLEURS 51 caractères

ENT 8 BATIMENT LES VIOLETTES RESIDENCE DES FLEURS 48 caractères

ENT 8 BAT LES VIOLETTES RESIDENCE DES FLEURS 43 caractères

ENT 8 BAT LES VIOLETTES RES DES FLEURS 37 caractères OK pour les 38 caractères.

ENT 8 BAT VIOLETTES RES DES FLEURS 33 caractères

ENT 8 BAT VIOLETTES RES FLEURS 29 caractères OK pour les 32 caractère

yohanboniface commented 8 years ago

En l'état, il me semble comprendre que tous les cas cités ici rentrent dans la modélisation actuelle (aussi bien que dans les deux autres en cours d'étude): ou bien en tant que District (type 3 dans ton tableau), ou bien en tant que position (type 1 et 2 dans ton tableau). Est-ce qu'on a d'autres points à checker?

concernant la norme adresse, voici les étapes réalisées pour respecter la taille du libellé (selon la norme utilisée, de 32 ou 38 caractères)

On est bien d'accord que dans la BAN on aura que les libellés complets?

cf #51 aussi.

yohanboniface commented 8 years ago

Question sur les tests d'import. Prenons cet extrait: screenshot from 2016-02-16 12-19-46

Puisqu'il est commun à plusieurs numéros, il me semble que le "Lotissement des Roses" (bravo pour les labels tout en majuscules au passage :p ) est un District, et non pas une Position.

Néanmoins j'ai une question: chaque ligne a son propre CO_CEA_L3, or pour moi c'est un seul et même objet. Du coup, je fais quoi de ces CEA?

christopheprudent commented 8 years ago

alors, en effet, notre référentiel ne contient que des libellés en majuscule, et non accentué (même pour les libellés in extenso, avant standardisation de la norme)

d'accord avec ton constat, il s'agit bien ici d'un sur-ensemble de numéros mais de manière générale, nous n'avons pas (ou pas toujours) celui des sur-ensembles de voies

enfin, ce CEA propre à chaque occurence de ce complément, permet d'identifier l'adresse (au sens du lieu précis) de celle-ci dans la rue 'ALLEE DES PEUPLIERS' en donnat également le numéro dans la voie : il s'agit d'un lien 1..n du complément vers son adresse de niveau supérieur

yohanboniface commented 8 years ago

enfin, ce CEA propre à chaque occurence de ce complément, permet d'identifier l'adresse (au sens du lieu précis) de celle-ci dans la rue 'ALLEE DES PEUPLIERS' en donnat également le numéro dans la voie : il s'agit d'un lien 1..n du complément vers son adresse de niveau supérieur

OK, donc je crée un housenumber NULL associé à chacun de ces districts?

Question bonus: je fais quoi des CO_CEA_L3 dans le cas d'un complément en position?

christopheprudent commented 8 years ago

euh, pas évident!

je pense qu'il vaut mieux, en l'état, toujours associé ces compléments à la Position (et non au District), associé au Housenumber (éventuellement à NULL), c'est-à-dire en tant que sous-ensemble

de cette façon, tu peux enrichir le CEA de ce complément (dans la colonne attributes ?) il est aujourd'hui diffuser (et j'espère utiliser) par les clients actuels de nos référentiels

bon, ça diverge dans les options, pas simple!

yohanboniface commented 8 years ago

je pense qu'il vaut mieux, en l'état, toujours associé ces compléments à la Position (et non au District), associé au Housenumber (éventuellement à NULL), c'est-à-dire en tant que sous-ensemble

Une position ne peut, bien entendu, pas être associée à plusieurs housenumbers. Ce qui voudrait dire, si on reprend l'exemple du Lotissement des Roses, qu'il faudrait créer autant de positions Lotissement des Roses que de numéros qui y sont associés. Ça me semble pas optimal. D'après moi on est vraiment face à un District, c'est-à-dire un surensemble de housenumbers, et non pas un sous-ensemble. Ou bien j'ai raté un truc?

christopheprudent commented 8 years ago

non, tu as tout bien résumé mais notre référentiel le code ainsi, avec duplication de ce complément (sous-ensemble) pour tous ses attachements (donc autant qu'il y a de numéros sur l'exemple pris)

et si on veut conserver ce CEA, je pense qu'il est nécessaire de répliquer ce schéma, oops!

yohanboniface commented 8 years ago

et si on veut conserver ce CEA, je pense qu'il est nécessaire de répliquer ce schéma, oops!

On en a pendu pour moins que ça! ;) Sérieusement, je pense que la BAN doit certes faire tout ce qui est possible pour aider les utilisateurs de l'adresse à migrer des différents systèmes antécédents à cette base unifiée, mais pas au point de tordre son modèle. Pour moi, c'est plutôt l'occasion de nettoyer ce point.

J'essaie de remouliner un peu tout ça pour y voir un peu plus clair.

parville commented 8 years ago

Bonjour !

Dans le cas d'espèce, le code répété du lotissement devrait pouvoir être associé au district ! Et comme on lie le district et le housenumber on peut donc, si on veut, restituer ce code au regard de chacun des housenumber du district ?!

Sinon j'aime assez à dire qu' on n'est pas là pour informatiser le b....

yohanboniface commented 8 years ago

Dans le cas d'espèce, le code répété du lotissement devrait pouvoir être associé au district !

Il y a un code CEA par numéro dans le lotissement, pas un code par lotissement (pour garder l'exemple).

parville commented 8 years ago

Yohan,

J'ai cru que le 580481 de la capture (qui n'a pas de rappel d'entête) représentait l'id du lotissement !

Alors ces valeurs distinctes pour chaque ligne sont l'identifiant de l'association :sweat: du district au housenumber !

yohanboniface commented 8 years ago

Alors ces valeurs distinctes pour chaque ligne sont l'identifiant de l'association :sweat: du district au housenumber !

Oui, et du coup je me pose la question de la pertinence de les garder…

christopheprudent commented 8 years ago

pas du tout, il s'agit d'un identifiant de la voie (ici 580481), suivi par une autre colonne, le numéro (ici 10)

pour info, extrait des données avec entête compl 33

soit:

yohanboniface commented 8 years ago

pas du tout, il s'agit d'un identifiant de la voie, suivi par une autre colonne, le numéro (ici 10)

Humm, j'ai pas compris. Tu parles bien de la colonne CO_CEA_L3?

yohanboniface commented 8 years ago

Bon, évidemment, là où y a de la donnée, y a de la purée: petit tour d'horizon. :)

Évacuons tout de suite le fait que les données sont en capitales non accentuées et qu'elles sont sans données géo ;)

Un peu de stats. Si on prend les premiers mots des libellés de complément d'adresse, voici ce qu'on trouve:

'RESIDENCE', 10535,
'LOTISSEMENT', 6219
'BATIMENT', 3215
'ENTREE', 1023
'DOMAINE', 467
'PARC', 123
'CITE', 80
'ZONE', 70
'IMMEUBLE', 57
'TOUR', 40
'FOYER', 21
'VILLA', 14
'CLOS', 7
'HLM', 2
'HALL', 2

Certaines valeurs sont assez faciles à mapper: ENTREE, BATIMENT ou HALL, on peut aisément les créer en tant que Position. Pour d'autres, c'est plus délicat.

Creusons par exemple un peu le cas 'RESIDENCE', qui est le plus courant:

Ce sera ni la première ni la dernière fois, mais, vu l'état des données, je vais me contredire: je crois qu'il serait prématuré de vouloir les structurer lors de l'import dans la BAN.

Voici les problèmes que je vois:

Donc ma proposition en l'état c'est de faire rentrer tous les compléments adresse dans des objets Position, au moment de l'import initial. Ensuite, l'usage pourra petit à petit, au fur et à mesure de la montée en compétence de la chaîne globale de gestion (communes, citoyens, etc.), faire remonter des infos dans des entités District dédiés. A condition toujours que les mainteneurs des données soit identifiables amha.

christopheprudent commented 8 years ago

je partage entièrement ton analyse

pour l'instant, je pense qu'il est préférable d'implémenter ces compléments en tant que sous-ensemble (info de précision) d'une Voie ou d'un Numéro [en conservant ainsi le CEA adresse de chaque complément]

dans le référentiel POSTE, nous n'avons pas les coordonnées (x, y) de ces adresses peut-être qu'un rapprochement (mais à déterminer le comment) avec IGN pourra nous aider ?

MaelREBOUX commented 8 years ago

Bonjour,

Je rajoute mon grain de sel.

Donc ma proposition en l'état c'est de faire rentrer tous les compléments adresse dans des objets Position, au moment de l'import initial. Ensuite, l'usage pourra petit à petit, au fur et à mesure de la montée en compétence de la chaîne globale de gestion (communes, citoyens, etc.), faire remonter des infos dans des entités District dédiés. A condition toujours que les mainteneurs des données soit identifiables amha.

Attention : les (grosses) métropoles ne géreront pas leurs adresses via la BAN mais y verseront leurs données. Ca fait une différence. Ici à Rennes actuellement il n'est pas envisagé de gérer ces appellations non officielles (je ne dis pas que c'est pas utile comme complément terrain). Dit autrement : ne vous attendez pas à ce que ces infos soient localement gérées et/ou nettoyées et maintenues.

@yohanboniface vu le schéma présent dans les propositions v 1.1 AITF : pourrais-tu décliner les valeurs de cet exemple si l'immeuble présenté s'appelait "résidence de la Rose" ?

ebuard commented 8 years ago

Bonjour et désolée pour la réaction tardive. Je rebondis sur le complément d'adresse. On a réfléchi de notre côté sur le complément d'adresse et voilà notre proposition: placer le complément d'adresse sur HouseNumber, et non sur Position, et donc déplacer du même coup le lien de filiation sur HouseNumber (une adresse principale et ses filles).

Nous voyons 2 cas d'exemples qui pourraient poser problème si on laisse cet attribut dans Position. Le premier exemple concerne la dissociation sémantique et géométrie. Il s'agit d'une adresse purement sémantique avec son complément d'adresse. On serait obligé de créer une position nulle, juste pour placer le complément d'adresse. Le second exemple concerne plusieurs positions pour une seule adresse avec complément d'adresse. Dans ce cas, le complément d'adresse serait dupliqué ou la position mère serait nulle. Prenons l'exemple de l'adresse située au 1 rue Truc Batiment A qui possède plusieurs entrées: "entrée pompiers" et "entrée piétons". Pour l'instant, on aurait soit 2 objets dans Position ("Bât A entrée pompiers" et "Bât A entrée piétons") soit 3 objets Position (Position mère: "Bât A" sans position et Position filles: "entrée pompiers" et "entrée piétons"). Le fait que le complément d'adresse soit sur HouseNumber nous permettrait d'avoir une classe Position plus propre, sans géométrie nulle: un objet Position a forcément une géométrie.

Par ailleurs, il est probable que le matching BAN - BD internes La Poste et IGN sera plus simple à effectuer puisque le matching sur la sémantique nécessitera seulement la classe HouseNumber.

On propose donc de dissocier la partie sémantique (dans HouseNumber) de la partie géométrique (dans Position). Par ailleurs, ce point va avec la filiation parce que la filiation est inhérente à la sémantique.

christopheprudent commented 8 years ago

d'accord avec tes remarques, qui obligent en effet de dupliquer la sémantique à chaque type de position (voir également une occurence sans géométrie)

mais le fait de "poluer" Housenumber ne fait que déporter le souci, en dénaturant cette fois cette entité, qui déjà embarque l'astuce du numéro à NULL pour identifier la Voie

je reste donc sur cette option, avec duplication, à re-discuter alors...

ebuard commented 8 years ago

Pour moi, le complément d'adresse fait partie intégrante de HouseNumber.

Par contre, le fait de créer une HouseNumber NULL pour identifier la Voie me pose problème: il n'y a pas d'adresses sur la voie, donc cette voie ne devrait être liée à aucun HouseNumber. C'est juste pour garder le CEA?

cquest commented 8 years ago

D'accord avec @christopheprudent , en migrant les compléments dans housenumber on déplacerait juste le problème. De mon point de vue, les compléments d'adresses n'ont pas pour l'instant atteint la maturité pour être modélisés comme on peut le faire sur les HouseNumber. Les stocker en position est donc une façon temporaire de les conserver. Lorsqu'on aura assez de recul, de données issues de différentes sources, on pourra remodéliser ce niveau supplémentaire de détail.

christopheprudent commented 8 years ago

houla, ça remonte déjà loin tout ça! par adresse, tu entends numéro ?

en tout cas, c'est le seul moyen de pouvoir associer une géométrie à 1 Voie, vu que ce lien est justement porté par Housenumber, de pouvoir également relier cette "adresse" (de type voie) aux autres étages de groupement...

ebuard commented 8 years ago

Pour résumer: ça ne vous dérange pas de stocker du texte descriptif qui n'a rien à voir avec la position (complément d'adresse sur une classe de nature géométrique (Position)?

Si j'ai bien compris, l'IGN veut ce complément et la filiation dans HouseNumber et La Poste et Etalab dans Position. Donc je me demande: quel est le processus de décision et quelle décision émerge au final? Doit-on faire remonter au COPIL nos divergences sur le modèle?

Je suis aussi d'accord sur le fait de laisser un complément sur District, mais cette classe n'est pas géométrique, puisque seule Position est une classe géométrique (par géométrique, j'entends avec des X et Y).

yohanboniface commented 8 years ago

Sur la collaboration

Si j'ai bien compris, l'IGN veut ce complément et la filiation dans HouseNumber et La Poste et Etalab dans Position. Donc je me demande: quel est le processus de décision et quelle décision émerge au final? Doit-on faire remonter au COPIL nos divergences sur le modèle?

J'espère que le COPIL a mieux à faire que de traiter ce genre de point ;) Un projet collaboratif demande un peu d'énergie pour arriver à un consensus. Il faut prendre le temps d'expliquer un problème, avec autant de détail que possible. Laisser les autres apporter des éléments de réponse. Revoir sa copie si le consensus n'est pas trouvé, chercher des solutions alternatives, etc. Les discussions, y compris les désaccords, font partie d'un processus sain collaboratif, on en est pas à en appeler au COPIL pour nous séparer parce qu'on s'est trop tapé dessus ;) Ensuite, de mon point de vue, en dernier recours, s'il faut un arbitre pour avancer, c'est le coordinateur technique qui tranchera, c'est-à-dire Christian.

Petit point workflow aussi sur ce ticket: il a été ouvert le 8 mars, on y a bossé activement pendant quelques jours jusqu'à trouver un consensus apparent, puis un mois plus tard un avis divergeant émerge. C'est très bien :) Mais il faut comprendre que ça va vous demander un peu plus d'énergie de convaincre tout le monde un mois après le gros des débats.

Sur la question des compléments d'adresse

Le consensus auquel on était arrivé, c'était justement qu'on ne pouvait pas décider maintenant. De même qu'on ne sait pas répondre de façon univoque à la question "qu'est-ce qu'une adresse", on n'est pas capable aujourd'hui de définir précisément un "complément d'adresse". Voir les débats sur ce ticket. Le résumé c'est que c'est une appellation un peu valise: on y trouve des regroupements d'adresse (lotissement), des sous-entités de l'adresse (bâtiment A), etc. Voir notamment ce message.

De mon côté, je trouve pertinente la question qui est soulevée de la duplication de données entre plusieurs positions qui auraient des compléments d'adresse similaires, de même que celle de savoir si l'entité géographique position est le bon réceptacle pour des données sémantiques telles qu'on peut les trouver dans les compléments d'adresse. Néanmoins, je ne pense pas que l'ébauche de solution avancée soit une bonne réponse. Mettre tout le monde dans des housenumbers soulève d'autres problèmes, par exemple celui de la coexistence entre le "2 bis rue des fleurs" et le "2 bis bâtiment A rue des fleurs". Ce serait là aussi une forme de duplication des données.

Donc, personnellement, en l'état, je reste sur ma position (sans jeu de mots ;) ). Gérer les compléments d'adresse de façon non formelle via les objets Position me semble la moins mauvaise option temporaire envisagée à l'heure actuelle. Faisons déjà rentrer toutes les données Poste et IGN dans ce modèle et voyons ce qu'il en ressort. Nous aurons toute latitude derrière pour faire évoluer le schéma.

Mais je tout à fait disposé à considérer des contre-arguments étayés :)

yohanboniface commented 7 years ago

Je ferme ici, je pense pas qu'on revienne sur ce thread. On ouvrira un nouveau ticket si on doit adapter la modélisation.