Loomio
Tue 9 Feb 2016 1:39PM

Re-structuration de la DB pour les Cities

R Raphael Public Seen by 135

Récemment, on s'est rendu compte qu'il y quelque ptit probléme concernant code postal / INSEE :
- CEDEX qui ne sont pas pris en compte
- le code postal qui était parfois plus pertinent que le code INSEE pour la géolocalisation
- Eviter de sortir plusieurs communes quand on cherche un INSEE

On a pu récupérer un fichier contenant l'ensemble des codes postaux avec cedex et j'ai fait un traitement qui permettait de les liés au INSEE correspondant:

Nous avons déjà une collection qui regroupe les différents quartiers France (métropole et DOM-TOM) et qui sont déjà liés par le code INSEE.

Du coup, afin de Harmonisé tout ça et d'évité des répétitions dans les collections, je vous propose une solution et me dire ce que vous en pensez :

On sépare toutes les infos en 3 collections : cities, postalcodes et quartiers

Collection Cities :

  • insee : 97411
  • name : Saint-Denis
  • article :
  • canton :
  • country : RE
  • dep :
  • depName :
  • region :
  • regionName :
  • geo : ...
  • geoShape

Collection postalcodes :

  • cp : 97491
  • insee : 97411
  • alternateCp : 97491 CEDEX
  • alternateName : Sainte-Clotilde
  • article :
  • geo :

Collection Quartiers :

  • iris : 0704
  • insee : 97411
  • name : Bas du Moufia
  • zoneID :
  • geo
  • geoShape

Voilà dit moi ce que vous en pensez

SB

Sylvain Barbot Wed 10 Feb 2016 3:40AM

Super ! Beau travail Raph. Le découpage me parait vraiment pertinent.
Quelques remarques/précisions.

Collection cities :
- La clé devient le code Insee. Il n'y a plus de doublon. Il faudra du coup faire un tri et supprimer les doublons. Par exemple : Saint Gilles les bains, Saint Gilles les haut, La saline... Qui sont des codes postaux de la commune de Saint Paul mais pas des communes à part entière.
- name : le name de notre collection city actuelle est par terrible : il manque les articles et il est en majuscule. Le alternate name de la collection city est pas mal (il a l'article) mais ce n'est parfois pas le nom principale du code insee (entre autre quand il y a plusieurs city pour un même code insee).
- article : on peut garder l'info, mais je ne vois pas comment l'utiliser.

Collection cp :
- alternateCp : est ce que c'est un tableau ?
- article ? Idem cities
- alternateName : pour le coup si on utilise le fichier CEDEX pour charger cette collection, les "name" sont pas mal. D'ailleurs, j'appellerais la colonne "name". D'autant plus que pour avoir un alternateName il faut un name :)

Pour info, voilà un github (https://github.com/pixelhumain/communecter/issues/545) dans lequel j'ai commencé à réfléchir à comment utiliser ses nouvelles infos et relier tout ça sur l'interface.

R

Raphael Wed 10 Feb 2016 5:09AM

Merci :)

Réponse au Remarque/Précision :

Collections Cities :

  • Tout à fait d'accord, sur le code Insee, je l'avais pas noté clairement mais oui , un seul code insee dans cities, on évite les doublons.

  • Pour le name et l'article , j'ai pas vraiment d'avis dessus, après je vois pas non plus l'intérêt de les sépares ( à voir )

Collection cp :

  • alternate cp , je les notés comme un string , enfaîte c'est la version complète du code postal "97491 CEDEX" si ce code postal comporte un CEDEX, un AIR ou un SP, d'après ce que j'ai pu voir les CEDEX son unique (A confirmé). Dans le cas ou c'est juste un code Postal (97490), on n'ajoute pas pas d'alternateCP ou alors on mets alternateCp : "97490"

  • Oui d'accord pour renommer alternateName en name, c'était surtout pour indiquer que ça représenter l'alternateName qui se trouves dans cities et qu'on utiliser pour afficher le nom de la communes