Property talk:P3182

Documentation

FANTOIR code
unique identifier for streets and public squares in France and Monaco; format: 10 digits/characters

Applicable "stated in" value

FANTOIR (Q3066631)

Data type

External identifier

Domain

geographical feature (Q618123)

Allowed values

\d[\dAB]\d{4}[\dA-Z]\d{3}[A-Z]
(0\d0|1[0-2]0|131|132|1[4-9]0|2[A-B]0|[2-4]\d0|5[0-8]0|591|592|6\d0|7[0-4]0|75[4-8]|7[6-9]0|8\d0|9[0-1]0|921|922|9[3-5]0|97[1-4]|976)\d{3}[0-9A-Z][0-9]{3}[A-Z]

Example

rue Duguesclin (Q23013581) → 3502382660T
rue Beaubourg (Q14629229) → 7541030759S
7541040759M

Related to country

France (Q142) (See 638 others)

Format of the property in Wikidata[edit]

Code of département and direction (3 digits)[edit]

Metropolitan France: INSEE department code (P2586) (2 digits) + 0

Exceptions:

Paris: 754, 755, 756, 757, 758
Bouches-du-Rhône: 131, 132
Nord: 591, 592
Hauts-de-Seine: 921, 922

Exemple for Meuse (Q12631) department: 55+0 → 550

Overseas France: INSEE department code (P2586) (3 digits)

Guadeloupe: 971
Martinique: 972
Guyane: 973
La Réunion: 974
Mayotte: 976

Municipality code (3 digits)[edit]

INSEE municipality code (P374) (or of an arrondissement in Paris, Lyon and Marseille) strictly speaking (only the last three digits of the Wikidata property, without the code of the department).

Exemple for Rennes (Q647): 35238 → 238

RIVOLI code (4 characters)[edit]

The RIVOLI code strictly speaking consist in only 4 characters.

First character:
- normal way (public domain): 1 digit
- way in a building complexe (joint ownership property and housing estate, etc.) : A
- place called: B-W
- pseudo ways (canal, ZAC, hospital and metro station, etc.): X
- temporary way: Y, Z
+ 3 digits

Check letter[edit]

One letter (except I, O and Q).

Comments[edit]

The code FANTOIR in Wikidata is not the same as the key ref:FR:FANTOIR=* in OpenStreetMap (only 10 characters: INSEE municipality code (5 digits) + RIVOLI code (4 characters) + check letter of the original FANTOIR code).
A way that crosses x different communes or arrondissements (in Paris, Lyon and Marseille) has x different FANTOIR codes. Normally, the RIVOLI code is the same.

Example: rue Beaubourg (Q14629229) in Paris: 7541030759S for the 3rd arrondissement (INSEE code: 103) and 7541040759M for the 4th arrondissement (INSEE code: 104).

Resources[edit]

Data[edit]

Fichier FANTOIR des voies et lieux-dits on data.gouv.fr
By departments on collectivites-locales.gouv.fr
Données FANTOIR découpées par direction by Geonov
By INSEE code on openstreetmap.fr (their FANTOIR ID is not the same that we use in Wikidata)

Documentation[edit]

