Ajoute à ça que les EPCI à FP (et même les autres EPCI) ne sont ps restreints à 1 seul département, mais peuvent être interdépartementaux voire même interrégionaux.
On ne peut donc pas coder en "poupée russe" puisqu'on aura des communes avec un code département différent de celui de l'EPCI (qui n'a pas de codification hiérarchique mais juste la codification nationale du SIREN, ignorant le code département, De même les codes SIREN des communes ne peuvent pas être déduits partout du code commune (c'est faux dans certains départements en métropole et en outremer le mode de formation est différent de celui le plus communément utilisé en métropole) Les SIREN n'étant pas des codes géographiques non plus mais des codes d'identité de la personne morale, ils ne sont attribués dans des tranches par département que sur leur siège est restreint à un seul département et ne peut pas en changer. Même les nouveaux cantons ne peuvent plus réutiliser un codage en "poupée russe" par "département-arrondissement-canton" puisqu'ils sont à cheval sur les arrondissements Dans le passé déjà, il y a longtemps, le codage en poupée russe des communes par canton a aussi été abandonné (les fractions cantonales de communes sont déjà très vieux et se sont poursuivis avec les fusions de communes tombant à cheval sur plusieurs cantons, et les cantons historiques, judiciaires ne sont plus utilisés par le découpage judiciaire qui prend des communes entières, l'INSEE ayant alors créé les "cantons-ou-villes", ainsi que les "pseudo-cantons" plus restreints que les cantons électoraux, et qui excluent les communes fractionnées codées à part en "canton-ou-ville" distinct avec un code canton spécial) Le code géographique de l'INSEE (aussi simple qu'il paraisse) pourrait être abandonné pour ne plus utiliser que les codes SIREN des personnes morales : 9 chiffres pour toutes les collectivités (communes, départements, régions, EPCI à FP ou non) et tous les établissements publics de l'Etat (préfectures et sous-préfectures, représentations de la république dans les COM) et n'identifiera plus le type/statut qui devra donc être codé à part. (L'Insee codifie déjà les types de communes). Il ne restera alors que les codes ISO 3166-2 (pas sûr qu'ils soient mis à jour avec les nouvelles régions...) Que serait un code en poupée russe juxtaposant les séries de 9 chiffres et d'autres codes pour des entités (arrondissements, cantons) qui ne sont pas des personnes morales (et n'ont donc pas de SIREN) ? Indigeste en plus que cela ne marche pas ! Il faut des clés séparées et faire un codage relationnel (non hiérarchique), utilisant une table annexe de correspondance des clés pour les cas de relations M:N et pas seulement 1:N (les lignes de la table annexe ne sont pas des entités; 3 tables en tout pour gérer deux types d'entités) c'est un principe universel de modélisation des bases de données (même avec la veille méthode française "Merise" qui était enseignée il y a encore une vingtaine d'années mais ça doit être fini je pense, ou avec la norme UML actuelle beaucoup plus riche). Le 13 février 2015 10:51, Christian Quest <cqu...@openstreetmap.fr> a écrit : > > Le 13/02/2015 10:14, Tony Emery a écrit : > > Il faudrait songer, du coup, à des clé en poupée russe, comme on a dans > les > > GEOFLA où la commune porte les identifiant des découpages supérieurs dans > > lesquelles elle se trouve (départements, epci, région, arrondissement). > > > > > > Dans GEOFLA, tu as des attributs pour chaque commune qui t'indique sont > appartenance au découpages supérieurs, mais le code INSEE d'une commune > ne contient que le code du département en préfixe. > > Pour les EPCI, ma source c'est ça: > > http://www.collectivites-locales.gouv.fr/liste-et-composition-des-epci-a-fiscalite-propre > > Les fichiers indiquent à quel EPCI chaque commune appartient. > > Je viens de demander les données 2015. > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
