adapt MCD to store (Street, Locality, and others) as Zone, and not each ones in own entity

[christopheprudent]

idea to unify theses zones in the same entity, for example Zone, w/ a new column, as type (varchar), to specify the zone

• Street
• Locality +
• old Municipality
• District

[yohanboniface]

Sharing some thoughts on this topic:

At this time, I think we can't put every one of those models in a single table, as there are some modeling exceptions:

• street => it's not an area :)
• zipcode => can be linked to more than one municipality

Also, some entities (like the IRIS code) have specific metadatas, and I'm not sure it's a good idea to share those metadata columns with others entities (that would then have the column empty, preventing us to make the column NOT NULL in the table, for example).

Also, we need (at this time, this can be discussed and changed of course) the street or locality fantoir to define the CIA (clé d'interopérabilité de l'adresse, see https://github.com/etalab/cle-interoperabilite-adresse). So if we allow a housenumber not to be linked to any street and any locality, we have many CIA that would end to be the duplicated. While the idea of the CIA is to be unique for all the database at a point in time.

Other point to keep in mind: maybe some areas types will be specifically managed by some entities, for example the IRIS may be added in the BAN only if the INSEE starts updating the data (when a new address is created, who links it to the good IRIS?), and maybe we'll want some specific authentication scopes for those areas (like only those clients can update IRIS), and this will be easier to do if the IRIS is a separate model (and table).

That's said, I don't have a counter-proposal at hand ;)

The best I can think to at this point would be:

• keep street and locality, because of fantoir and cia
• keep zipcode because it can be linked to more than one municipality
• add district for suburban areas (so quartier, ancienne commune, zone artisanale, etc. would go there)
• keep iris like zones in dedicated models, for easier auth and attribute management

Not saying that this is the best option ever! All this needs more thinking and experimenting, for sure :)

cc @cquest

[cquest]

I'm in favor of:

• street (single)
• locality (single)
• zones (multi)

Each zone is a group of housenumbers. Zones can be:

• Zip code areas
• statistical areas (like IRIS in France)
• sub-municipality zoning (suburb, etc)
• former municipality area (when municipality are merging) etc...

We should accepts zones that are :

• generic enough (enough people refering or using them)
• maintained by a BAN partner (Poste for ZIP codes, INSEE for IRIS, etc)

For other less generic zoning, API-Carto and geographic based matching can be used, but outside BAN.

(pourquoi on discute en anglais ?)

[yohanboniface]

(pourquoi on discute en anglais ?)

Ah, c'est pas de l'allemand? :) Réponse: à la convenance de chacun (tant que les commentaires dans le code sont en globish, le reste me va). :)

zones (multi)

Si on met les zipcode dans une table générique "zones", on va devoir typer chaque row (type="zipcode", type="iris"), et on va très vite devoir ajouter des comportements spécifiques (if type == "zipcode": check that code is set and is less than 5 chars and is numeric). Ces comportements doivent être gérés via des modèles dédiés et pas via des exceptions dans un modèle générique On pourrait imaginer avoir un modèle Zone et des modèles qui en héritent, le tout dans une seule table "zone", mais du coup ça nous empêche d'avoir des colonnes spécifique par modèle, ou tout au moins ça nous empêche de mettre des NOT NULL si besoin. Pour moi, l'idée d'un zonage générique doit atterrir dans l'API carto, et pas chez nous :) Par contre, on peut imaginer accepter des recherches par polygon, pour permettre à quelqu'un qui veut les adresses d'un quartier prioritaire ou whatever de nous passer un geojson avec sa géométrie, qu'il aurait éventuellement obtenu de l'API carto par exemple. :)

Y a quoi comme cas de zonages candidats à une intégration dans la BAN, dans le radar actuellement?

• quartier
• ancienne commune
• IRIS
• code postal

What else?

[christopheprudent]

j'aime bien la chute du message de Christian...

sinon, non, en effet, pas d'autres "types" de zone en vue, à part donc, de manière générique:

• quartier
• ancienne commune (qui devient elle-même un quartier de la commune résultant de la fusion) avec pour ce dernier cas le besoin de mémoriser son code INSEE (cette commune n'étant plus dans la table Municipality)

ça me va bien, merci :)

cc @Apside-bdx-BBO

[christopheprudent]

et petite précision, dans cette nouvelle entité District, nous pourrons donc ranger les zones dites Lieu-Dit (actuellement dans notre référentiel LP), certaines avec un code INSEE, pour conserver son statut d'ancienne commune...

par exempe, en Gironde:

[christopheprudent]

le but est d'ajouter un niveau de hiérarchie entre la Commune et la Voie (ou le Numéro si besoin), de manière à référencer les "quartiers" d'une commune, en les typant