Format “[0-9][0-9AB][0-9]{4}[0-9A-Z][0-9]{3}[0-9A-Z]|”: value must be formatted using this pattern (PCRE syntax). (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/P3182#Format, SPARQL

Item “country (P17): France (Q142), Monaco (Q235)”: Items with this property should also have “country (P17): France (Q142), Monaco (Q235)”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P3182#Item P17, hourly updated report, search

Item “located in the administrative territorial entity (P131)”: Items with this property should also have “located in the administrative territorial entity (P131)”. (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/P3182#Item P131, search, SPARQL

Type “geographical feature (Q618123)”: item must contain property “instance of (P31)” with classes “geographical feature (Q618123)” or their subclasses (defined using subclass of (P279)). (Help)

List of violations of this constraint: Database reports/Constraint violations/P3182#Type Q618123, hourly updated report, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (Help)

List of violations of this constraint: Database reports/Constraint violations/P3182#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value)

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: Boulevard Périphérique of Paris (Q849777)
List of violations of this constraint: Database reports/Constraint violations/P3182#Single value, SPARQL

Format “(0\d0|1[0-2]0|131|132|1[4-9]0|2[A-B]0|[2-4]\d0|5[0-8]0|591|592|6\d0|7[0-4]0|75[4-8]|7[6-9]0|8\d0|9[0-1]0|921|922|9[3-5]0|97[1-4]|976)\d{3}[0-9A-Z][0-9]{3}[A-Z]”: value must be formatted using this pattern (PCRE syntax). (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/P3182#Format, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (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/P3182#Entity types

Localisation inconsistency
Inconsistency between this identifier and the INSEE municipality code (P374) of the commune of the located in the administrative territorial entity (P131). (Help)
Violations query:

SELECT ?item WHERE { 	?item wdt:P3182 ?FANTOIR ; wdt:P131 ?localisation . 	?localisation wdt:P374 ?INSEE . 	FILTER( substr(?FANTOIR, 1, 2) != substr(?INSEE, 1, 2) && substr(?FANTOIR, 4, 3) != substr(?INSEE, 3, 3) ) }

List of this constraint violations: Database reports/Complex constraint violations/P3182#Localisation inconsistency

Type inconsistency
Inconsistency between the type and the instance of (P31). (Help)
Violations query:

SELECT ?item WHERE { 	?item wdt:P3182 ?FANTOIR ; wdt:P31/wdt:P279* wd:Q83620 . 	FILTER regex( substr(?FANTOIR, 7, 1) , "[A-Z]" ) }

List of this constraint violations: Database reports/Complex constraint violations/P3182#Type inconsistency

Type inconsistency
When there is multiple value, the Rivoli codes (last four digit before the final control key) should be the same. (Help)
Violations query:

SELECT * WHERE {   ?q wdt:P3182 ?id1 .   ?q wdt:P3182 ?id2 .   FILTER ( ?id1 != ?id2 )   BIND ( SUBSTR(?id1,7,4) AS ?rivoli1 )   BIND ( SUBSTR(?id2,7,4) AS ?rivoli2 )   FILTER ( ?rivoli1 != ?rivoli2 )   MINUS { ?q wdt:P131+ wd:Q90 } }

List of this constraint violations: Database reports/Complex constraint violations/P3182#Type inconsistency

Conditions d'utilisation[edit]

Ping Tubezlob, Benoît Prieur, Pymouss, Cquest, JLZIMMERMANN,

Pour information, la propriété vient d'être créée et j'ai commencé à l'ajouter sur une centaine de rues de Rennes pour voir ce que cela donne. J'ai déjà diverses questions :

que faire quand il y a un problème de correspondance entre les deux bases, par exemple quand :
- une rue possède deux codes FANTOIR ? (je pensais cela impossible mais pour la Q23296813 j'ai 3502386711W et 3502389914C dans le fichier départemental sur http://www.collectivites-locales.gouv.fr), faute de mieux je propose de mettre les deux...
- je n'ai pas trouvé le cas inverse où il y a deux éléments sur Wikidata mais dans ce cas (sauf exception ?), la solution serait simplement de fusionner les deux éléments.
- quand une rue est présente dans une base et pas dans l'autre, par exemple Q23296785 ou Q23296896 ne semble pas présente dans FANTOIR (mais on n'a pas la main à ce niveau...) et inversement énormément de rues ne sont pas encore dans Wikidata (sont-elles à créer à la chaîne ? il me semble que l'on manque un peu d'informations et que l'on créerait des éléments un peu vides...).
pour ceux s'y connaissent en contraintes Wikidata, j'en ai mis quelques unes ci-dessus (le rapport de violation de contrainte ne sera générée que demain) mais il en manque sans doute et j'ai peut-être fait des erreurs (notamment avec single et unique, je ne suis pas sur de ce qui en est, cf. Q23296813 dont je parle plus haut ; je ne suis pas forcément spécialiste des contraintes complexes).
idem pour Property:P3182 où j'ai pu oublié des informations (j'espère tout de même avoir couvert l'essentiel).

Pour voir ce que cela donne, voici un exemple de requête SPARQL lisant l'identifiant Wikidata, son libellé en français, le code FANTOIR, le lieu où se trouve l'élément (pour le moment, il n'y a que Rennes) :

SELECT ?item ?itemLabel ?FANTOIR ?typeLabel ?localisationLabel WHERE {
	?item wdt:P3182 ?FANTOIR .
    optional { ?item wdt:P31 ?type }
	optional { ?item wdt:P131 ?localisation }.
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

Cdlt, VIGNERON (talk) 14:47, 20 September 2016 (UTC)[reply]

@VIGNERON: Bonjour,

Pour le cas des doubles codes (premier point), il parait en effet logique de mettre les deux. Même si l'un était plus valide que l'autre, comment le saurions-nous ? Si jamais il y a deux éléments Wikidata ayant le même code FANTOIR, il faudra sûrement fusionner, à part si ce sont différentes sections d'une même rue (je ne sais pas si ça existe) où il faudra créer alors un élément supérieur (de la voie, donc avec le code) qui englobe les éléments des différentes sections (sans le code).

Pour la création à la chaîne (deuxième point), cela pourrait être intéressant mais le problème est que les noms des rues sont en capitales (et donc sans accents). Il faudrait donc corriger les noms avant l'import…

En tout cas, merci beaucoup de t'occuper de FANTOIR si bien ! Tubezlob (🙋) 17:07, 20 September 2016 (UTC)[reply]

Et d'ailleurs, quelle méthode as-tu utilisé pour ajouter les codes FANTOIR aux rues rennaises ? Tubezlob (🙋) 17:10, 20 September 2016 (UTC)[reply]

@Tubezlob: pour les codes en doubles, je pense que c'est le mieux mais préfère attendre un peu d'autres avis (Benoît Prieur, Pymouss, Cquest, JLZIMMERMANN ?) avant de les ajouter en double dans Wikidata (qui est une base de données et où les identifiants sont théoriquement unique). Pour le cas de deux sections d'une même rue, je ne sais pas non plus si cela existe... Je n'ai rien vu pour Rennes en tout cas (les rues ayant des codes en doubles ne me semble pas avoir de sections particulières et quand bien même, comment les repérer ?). Le cas le plus proche que j'ai repéré est celui où une rue traverse deux communes (3502384820R et 3502810100Y pour le Boulevard Jean Mermoz (Q26958032) entre Rennes et Saint-Jacques-de-la-Lande), mais dans ce cas-là je propose d'utiliser un qualificateur pour distinguer les deux valeurs (la question est lequel : located in the administrative territorial entity (P131) ? applies to part (P518) ? un autre ?).

Pour la méthode d'import, j'ai utilisé le classique trio que je maîtrise : Query, Calc et QuickStatement. Je prends le fichier FANTOIR départementale d'Ille-et-Vilaine, je prends les lignes correspondants à Rennes (code commençant en 350238), j'en extrais les 11 premières caractères (id qui sera à importer) et les 30 suivants (dénomination), je ne garde que les lignes dont la dénomination commence par « RUE ». Je fait une requête SPARQL pour avoir les rues de Rennes (identifiant et libellé). Je trie par ordre alphabétique la dénomination FANTOIR et le libellé Wikidata et je compare à la main (que j'ai convertis en capitale pour aider visuellement, là je pourrais sans doute utiliser OpenRefine pour le faire automatiquement mais je voulais le faire à la main pour mieux apprendre et comprendre comment était les données FANTOIR, spoiler : on a vu pire mais on a surtout vu plus propre et plus cohérent). Enfin, pour les données alignées, j'envoie le tout dans QuickStatement.

Bilan de cette première expérience : sur les 928 voies de type street (Q79007) situé à Rennes (Q647), j'ai pu trouvé un FANTOIR code (P3182) pour quasiment toute ! Actuellement il y en a que 8 sans code FANTOIR mais ce sont uniquement des rues avec 2 codes FANTOIR que je préfère laissé en suspens (et finalement aucune rue sans code FANTOIR, j'ai finalement trouvé pour Q23296785 et Q23296896, il s'agissait d'un problème de dénomination allée/rue). Inversement, il y a 967 lignes dans le fichier FANTOIR dont la dénomination commence par « RUE » ; donc là aussi on a quasiment tout dans Wikidata (et du coup, puisqu'il n'en manque que 39 je vais regarder à la main pour faire d'éventuels ajouts ou corrections). Je suis assez content et heureusement surpris que les données s'alignent aussi bien, il ne reste plus qu'à voir pour d'autres villes (il faut dire que j'avais passé du temps à préparer la création des rues de Rennes sur Wikidata, la situation pour d'autres villes n'est peut-être pas aussi bonne...) et surtout à tester l'interconnexion avec des outils externes comme OSM ou BANO

.

Cdlt, VIGNERON (talk) 08:00, 21 September 2016 (UTC)[reply]

VIGNERON, Benoît Prieur, Pymouss, Cquest, JLZIMMERMANN :

J'ai voulu essayé d'importer les codes FANTOIR pour les voies parisiennes, mais je me suis rendu compte que chaque rue avait deux identifiants ! Seul le quatrième chiffre change : soit 0, soit 1. Par exemple pour la rue du Faubourg-Montmartre (Q3452296) (9^e arrondissement), on a :

7540093510RRUE DU FBOURG MONTMARTRE (ligne 877) dans la section 754009 APARIS 09
7541093510FRUE DU FBOURG MONTMARTRE (ligne 2104) dans la section 754109 JPARIS 09

Je n'arrive pas à comprendre la subtilité, ce serait donc le code commune qui change ? Cependant OpenStreetMap semble utiliser toujours la version avec le 1 (voir https://www.openstreetmap.org/way/34681880).

Sur data.iledefrance.fr, ça donne ça.

Savez-vous que faire ? Tubezlob (🙋) 09:57, 29 October 2017 (UTC)[reply]

(rapidement parce que je suis à la WikidataCon à Berlin, je regarderais plus en détail la semaine prochaine) Est-ce vraiment toutes les rues ? Ou juste certaines rues, par exemple celle à cheval sur deux arrondissements ? Cela vaudrait aussi la peine de faire une requête SPARQL croisée entre Wikidata et OSM sur cet outil Query WD+OSM. Cdlt, VIGNERON (talk) 10:35, 29 October 2017 (UTC)[reply]

@VIGNERON: Cela semble concerner la quasi-totalité des entités de FANTOIR. Ce n'est pas les rues qui sont à cheval sur deux arrondissements, car on a par exemple le boulevard Haussmann (Q895076) (à cheval sur le 9^e et le 8^e arrondissement) qui a donc quatre identifiants :

7540094485A

7541094485R

7560084485J

7561084485Z

Quand on met côte à côte les deux parties comprenant les identifiants d'une même rue, on arrive à quelque chose de très similaire (voir cette capture d'écran). Sur cette capture, on remarque juste que le square D'Estienne-d'Orves (Q3494546) (ligne 2143) n'a qu'un seul identifiant dans le fichier (ce que j'ai vérifié en faisant une recherche). Sinon, je pense que l'écrasante majorité des entités ont un identifiant double.

J'ai trouvé comme autre exemple avec un identifiant unique la Terrasse Émilienne-Moreau-Évrard (Paris) (Q19902885), qui est une voie inaugurée en 2013.

Tubezlob (🙋) 11:41, 29 October 2017 (UTC)[reply]

@Tubezlob: à regarder plus précisément mais je dirais que si les deux valeurs sont identiques sauf pour le 4e chiffre, peut importe, on choisi d'en prendre un ou l'autre et on peut déduire l'autre automatiquement. Il faudrait tout de même savoir d'où cela vient et pourquoi. Sur OSM, ne sont apparemment utilisées que les variantes avec le 1 ( tinyurl.com/y9m2rh6s ). Cdlt, VIGNERON (talk) 12:53, 29 October 2017 (UTC)[reply]

il y a 2 FANTOIR par rue qui diffère d'un 0 ou 1 selon le "sens" aller/retour. le détail est normalement sur la page wiki fantoir d'osm Marc wik (talk)

@Marc wik: Merci beaucoup pour ta réponse ! La page que tu cites est bien celle là : https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR ? Je ne vois pas de mention de sens aller-retour.

Et donc pourquoi avoir fait le choix sur OpenStreetMap d'utiliser uniquement le 1 ? Doit-on faire de même sur Wikidata ? Tubezlob (🙋) 18:07, 29 October 2017 (UTC)[reply]

oui cette page dit "(dans les fichiers sources de la DGFiP, un "code Direction" à un chiffre est ajouté pour former le code FANTOIR allongé à 11 caractères ; en outre-mer, ce code répète le troisième chiffre du département ; en métropole il correspondait à d'anciennes directions locales ou aux sous-préfectures mais n'a plus d'usage réel ; ce caractère n'est pas distinctif mais est pris en compte pour le calcul de la clé de contrôle) ;"sur osm, on vire ce chiffre qui n'a plus de sens et on encore le code a 10 chiffres. la rue https://www.openstreetmap.org/way/34681880 dont vous parliez a un code de 10 chiffres dans osm Marc wik (talk) 19:05, 29 October 2017 (UTC)[reply]

Après discussion sur l'IRC #osm-fr avec Marc wik et sur le mailing list [OSM-talk-fr], il apparaît qu'en fait, chaque rue pourrait avoir deux codes FANTOIR sans considération des rues sur plusieurs communes avec en 4^e position un 0 ou un 1, et donc une clé de contrôle (lettre en 11^e position) différente. Sur OSM, la clé ref:FR:FANTOIR=* ne correspond en fait pas au code FANTOIR à proprement parler, mais à un code constitué du code commune INSEE (5 caractères) puis du code RIVOLI (4 caractères, se trouvant sur le code FANTOIR original à la position 7-10).

Il semble donc que la contrainte de valeur unique est erronée.

On a donc plusieurs solutions :

stocker les deux codes
en choisir arbitrairement un en établissant une règle
faire un code à notre sauce comme OSM, ce qui ne me semble pas être dans l'esprit de Wikidata
stocker uniquement le code RIVOLI, mais ce code n'est unique que dans une seule commune, se pose alors le problème des rues qui sont sur deux communes et des communes fusionnées

La meilleure solution semble donc être, comme le pense également Marc wik, de stocker les identifiants en double (voire plus)

On a donc dans ce fichier :

des rues avec identifiant unique
des rues avec deux identifiants : 0 ou 1 en 4^e position (voire plus si la rue est sur plusieurs arrondissements ou communes). Cela semble concerner la quasi-totalité des rues de Paris, apparemment moins ailleurs en France (à vérifier)

@VIGNERON: Est-ce que cela te convient également ?

Tubezlob (🙋) 22:36, 29 October 2017 (UTC)[reply]

@Marc wik: NOUVEAU REBONDISSEMENT : 😂 Je me suis en fait rendu compte que tous les codes qui utilisent le 0 (au moins à Paris) ont une date d'annulation égale à 2001257. Ces codes ne seraient donc plus valides depuis 2001 ! Ce qui explique qu'OSM n'utilise que les codes actuellement en vigueur (avec le 1). Pour le reste de la France, j'ai par exemple regardé le département de la Meuse, et il ne semble y avoir aucun doublon dû à une date d'annulation.

J'ai utilisé pour cela les fichiers de Geonov découpés par directions.

On va donc importé sur Wikidata que les identifiants qui sont actuellement en vigueur (avec le 1 pour Paris).

Tubezlob (🙋) 09:42, 30 October 2017 (UTC)[reply]

Tubezlob Très intéressant, merci pour tout ce boulot de recherche et d'élagage ! (surtout que j'avais toujours compris la caractère direction dans le sens service avec un directeur comme dans DGFiP et non comme aller-retour). Du coup, effectivement, on peut n'importer que les codes en vigueurs mais en théorie on peut aussi importer les anciens codes et les indiqués comme tel (avec un end time (P582) et un rang normal alors que le code actuel aurait un rang privilégié) après cela me semble un peu overkill et pas forcément nécessaire.

Inversement, pour les codes actuels en 1, as-tu une start time (P580) à mettre en qualificatif ?

Cdlt, VIGNERON (talk) 08:20, 31 October 2017 (UTC)[reply]

@VIGNERON: Pour ce qui est du code direction, en fait selon le mailing list, le code direction serait bien le 3^e chiffre. 009 et 109 serait en fait une espèce de confusion de FANTOIR entre code postal et code INSEE. On peut donc théoriquement importé les deux identifiants : celui avec le 0 avec une date de début au 15 mars 1988 (la plupart du temps) et une date de fin au 25 juillet 2001 (la plupart du temps aussi) et l'identifiant avec le 1 avec une date de début au 25 juillet 2001.

Le plus simple est je pense d'utiliser les fichiers Geonov qui sont bien à jour, nettoyés, et beaucoup plus facile d'utilisation.

Est-ce que ça vaut le coup d'importer les vieux aussi ? Je ne sais pas, mais ce n'est peut-être pas une si mauvaise idée, on aurait vraiment des données complètes comme ça.

Par contre, je ne crois pas que j'aurai le temps de me charger de l'importation, ça a été plus compliqué que prévu et cela va être sûrement au-delà de mes compétences… Si tu peux t'en charger, ça serait super. Ou peut-être faire une requête pour un bot ?

Tubezlob (🙋) 08:59, 31 October 2017 (UTC)[reply]

Ah oui, j'avais oublié mais il est vrai qu'OSM tronque étrangement l'identifiant FANTOIR en retirant le code direction (et d'ailleurs, je viens de vérifier, c'est bien la direction service avec un directeur et non aller-retour, ma compréhension d'origine était donc correcte). Du coup, le troisième caractère sur OSM, ce n'est plus le code direction. Donc, OSM utilise 751015409E pour way/53578245 (10 caractères) là ou le fichier FANTOIR donne l'identifiant 7541015409E (11 caractères) et donc Wikidata (Rue des Lavandières-Sainte-Opportune (Q3451887)) doit logiquement faire de même.

Pour les vieux, je dirais que cela ne vaut pas forcément le coup, l'utilité est moindre. L'avantage d'indiquer explicitement les vieux est d'éviter que quelqu'un ne sachant pas que l'ancien identifiant n'est plus en vigueur ne l'ajoute en le pensant manquant et oublie d'indiquer qu'il n'est plus en vigueur mais c'est un avantage très relatif.

Pour l'import, je peux te montrer comment faire avec QuickStatements ou bien l'on peut demander un bot. De toute façon, dans les deux cas, la première étape est de faire et de fournir l'alignement entre Fantoir et Wikidata (partie parfois assez compliquée, rien que pour une centaine de rues de Rennes, cela m'avait pris pas mal de temps), le plus simple est encore plutôt de faire cela sur un tableur.

Si tu peux patienter quelques jours, je peux essayer de construire un tutoriel pas à pas (en reprenant l'exemple de Rennes - que je dois finir depuis plus d'un an - et tu pourras faire de même pour Paris si tu acceptes de servir de cobaye, on pourra alors améliorer le tutoriel ;) ).

Cdlt, VIGNERON (talk) 10:14, 31 October 2017 (UTC)[reply]

Merci pour la proposition ! C'est vrai qu'un tutoriel ne serait pas de trop (les informations sur comment utiliser les outils externes étant quand même pas terribles sur Wikidata, on vient seulement de créer Help:QuickStatements). J'avais fait un truc dans le genre lorsque j'avais importé les INSEE countries and foreign territories code (P3422) mais j'ai dû employer des méthodes archaïques et cela ne portait que sur environ 250 éléments. Je veux bien servir de cobaye, pas de souci ! Seulement j'ai peur de ne plus avoir trop de temps en fin de semaine (je suis en vacances actuellement mais ça reprend bientôt) et mes études ne me permettent plus de contribuer pendant la semaine ou les week-ends. Mais si tu fais un tutoriel ce serait vraiment super et je trouverai quand même bien le temps de le lire et de faire des tests, et éventuellement des commentaires !

Tubezlob (🙋) 11:03, 31 October 2017 (UTC)[reply]

@VIGNERON: Après presque un an, j'ai enfin commencé les imports pour Paris. J'ai fait le premier cinquième (Paris est divisé avec cinq codes directions, donc il y a 754, 755, 756, 757 et 758) avec OpenRefine 3.0 et ça c'est plutôt bien passé ! J'ai pû reconcilier 92 % de FANTOIR 754 avec Wikidata. Certains éléments (de squares notamment) n'existent pas sur Wikidata, mais surtout il y a des entrées FANTOIR dont je n'arrive pas à comprendre ce qu'elles désignent, mais qui je pense ne correspondent pas à des éléments que l'on pourrait créer sur Wikidata. Je verrai après avoir fait tout Paris s'il y a beaucoup d'éléments de Wikidata qui n'ont pas d'identifiant FANTOIR. Tubezlob (🙋) 13:44, 30 September 2018 (UTC)[reply]

fantoir <> rivoli[edit]

Je pense qu'il est erroné de dire que le code Fantoir s'appelle aussi Rivoli. Rivoli n'est qu'une partie de la clef Fantoir, ce n'est donc pas la même chose. Si on veux être puriste, Rivoli nécessiterait une entrée séparée avec éventuellement un lien comme sous-partie de la référence Fantoir. Marc wik (talk) 18:46, 30 October 2017 (UTC)[reply]

Oui c'est un raccourci (comme pour clef/code/identifiant), ceci dit, je ne crois pas qu'il soit écrit nulle part que fantoir = rivoli. Cdlt, VIGNERON (talk) 07:56, 31 October 2017 (UTC)[reply]

L'erreur se trouve en haut de la page : Alias "code RIVOLI" Marc wik (talk) 17:36, 13 November 2017 (UTC)[reply]

@Marc wik: oui mais du coup c'est un alias (par définition, ce n'est donc pas vraiment équivalent), du coup cela me semble logique et correct, non ? Si les gens cherche une propriété code RIVOLI c'est bien sur cette propriété qu'ils doivent arriver ; même si ce n'est pas exactement ce qu'il cherchait c'est ce qui en est le plus proche. Cdlt, VIGNERON (talk) 18:02, 13 November 2017 (UTC)[reply]

Un alias me semble assez différent d'un sous-élément. Je trouve qu'il serrait mieux de faire une sous-clef Rivoli mais vu mon niveau proche de 0 en wikidata, j'ignore si c'est possible et encore moins comment faire, d’où ma suggestion "pour ceux qui savent faire" :-) Marc wik (talk) 18:22, 13 November 2017 (UTC)[reply]

Oui c'est différent et oui, si on était sur un élément, on devrait plutôt faire un sous-élément (je me le note pour le faire plus tard d'ailleurs, il faudrait aussi créer un élément FANTOIR, j'avais oublié mais je me le re-note) mais là on est sur une propriété, une sous-propriété serait inutilement redondante (sauf erreur, je ne suis pas spécialiste du FANTOIR mais cela me semble une manipulation très simple de récupérer le RIVOLI à partir du FANTOIR, pour reprendre l'exemple originel : Q23013581, fantoir = 3502382660T - suivi des autres caractères si on veut être puriste - et rivoli = 2660T ). Cdlt, VIGNERON (talk) 18:55, 13 November 2017 (UTC)[reply]

Il y a deux termes qui s'appellent Rivoli :

1. il s'agit de l'ancien nom du fichier FANTOIR, qui était alors le fichier RIVOLI, pour "répertoire informatisé des voies et lieux-dits"

2. la clef de contrôle qui donne le dernier caractère A-Z (sauf O I Q) des codes du fichier actuel

Le code rivoli et le code fantoir, dans des casses variées, semblent aussi parfois être utilisés de manière interchangeables par différentes administrations et producteurs de données, en fonction de leurs mises à jour des leurs documentations et systèmes informatiques, incluant la partie INSEE avec code de direction. --Dereckson (talk) 05:34, 13 January 2023 (UTC)[reply]

Property talk:P3182

Contents

Documentation

Format of the property in Wikidata[edit]

Code of département and direction (3 digits)[edit]

Municipality code (3 digits)[edit]

RIVOLI code (4 characters)[edit]

Check letter[edit]

Comments[edit]

Resources[edit]

Data[edit]

Documentation[edit]

Conditions d'utilisation[edit]

fantoir <> rivoli[edit]

Navigation menu

Property talk:P3182

Documentation

Format of the property in Wikidata[edit]

Code of département and direction (3 digits)[edit]

Municipality code (3 digits)[edit]

RIVOLI code (4 characters)[edit]

Check letter[edit]

Comments[edit]

Resources[edit]

Data[edit]

Documentation[edit]

Conditions d'utilisation[edit]

fantoir <> rivoli[edit]

Navigation menu

Search