Property talk:P374

From Wikidata
Jump to navigation Jump to search

Documentation

INSEE municipality code
identifier with 5 digits or letters for a municipality or a municipal arrondissement in France, per the National Institute of Statistics and Economic Studies
DescriptionNumber sequence for the identification of municipalities (or municipal arrondissements) in France, assigned by The National Institute of Statistics and Economic Studies (Q156616).
Data typeExternal identifier
Template parameter|insee= in fr:Modèle:Infobox Commune de France
Domain
According to this template: commune of France (Q484170)
According to statements in the property:
territorial collectivity of France (Q583865) or district of the French Southern and Antarctic Lands (Q26807495)
When possible, data should only be stored as statements
Allowed values\d[0-9AB][0-9P]\d\d
ExampleMende (Q191772) → 48095
Paris (Q90) → 75056
Formatter URLhttps://www.insee.fr/fr/statistiques/2011101?geo=COM-$1
Tracking: sameno label (Q28605279)
Tracking: differencesno label (Q24194671)
Tracking: usageCategory:Pages using Wikidata property P374 (Q24194673)
Tracking: local yes, WD nono label (Q24194670)
Related to country France (Q142) (See 651 others)
See alsoINSEE canton code (P2506), INSEE department code (P2586), INSEE region code (P2585), INSEE arrondissement code (P3423)
Lists
Proposal discussionProposal discussion
Current uses
Total40,842
Main statement40,837>99.9% of uses
Qualifier2<0.1% of uses
Reference3<0.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Format “\d[0-9AB][0-9P]\d\d|”: value must be formatted using this pattern (PCRE syntax). (Help)
List of violations of this constraint: Database reports/Constraint violations/P374#Format, hourly updated report, SPARQL
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: L'Oudon (Q1087545), Saint Barthélemy (Q25362), Saint-Martin (Q126125)
List of violations of this constraint: Database reports/Constraint violations/P374#Single value, SPARQL
Item “country (P17): France (Q142)”: Items with this property should also have “country (P17): France (Q142)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Monaco (Q235)
List of violations of this constraint: Database reports/Constraint violations/P374#Item P17, search, SPARQL
Item “coordinate location (P625)”: Items with this property should also have “coordinate location (P625)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P374#Item P625, SPARQL
"exceptions" is incompatible with "mandatory" parameter List of violations of this constraint: Database reports/Constraint violations/P374#Item P131, hourly updated report, search, SPARQL
Item “Commons category (P373)”: Items with this property should also have “Commons category (P373)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P374#Item P373, search, SPARQL
Item “GeoNames ID (P1566)”: Items with this property should also have “GeoNames ID (P1566)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Saint Paul and Amsterdam (Q1681727)
List of violations of this constraint: Database reports/Constraint violations/P374#Item P1566, search, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
List of violations of this constraint: Database reports/Constraint violations/P374#Entity types, hourly updated report
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P374#Scope, SPARQL
Inconsistency between the codes
Place with postal code prefix indicating a departement but located in another departement. (Help)
Violations query: SELECT ?item ?cc ?cp WHERE { ?item wdt:P374 ?cc . #code Insee de commune ?item wdt:P281 ?cp . #code postal FILTER ( ?cc NOT IN( "39274", "44060", "06900" ) ) #valid exceptions FILTER ( SUBSTR(?cp, 1, 2) != "20" ) #excluding Corse 2A/2B != 20 FILTER ( SUBSTR(?cp, 1, 2) != SUBSTR(?cc, 1, 2) ) }
List of this constraint violations: Database reports/Complex constraint violations/P374#Inconsistency between the codes
Unique value
A value must not be used by multiple entities at the same point in time (Help)
Violations query: SELECT DISTINCT ?item ?item2 ?value WHERE { ?item wdt:P374 ?value . ?item2 wdt:P374 ?value . FILTER( ?item != ?item2 && STR(?item) < STR(?item2) ) . MINUS { ?item p:P374 ?st1 . ?st1 ps:P374 ?value; pq:P582 ?end . ?item2 p:P374 ?st2 . ?st2 ps:P374 ?value; pq:P580 ?start . FILTER( ?end < ?start ) } MINUS { ?item p:P374 ?st1 . ?st1 ps:P374 ?value; pq:P580 ?start . ?item2 p:P374 ?st2 . ?st2 ps:P374 ?value; pq:P582 ?end . FILTER( ?end < ?start ) } }
List of this constraint violations: Database reports/Complex constraint violations/P374#Unique value
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Settlement properties
Location
Attributes
Transport
Communication
Identifiers
Demographics
Other

Allowed values

[edit]
  • Allowed value The value has to be five digits long (like 06088 for Nice). Some have leading zero, the Corsican departements have a letter in their code: 2A and 2B, so do the municipality codes: 2A004 for Ajaccio and 2B033 Bastia. --Monsieurbecker (talk) 07:13, 1 April 2013 (UTC)[reply]
The allowed value as a regular expression: ((0[1-9])|([13-9][0-9])|(2[1-9AB]))[0-9][0-9][0-9] --Monsieurbecker (talk) 19:30, 1 April 2013 (UTC)[reply]
I'm not sure how to read exactly your regular expression but the INSEE go from 01001 (L’Abergement-Clémenciat) to 98901 (Île de Clipperton). Some departements, have a lot of commune but some have very few (for instance Paris departement has now only one commune 75001). Maybe it will be better to make a list of the allowed values.
Something else : how should we manage « old » insee code ? (eg. Antony was 75002 until 1968 and is now 92002 ; Veneffles was 35349 until his disparition in 1971, etc.). Cdlt, VIGNERON (talk) 08:05, 3 April 2013 (UTC)[reply]
With the regular expression, I want to say the following: The third, fourth and fith digit, can go from 0 to 9 "[0-9]". The first digit can be a zero, but in this case the second digit cannot be a 0 "0[1-9]". The first digit can be a 1, 3, 4, 5, 6, 7, 8 or 9 and the second can go from 0 to 9 "[13-9][0-9]". If the first digit is a 2, the second can't be a zero, but it can be A or B "2[1-9AB]". I made it only in case we can specify data types later.
About the old codes: I honestly have no idea. Probably, we can add qualifiers as soon as they are available? Do you know if those old codes have been used again? --Monsieurbecker (talk) 15:02, 3 April 2013 (UTC)[reply]
Ok, that's seems fine (except for old corsican codes wich begin by « 20 » before 1976).
Do you know when the're will be qualifiers? (I've heard of it serveral times but didn't see anything coming…). Since the old codes are never attribute again the're used from time to time to point old entities. In the wikipedia it's pretty rare (eg. I use it on fr:Veneffles Q3555470).
Cdlt, VIGNERON (talk) 08:58, 5 April 2013 (UTC)[reply]

Name and length

[edit]

The code Insee (Q156705 see the articles) is not only for the commune but also for regions and departements, peoples and entreprises. Furthermore, the commune code is only the 3 last numbers : Mende (Lozère) is 095 (2 last numbers for oversea communes) ; the two first number is for the departement (48 is Lozère ; 3 first numbers for oversea departement). So the same information (the departement) will maybe twice in the properties , isn't it a problem ? At least, I think I will replace the labels to be more precise : INSEE code -> INSEE commune code (and so on). Cdlt, VIGNERON (talk) 11:09, 31 March 2013 (UTC)[reply]

name of the property: At the beginning, I wanted to use "French municipality key", but then I have chosen the names that can be found in infoboxes. But I understand your concerns, so let's specify the name.
length of the code: In fact, the code commune is only three digits long, but even Insee is using the five digits version to designate the municipalities, see [1] and [2] (CHEFLIEU). I don't understand why it should be a problem to have the information (departement) twice. --Monsieurbecker (talk) 16:39, 31 March 2013 (UTC)[reply]
Ok for the name, the infoboxes are synthetic here we shoul be more specific.
My mistake : the three digits long is the code commune *in the departement* and the five digits long is the code commune *in France*. Two communes could have the same three digits code, Acigné and Ahuillé are both 001 but Acigné is 35001 and Ahuillé is 53001. It's maybe better to stay with the five digits code.
For the double information, I don't know if it's a problem or not ; but I remember that redundancy should be avoid in database.
Cdlt, VIGNERON (talk) 07:29, 3 April 2013 (UTC)[reply]
The 5 digit code will be imported by me RobotMichiel1972 (talk) 20:05, 4 April 2013 (UTC)[reply]
Would you be so nice to inform us when all codes will have been imported? --Monsieurbecker (talk) 22:01, 4 April 2013 (UTC)[reply]

code officiel géographique

[edit]

Apparently, "code INSEE" is a generic name for various codes attributed by INSEE. I think the correct property label should be "code officiel géographique", and that it should also apply to arrondissements (3 digits) and cantons (4 digits). INSEE appear to use those codes as well (example). I do not know if we départements and régions codes are part of the code officiel géographique, they do not appear in the COG search box of INSEE's website. --Zolo (talk) 12:59, 6 April 2013 (UTC)[reply]

The property label is "INSEE municipality code"/"INSEE-Gemeindecode"/"code commune", so it is clear that it only applies to municipalities. I think there should be different properties for different subdivision levels: code région, code département, code commune, code arrondissement, code canton, code pour des pays et territoires étrangers. Why? The different codes have sometimes the same numbers, for example all numbers of the code région exist in the code commune. --Monsieurbecker (talk) 17:59, 6 April 2013 (UTC)[reply]
Oh I see, the initial system was sane but the creation of regions messed everything up. I suppose you are right then, it makes sense to have different properties. --Zolo (talk) 19:23, 6 April 2013 (UTC)[reply]
Actually the name "code officiel géographique" (COG) is only a part of the code defined by INSEE. (INSEE also defines other non-geographic codes, notably "numéro national d'identité" for the physical persons with a legal residence in France (including foreign people that can apply for one if they want to the Social Security or must pay taxes in France), the SIREN for identifying private or public organizations (with or without commercial goals), the SIRET for identifying their legal establishments (important for tax or legal purpose when these establishments follow different fiscal or social regimes for different parts of their activities, though legally the legal responsability is still the organization as a whole).
The COG defines several kinds of codes for different kinds of territorial entities. It does not define any code for other kind of entities that may be competent over multiple territorial entities.
The various codes in COG however do not establish their legal identity as the same code will be reused (incluiding at the same time) for different organisations, and may also be reused over time when their composition change or even if the territorial entitity has no longer any legal identity (e.g. former communes), as it will be used mostly as a shortcut (so ambiguities are still possible). The SIREN should be used instead of COG codes if there's any ambiguity.
INSEE also defines various codes for other non-geographic entities that are also not persons (e.g. the APE codes for encoding activities in organizations, and various odes used for statistic or legal accounting purposes). INSEE also some assigns some codes for the European Union when they are specifically applicable to various activities only in France when they are identifiable to specific persons (for the rest, other standard bodies may assign their own codes that INSEE also reuses; INSEE cooperates with other French or international standard bodies, where it sends to their maintenance agencies some needed authoritative data registered by INSEE into their standard registries). INSEE also internally uses other codes needed for their internal work or for their commercial activities. Verdy p (talk) 17:53, 8 September 2016 (UTC)[reply]
[edit]

I have added an extenral link to INSEE statistics in the commune through MediaWiki:Gadget-AuthorityControl.js. It does not change anything to the property itself, nor to the way client websites can use it, but it provides a quick access to INSEE statistics.--Zolo (talk) 19:51, 8 April 2013 (UTC)[reply]

That's a very good idea! Thank you. --Monsieurbecker (talk) 21:09, 8 April 2013 (UTC)[reply]

Postal code equivalence

[edit]

OpenDataSoft recently published a table of postal and INSEE codes, including the commune name, area and average elevation. I don't know if the data is of better quality than the current Wikidata codes, and if it can be reuse in Wikidata. -- Freedatum (talk) 11:37, 5 December 2013 (UTC)[reply]

The source of this file is « Wikipédia » So it's probably the same quality.
For « commune name, area and average elevation », the official source is the répertoire géographique des communes (RGC) (under free/open licence « licence ouverte », compliant with CC-BY 2.0, not sure for CC0).
Cdlt, VIGNERON (talk) 13:18, 30 January 2014 (UTC)[reply]

Code INSEE pour les autres unités administratives que la commune

[edit]

Il y a un code INSEE pour chaque niveau traité par l'INSEE. Il y a un code INSEE pour les cantons par exemple, rien n’empêche le champs INSEE d'un canton avec son code. Il n'y a aucune ambigüité et sinon le code ne peut que rester vide. Il n'y a aucune raison de réserver le code au seul niveau communal. Ce code est utilisé par la version Espéranto sa description est : Franca ŝlosilo uzata de INSEE (Institut National de la Statistique et des Études Économiques). Il n'est pas fait mention de restriction aux communes.--Pino~eowiki (talk) 11:20, 30 December 2015 (UTC)[reply]

Voir ce diff.
Le libellé français est "code commune INSEE".
Personnellement, je pense qu'il serait mieux de créer une autre propriété pour les cantons : "codes insee canton". Déjà parce qu'il est plus facile de trouver toutes les communes française via une requête, sans à avoir exclure d'autres cas (canton, département, ... qui ont aussi des codes INSEE). De plus, les contraintes en haut de cette page deviennent quelque peu bancale : image (P18), n'a plus trop de sens, coordinate location (P625) sur le chef-lieu à la limite, mais le pire est le format qui n'est plus bon : "xxxxx" pour une commune, "xx xx" pour un canton. Gzen92 [discuter] 15:05, 30 December 2015 (UTC)[reply]
Multiplier les propriétés n'est pas non plus sans risque et complique l'intégration dans l'article. Il n'y a pas vraiment d'obstacles rédhibitoires. Rien n'empêche de libeller en français "code INSEE", les fichiers de cantons et d'arrondissements ne me semblent pas spécialement compliqués à trouver. On n'est pas obligé de renseigner ou d'utiliser l'image ou les coordonnées géographiques et puis une image représentative et les coordonnées du chef-lieu peuvent rendre service. Quant aux contraintes de format, ce n'est pas actuellement un obstacle, elles ne sont pas activées sinon je n'aurais pas pu entrer de code canton. Évidemment, on peut vouloir strictement ré-appliquer le premier jet de définition, mais les conséquences seront difficiles pour la version espéranto et l’intérêt pour d'autres peu évident. Bien cordialement. --Pino~eowiki (talk) 19:31, 30 December 2015 (UTC)[reply]
@VIGNERON, Zolo: qu'en pensez-vous ? Gzen92 [discuter] 09:13, 2 January 2016 (UTC)[reply]
@Pino~eowiki, Gzen92, Zolo, Monsieurbecker: je pense surtout qu'il nous faudrait surtout un spécialiste des codes INSEE parce que le sujet est compliqué et que je ne suis même pas sur que la façon actuelle de faire soit entièrement correcte. Sinon, vu que cette propriété sur Wikidata est réservée depuis longtemps aux communes, il me semble plus prudent de créer des propriétés distinctes pour les codes INSEE des cantons, des arrondissements, des départements, des régions, des pays, des personnes morales et physiques, des établissements, des entreprises, etc. Cdlt, VIGNERON (talk) 10:03, 2 January 2016 (UTC)[reply]
Ne mélangeons pas tout, on parle ici de code d'unité géographique. Actuellement pouvoir logiquement utiliser le code INSEE (P374) pour les cantons et les arrondissements est cohérent et rend réellement service. Si vraiment vous voulez créer un système plus complexe, ne décourager pas les utilisateurs et laisser en place au moins les données rentrées avant que soit acté la mise en place de nouvelles propriétés (dont il faudrait montrer l'utilité). Ce serait faire preuve d'un minimum de pragmatisme et ne pas décourager les bonnes volontés. Si quelqu'un relève un réel problème dans une version quelconque de Wikipédia, hormis des questions de principe comme un attachement à ce qui serait une tradition ou encore des contraintes ou des définitions que l'on peut sans problèmes adapter à la situation, qu'il efface les données rentrées et utilisées dans le cas contraire, j'aurais du mal à comprendre. --Pino~eowiki (talk) 12:11, 2 January 2016 (UTC)[reply]
@Pino~eowiki: donc on ne mélange pas tout les codes INSEE mais on mélange le code spécifique aux communes et celui spécifique aux cantons alors qu'ils ont un format, une utilisation et une histoire différente (sans compté l’ambigüité que cela génère, par exemple : 97402 est à la fois le code de la commune de Bras-Panon et le code de l'actuel canton du Port et celui de l'ancien canton de Bras-Panon). Désolé mais cela ne me semble ni logique ni souhaitable. Créer une nouvelle propriété est facile et permet de distinguer clairement deux codes différents. On pourrait en profiter pour créer les autres codes INSEE (au moins pour les arrondissements, départements et régions ; sans doute aussi les pays). De toute façon, il me semble impossible de ré-écrire les contraintes actuelles de le propriété INSEE municipality code (P374) pour tenir compte à la fois des codes communes et des codes cantons (rien que la contrainte de format à elle seule est difficile à ré-écrire). Ce point en lui seul me semble suffisant pour empêcher son utilisation pour les cantons. Surtout qu'avec le chamboulement de la réforme-refonte des cantons, il y a des problèmes spécifiques qui mérite d'être gérés à part. Cdlt, VIGNERON (talk) 12:40, 2 January 2016 (UTC)[reply]
Effectivement on utilise la même propriété p374 pour le code géographique INSEE du canton et de la commune leur format est différent, (probablement leur histoire aussi mais en ce cas je ne vois en cas cela change concrètement à la question). Leur utilisation également est différente dans un cas cas on parle de commune dans l'autre de canton, mais on s'en sert de la même façon essentiellement pour indiquer le code de l'unité géographique. Il ne peut y avoir d'ambigüité même si les codes sont les même puisque dans un cas on est rattaché à une entité géographique qui est la commune et dans l'autre le canton. De toutes manière cela ne me semble pas franchement le cas 97402 (ou 974 02) est le code de la commune de Bras-Panon mais en général on présente plutôt le canton sous la forme 974 02. Le format n'a besoin d'être réécrit puisque visiblement il n'est pas bloquant. Je vais en refaire le test. Les cantons ont changé leur numéro aussi, on suit l'évolution je ne vois pas le problème. Cordialement. --Pino~eowiki (talk) 14:24, 2 January 2016 (UTC)[reply]
Non, pour le moment, on utilise la propriété INSEE municipality code (P374) uniquement pour les communes (très exactement sur 36881 communes, 45 arrondissements municipaux et 6 anciennes communes). Toutes les contraintes de cette propriété sont faites uniquement et spécifiquement pour les communes. Utiliser cette propriété pour les cantons, c'est rendre inutilisable les contraintes actuelles et donc rendre impossible leur vérification (qui se vérifie a posteriori, tu peux enter 123456789123456789 comme valeur de INSEE municipality code (P374), ce n'est pas bloquant non plus). In fine, cela endommage la fiabilité des données.
Je ne suis pas absolument contre l'utilisation de cette propriété pour les cantons mais il ne faut pas « tester », il faut se poser, réfléchir et modifier les contraintes en conséquences. Il faut par exemple réfléchir au format ; peu importe de mettre l'espace ou non mais il faut que ce soit cohérent. Il faut aussi réfléchir au lien généré (sur canton of Fontaine-lès-Dijon (Q18129) historique, le lien menait à [3] qui n'existe évidemment pas). Certes le contexte (typiquement la valeur de instance of (P31)) permet de savoir si on a affaire à une commune ou un canton (ou autre chose) mais dans l'absolu, cela reste quand même ambigu. Le code INSEE étant normalement doublement unique (ce qui est logique pour un identifiant), les contraintes ci-dessus seront d'autant plus difficile à vérifier si on ajoute les cantons. Avec une propriété spécifique pour les cantons, on ne placerait pas cette contrainte d'unicité.
Pour l'histoire, cela est un peu anecdotique mais cela a des conséquences, par exemple si on veut vérifier la validité des qualificateurs. Les communes ne peuvent avoir un code commune INSEE avec une date de début inférieure à 1941 alors que pour les cantons, la création du code remonte à 1943.
Cdlt, VIGNERON (talk) 15:29, 2 January 2016 (UTC)[reply]
Tout à fait d'accord avec VIGNERON. Perso je vérifie régulièrement la contrainte INSEE municipality code (P374), les 36 000 éléments-communes sont cohérents et surtout complets. Je serais d'avis de créer une propriété pour y retrouver facilement les quelques milliers de cantons. Actuellement, il y a deux cantons qui ont un code INSEE (canton of Fontaine-lès-Dijon (Q18129) et canton of Saint-Apollinaire (Q17623121), plus quelques une que j'ai supprimé il est vrai), quel intérêt ? Gzen92 [discuter] 16:16, 2 January 2016 (UTC)[reply]
Quel intérêt d'avoir un code INSSEE pour les cantons, c'est le même que pour les communes.
Pas du tout! Les codes cantons sont à 4 chiffres (2 pour le numéro de département, 2 pour un numéro d'ordre dans le département; en, outre-mer, 3 pour le département et 1 pour la numéro d'ordre). Donc rien à voir avec les codes communes Verdy p (talk) 12:25, 8 September 2016 (UTC)[reply]
C'est une référence sûre pour l'utilisateur et un identifiant efficace pour créer des liens automatiquement. Utiliser la propriété p374 est une solution qui n'est pas illogique même si cela peut effectivement nécessiter de reformuler les conditions de contrôle : si p131 indique une commune on fait tels tests, si p131 indique un canton on fait d'autres tests. Sinon actuellement nous n'avons pas de propriété pour stocker le code INSEE canton et surtout nous n'avons pas sa valeur dans Wikidata. D'expérience ce n'est pas facile d'obtenir la création d'une nouvelle propriété, surtout si l'on n'est soit même pas complètement persuadé de son utilité et que de surcroit on ne maitrise pas l'anglais. Si vous sentez de taille à l'obtenir, bien sûr elle sera utile, surtout, si vous savez importer automatiquement les valeurs. En attendant cette solution évitez peut-être d'effacer des données qui ne perturbent pas vraiment. Cordialement. --Pino~eowiki (talk) 11:10, 4 January 2016 (UTC)[reply]
(Retour) @Fralambert: qui est un créateur de propriétés, pourra peut-être nous orienter sur le bien-fondé ou non de la création d'une telle propriété. Gzen92 [discuter] 12:52, 4 January 2016 (UTC)[reply]

@Gzen92, VIGNERON, Pino~eowiki: Puisqu’on m’appelle, je vois que INSEE municipality code (P374) utilise formatter URL (P1630). La forme de l'URL est-elle différente pour les communes et les canton? Si oui c'est mieux de faire une nouvelle propriété, comme pour lostbridges.org ID (P1311) et Exceptional heritage of Wallonia ID (P1551). Pino~eowiki, ce n'est pas si difficile de créer une propriété "chaîne", pour autant qu'elle soit d'un niveau administratif suffisant. --Fralambert (talk) 00:08, 5 January 2016 (UTC)[reply]

Merci pour ce point de vue, il semblerait que l'url ne focntionne pas avec les cantons. Gzen92 [discuter] 07:19, 5 January 2016 (UTC
L'url est pour moi pour le moins obscur mais dont acte, donc pouriez vous créer une propriété code INSEE canton ? --Pino~eowiki (talk) 19:24, 5 January 2016 (UTC)[reply]
J'ai fait une demande de création de propriété, n'hésitez-pas à la corriger/compléter. Gzen92 [discuter] 07:33, 6 January 2016 (UTC)[reply]
Merci, j'espère que vous aboutirez, je vais suivre le processus. Cordialement.--Pino~eowiki (talk) 12:16, 6 January 2016 (UTC)[reply]
Demande déplacée. Gzen92 [discuter] 12:31, 6 January 2016 (UTC)[reply]
Bravo vous avez réussi, j'ai suivi la démarche, ce n'est pas évident pour un quidam mais le résultat est là, nous avons une case INSEE propre au canton. Si on la remplit à la main, ce sera peu efficace. Comment peut-on importer automatiquement les données ? Qui sait faire ? --Pinof (talk) 20:04, 17 January 2016 (UTC)[reply]
INSEE canton code (P2506) a été créé.Gzen92 [discuter] 08:22, 18 January 2016 (UTC)[reply]

Code Insee pour les unités administratives infra-communales

[edit]

L'Insee définit aussi des codes pour des unités administratives infra-communales (codes géographiques qui pourtant ne font pour l'instant PAS partie du "code géographique officiel" mais définis en complément car ils ne sont pas régulés de la même façon par l'Etat mais définis en concertation avec les communes):

  • un code à 7 chiffres pour les grands quartiers (terme défini par l'Insee en accord avec les communes concernées), formé des 5 chiffres (ou lettres) du code Insee de la commune (ou de l'arrondissement communal à Paris, Lyon et Marseille) et de 2 chiffres supplémentaires pour chaque grand quartier. Il y en a plus de 2700 en France (dont notamment toutes les communes "irisées"); si la commune n'a pas de "grand quartier" administratrif, l'Insee définit tout de même un grand quartier codé "01" (le libellé est facultatif, ou souvent c'est le nom de la commune entière, ou juste "Quartier n°1" bien que ce soit le seul mais il est nécessaire car le zonage des IRIS est requis dans les communes les plus peuplées). Ce codage a valeur administrative.
  • un code à 9 chiffres pour les IRIS, formé des 7 chiffres du "grand quartier" (y compris le cas du "01" créé artificiellement pour la commune entière non divisée administrativement), et de deux autres chiffres supplémentaires (les IRIS n'ont pas toujours de nom ou c'est un nom descriptif, ou un assemblage d'un ou plusieurs toponymes de lieu-dits ou noms de rues plus ou moins abrégé). Ce codage a valeur essentiellement statistique (il n'y a aucune administration locale), mais sert aussi à définir le découpage électoral (cantons ou circonscriptions législatives). Dans certaines communes, il peut cependant être repris pour correspondre au découpage de comités de quartiers (consultatifs), mais pas aux conseils de quartiers reconnus seulement au niveau des "grands quartiers" administratifs; il peut aussi servir au zonage des services communaux (pour ce que les communes désignent comme "quartiers" ou "sous-quartiers" et non "grands quartiers".
    Il y a aussi un code Insee à 5 chiffres pour les TRIRIS, qui sont des créations de l'Insee utilisées dans des cas spécifiques où les statistiques au niveau le plus fin des IRIS ne peuvent pas être diffusées publiquement (pour des raisons de protection des données personnelles: composition des foyers, revenus, valeurs locatives, taux d'emploi...) et leur regroupement est nécessaire (en général par groupe de trois): en effet les IRIS ont une typologie (qui distingue ceux à vocation d'habitat, de ceux à vocation d'activité et les autres "divers/ruraux"), mais aussi certaines communes entières sont trop peu peuplées. Dans ce cas un TRIRIS peut être formé en assemblant plusieurs IRIS contigus (pas forcément tous de la même commune, mais tous dans la même "unité urbaine").
    Il est formé d'un code de département (le code géographique du département uniquement en métropole ; parfois "00" aussi, en métropole uniquement, pour les TRIRIS dans les unités urbaines à cheval sur plusieurs départements, voire aussi régions ; les codes statistiques "9A" à "9F" sont utilisés pour les départements d'outre-mer à la place des codes géographiques "971" à 976"), suivi d'un code séquentiel à 3 chiffres. Ce codage des TRIRIS a valeur uniquement statistique pour les données *publiques* de l'Insee (il ne sert pas pour les données internes dont l'accès est restreint aux agents administratifs habilités au secret des données privées ou des affaires, dont les agents fiscaux et judiciaires, qui eux ont accès à toutes les données par IRIS, donc aussi les données détaillées sur toutes les communes rurales regroupées dans un TRIRIS). Toutes les données de l'Insee n'utilisent pas les TRIRIS si elles n'ont pas de caractère personnel protégé (par exemple les données sur la population résidente, ou le total de surface bâtie sans autre qualification), c'est une nécessité uniquement demandée par la CNIL. Ne pas confondre les codes Insee de TRIRIS avec les codes Insee de commune ou arrondissement, même s'ils ont le même format et souvent des valeurs similaires.
    Les TRIRIS sont eux-mêmes groupés en unités urbaines utilisant le même principe de codification statistique (réduite à 4 chiffres, deux pour le code du département ou "00" ou "9A" à "9F").

Peut-on définir une sous-propriété pour ces codes Insee (hors COG) manquants dans la méta-classe des propriétés "code Insee" ? (au moins celui des "grands quartiers" à 7 chiffres : "code Insee d'un grand quartier") ?

  • Voir la liste des quartiers de Marseille sur Wikipédia pour un exemple complet (les grands quartiers sont définis au sein de chaque arrondissement communal), mais le même principe s'applique à Paris, Lyon, Rennes, Nantes, etc. avec plus de 2700 codes définis)
  • Ne pas confondre non plus avec les codes définis pour les quartiers de la politique de la ville, de la forme "QPdddnnn", où "QP" abrège "Quartier de la Politique de la ville", "ddd" est le code géographique de département (y compris en outre-mer : les DOM de "971" à "974" et "976", ainsi que les COM dont "978" pour Saint-Martin et "987" pour la Polynésie française), étendu à 3 positions en métropole (avec un zéro initial), et "nnn" est un numéro séquentiel dans cette collectivité.

Cela permettrait ensuite de sourcer correctement les données de population par quartier (elles sont publiées). On ne peut pas forcément créer de lien externe, mais on les trouve au sein des fichiers de données et c'est utile pour faire un rapprochement avec les entités Wikidata.

Verdy p (talk) 16:24, 26 March 2020 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P374&oldid=2269594843"