• les anciennes communes, issues d'une fusion entre communes : les communes fusionnées devenant un quartier de la commune résultante
• en interne POSTE sont également déclarés les lieux-dits des TOM (Territoires d'Outre-Mer), à identifier pour un usage particulier de l'adresse littérale (commune, suivi du code postal et enfin du lieu-dit) à l'opposé du cas usuel
• les lieux-dits non ancienne commune (en fait les autres)

par contre, à priori lien 1-1 entre entité Housenumber et District

[yohanboniface]

@christopheprudent tu as pu tester le modèle District, ajouté récemment, voir s'il correspond aux besoins décrits ici?

[christopheprudent]

je suis en train de regarder ça, et je m'étonne du choix n-n justement : je creuse!

[yohanboniface]

je suis en train de regarder ça, et je m'étonne du choix n-n justement : je creuse!

Tout simplement un housenumber qui est à la fois dans le quartier "Vieux-Port" et dans l'ancienne commune "Fouillis-sur-Mer"?

[christopheprudent]

ok, nous n'avons pas dans notre référentiel POSTE ce niveau de hiérarchie imbriquée ici, le quartier "Vieux-Port" est un quartier de l'ancienne commune "Fouillis-sur-Mer" ?

à vérifier de notre côté, mais je pense que dans ce cas, la déclaration du numéro porte uniquement sur l'ancienne commune!

[yohanboniface]

ok, nous n'avons pas dans notre référentiel POSTE ce niveau de hiérarchie imbriquée ici, le quartier "Vieux-Port" est un quartier de l'ancienne commune "Fouillis-sur-Mer" ?

Il ne s'agit pas d'imbrication, mais de relations multiples. C'était il me semble l'idée de la table "zone" générique, dans laquelle on met différents types de zones subcommunales non exclusives. Mais j'ai pu comprendre de travers :(

Mais peut-être tout simplement l'idée d'une table zone générique n'est-elle pas adaptée. Si au final les seules zones qu'on va utiliser sont des anciennes communes, il faudrait revoir la copie. En ce cas, je préconiserais plutôt d'ajouter un flag sur les Municipality pour savoir si elles sont toujours actives (voire en gardant les dates de création et suppression), et j'ajouterais une relation m2m entre les housenumber et les Municipality pour garder la trace des anciennes communes (genre old_municipalities).

[christopheprudent]

je me suis sûrement mal exprimé pour expliquer cette notion d'imbrication de zones, dans le sens de zones gigognes (notion de précision d'empreinte)

notre référentiel actuel ne recense pas les quartiers des villes (appelation locale, "zones" de la commune, ...), sauf exceptions (dont je ne connais pas la raison, peut-être un souci de distribution? , j'essaie d'avoir une explication interne) et bien sûr les anciennes communes

aujourd'hui, je recense:

• 36813 communes
• 46 communes de type arrondissement (PLM)
• 1199 anciennes communes
• 206 communes (TOM)
• et donc 937 autres, type Quartier, non INSEE

sur ces 937 derniers cas, seuls 84 possèdent au moins 1 voie rattachée (pour un total d'environ 6600 voies, avec leurs 126748 numéros); il s'agit pour nous de cas d'exception, et c'est en ce sens que je me souci du bien fondé pour l'élaboration du modèle : ne pas gérer l'exception comme le cas général en tout cas, il s'agit toujours d'un attachement simple, de la voie à ce Quartier (de type 0-1) :information_source: le cas 6 https://github.com/etalab/ban/wiki/liste-d%27adresses-type se traduit par la duplication de la voie 'Allée des Mimosas', l'une attachée à la commune 'Antibes', l'autre au quartier 'Juan les Pins'

de plus, je ne sais pas qui sera capable de donner cette information de rattachement d'une voie ou même d'un numéro à un quartier ? pour quel usage ?

mais si ce besoin est retenu, un lien 0-n est donc nécessaire entre Housenumber (qui contient et les voies, et les numéros) et District

[christopheprudent]

cette issue soulève donc l'étude de l'attachement Voie, Numéro à un District

cas Voie

• (cas 7) ex voie non numérotée, attachée à un quartier
• fusion de communes conserver le lien vers l'ancienne commune d'une voie (voir #62)

cas Numéro

• (cas 6) à noter que dans ce cas d'une voie multi-CP, multi-COMMUNE/QUARTIER, la voie est dupliquée, côté POSTE: l'une déclarée sur ANTIBES, l'autre sur JUAN LES PINS

[yohanboniface]

@christopheprudent si la table District est multitypée, de facto la relation est many to many: rien ne permet de garantir qu'un même housenumber ne sera pas associé à des districts de plusieurs types. Donc si on pense qu'il faut une relation unique de housenumber vers district, ça veut dire qu'il faut que la table district ne contienne qu'un seul type d'objets.

[christopheprudent]

@yohanboniface bonjour, d'attaque dès le matin! l'entité District sera en effet multi-typée mais avec des éléments exclusifs (dans la littérature UML, ça porte un nom intelligent), donc pas de problème, non ?

[yohanboniface]

@yohanboniface bonjour, d'attaque dès le matin!

Toujours, le week-end! ;)

l'entité District sera en effet multi-typée mais avec des éléments exclusifs (dans la littérature UML, ça porte un nom intelligent), donc pas de problème, non ?

J'ai pas compris :( En quoi ça me garantit qu'on ne voudra pas associer un même housenumber à la fois à un District de type ancienne commune et à un Disctrict de type quartier?

[christopheprudent]

oops, d'accord! c'est en effet une possibilité, tu as raison après, est-ce un besoin auquel il faudra répondre?

[MaelREBOUX]

2 bonnes questions :

1. est-ce vraiment un besoin ?
2. est-ce que ce sera maintenu et par qui ?

Sincèrement avoir la trace des communes concernées par fusion de communes : oui. Besoin pour de l'intra communal : je suis très septique. Je poserai la question au groupe AITF fin du mois.

[yohanboniface]

Je pense qu'on peut fermer ici.