ref:FR:FANTOIR

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

ref:FR:FANTOIR

Jérôme Amagat
Bonjour,

D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=* https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :

Il y en a beaucoup dans l'Ain ajouté par chabe01 (https://www.openstreetmap.org/user/chabe01), je vois aussi qu'il a ajouté tous récemment des ref:FR:FANTOIR=* avec 11 caractères en région parisienne. Et j'ai l'impression qu'il ajoute un 0 entre le département et le code commune comme il est dit dans le wiki.

Déjà il faudrait le contacter pour lui dire qu'il commet une erreur et que les outils https://dev.cadastre.openstreetmap.fr/fantoir/ sont bien utiles pour l'ajout des adresses, il n'a pas l'air de les utiliser :)
Si ça tente quelqu'un de le contacter et de chercher si d'autres contributeurs commette cette erreur.

Mais aussi, je pense qu'il faudrait faire une modification de masse pour enlever ce caractère en trop mais tout ne viens pas de lui et comment bien choisir les ref qui ont ce 0 en trop ?

Faut il obligatoirement 10 carractères ?

Il y a aussi beaucoup de valeur de ref:FR:FANTOIR qui n'ont ni 10 ni 11 caractères : https://overpass-turbo.eu/s/OSZ
Il y en a qui ne sont pas faux : plusieurs code séparer par des ";"
Il y a je pense des valeurs avec seulement le code rivoli sur 4 caractères.
Pour certain il y a un fantoir avec "-" suivie de 1 ou plusieurs caractères derrière.


Comment pourrait on améliorer tout ça ? :)

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Vincent de Château-Thierry-2

> De: "Jérôme Amagat" <[hidden email]>
>
> Déjà il faudrait le contacter pour lui dire qu'il commet une erreur
> et que les outils https://dev.cadastre.openstreetmap.fr/fantoir/
> sont bien utiles pour l'ajout des adresses, il n'a pas l'air de les
> utiliser :)
> Si ça tente quelqu'un de le contacter et de chercher si d'autres
> contributeurs commette cette erreur.

Merci Jérôme pour la veille.
Je viens de laisser un commentaire sur un de ses changesets : https://www.openstreetmap.org/changeset/78252330

On verra s'il répond (et quoi) pour mieux aviser la suite.

vincent

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Vincent de Château-Thierry-2

> De: "Vincent de Château-Thierry" <[hidden email]>
>
> Merci Jérôme pour la veille.
> Je viens de laisser un commentaire sur un de ses changesets :
> https://www.openstreetmap.org/changeset/78252330
>
> On verra s'il répond (et quoi) pour mieux aviser la suite.

Chabe01 a lu mon commentaire, y a répondu et a engagé une correction massive de ses derniers changesets. Une bonne chose. Mais en observant ses autres changesets récents je vois qu'il/elle fait de l'import trop massif d'adresses pour assurer une quelconque qualité d'intégration, cf.:
https://www.openstreetmap.org/changeset/78259779
La discussion du changeset a donc continué... j'espère que la méthode changera un peu aussi, au profit d'un rythme moins soutenu. A suivre.

vincent

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Jérôme Seigneuret-3
C'est pas le seul dans ce cas. J'ai discuté avec le responsable SIG d'une intercommunalité qui bascule les données en important tous les points d'adresse sans vérification depuis l'export de Fantoir.

Pour eux OSM est La données d'entrée donc tous doit y être... La vérification passe au deuxième plan.

L'adressage varie fortement d'année en année. fusion cadastrale avec une adresse création de copro. Ajout de numéro ou nom de rue sur des lotissements.

Bref le point d'entrée pertinent et à jour est difficile à trouver. On fait des DSP (eau) et de la redevance  incitavice (déchets) et on arrive pas à avoir des données pertinentes à jour des communes et encore moins à définir un process pour gérer l'actualisation (problème de moyens et de temps?)

Quelqu'un a déjà défini un processus pour les mise à jour (exemple: renommage de rue, changement de sens de circulation , création de numéro, changement d'un adressage en mode métrique ... sur la base d 'arrêté de voirie?


Le mer. 11 déc. 2019 à 16:29, Vincent de Château-Thierry <[hidden email]> a écrit :

> De: "Vincent de Château-Thierry" <[hidden email]>
>
> Merci Jérôme pour la veille.
> Je viens de laisser un commentaire sur un de ses changesets :
> https://www.openstreetmap.org/changeset/78252330
>
> On verra s'il répond (et quoi) pour mieux aviser la suite.

Chabe01 a lu mon commentaire, y a répondu et a engagé une correction massive de ses derniers changesets. Une bonne chose. Mais en observant ses autres changesets récents je vois qu'il/elle fait de l'import trop massif d'adresses pour assurer une quelconque qualité d'intégration, cf.:
https://www.openstreetmap.org/changeset/78259779
La discussion du changeset a donc continué... j'espère que la méthode changera un peu aussi, au profit d'un rythme moins soutenu. A suivre.

vincent

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


--
Cordialement,
Jérôme Seigneuret

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

deuzeffe
In reply to this post by Jérôme Amagat
Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> Bonjour,
>
> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> https://overpass-turbo.eu/s/OSX

D'après la description du fichier FANTOIR
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
semble avoir été ràz, donc ignoré dans la version finale ?

Si quelqu'un y voit plus clair que moi...

--
deuzeffe - pas le neurone en face de la synapse

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

verdy_p
Le "code direction" n'a plus d'intérêt, c'est un champ à priori historique puisqu'il n'y a plus qu'une seule direction par département.

Cependant pas sûr qu'il ne reste pas de doublon si on supprime ce code (par exemple à Paris et les quelques autres départements où il y a eu plusieurs directions). Il faudrait vérifier s'il est encore utile pour des distinctions de rues qui n'auraient pas été renumérotées.

Cependant pour les DOM, ce champ contient le 3e chiffre du département, et dans les autres il était à zéro (sauf dans les départements à plusieurs directions). Et on ne peut alors pas supprimer ce chiffre sans causer de sérieux problèmes de doublons dans les DOM à moins de le placer comme premier chiffre du code commune (les codes communes INSEE dans les DOM sont à deux chiffres et non trois, après le code département). Noter aussi que des communes ont pu fusionner tout en conservant leur code commune historique dans les rues. La fusion des codes communes n'a pas lieu non plus dans les communes qui ne sont pas réellement en fusion simple, les codes INSEE des communes ne sont donc pas supprimés, la commune nouvelle utilisant alors autant de codes que de communes membres, et cela peut persister longtemps (on a aussi des cas de défusion de communes) parce qu'on ne peut pas simplement remplacer ce code commune par un autre sans renuméroter tout le reste. C'est le cas par exemple dans les bases du cadastre pour référencer les planches.

L'idée qu'une commune n'a qu'un seul code INSEE est fausse: même s'il y a un code "principal" il y a encore des codes secondaires correspondant au découpage historique et il faut des années pour que cela change, les communes n'ayant pas envie ni le temps de corriger tous les fichiers et faire que cela fonctionne avec toutes les administrations, la chose qui compte n"tant pas le code commune seul mais l'identifiant complet de l'objet (ici un code FANTOIR ou une planche cadastrale) dont le code commune n'est qu'un composant non réellement séparable (on a même des cas de communes ayant conservé des codes communes d'un ancien département quand une fusion a eu lieu avec une commune d'un département voisin, les départements ayant alors changé de délimitation, avec un exemple assez récent entre Maine-et-Loire et Loire-Atlantique si je me souviens bien).


Le mer. 11 déc. 2019 à 21:53, deuzeffe <[hidden email]> a écrit :
Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> Bonjour,
>
> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> https://overpass-turbo.eu/s/OSX

D'après la description du fichier FANTOIR
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
semble avoir été ràz, donc ignoré dans la version finale ?

Si quelqu'un y voit plus clair que moi...

--
deuzeffe - pas le neurone en face de la synapse

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Vincent de Château-Thierry-2
In reply to this post by deuzeffe
Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :

> Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
>> Bonjour,
>>
>> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
>> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
>> https://overpass-turbo.eu/s/OSX
>
> D'après la description du fichier FANTOIR
> (https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
> ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
> semble avoir été ràz, donc ignoré dans la version finale ?
>
> Si quelqu'un y voit plus clair que moi...

Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
choisi de ne pas considérer ce code direction pour composer ce qu'on
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
appliquée depuis, et assez pratique puisqu'elle permet très simplement
un lien avec la commune, vu que les 5 1ères positions du code
correspondent au code INSEE communal. Je ne sais pas quel avantage /
quelle interopérabilité nous apporterait l'inclusion du code direction
en 3è position, je sais en revanche qu'il nous casserait bien les pieds
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
et sa commune d'appartenance. On passerait notre temps à détricoter le
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...

vincent


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

verdy_p
Mais est-ce que ça marche pour Paris (un seul code commune comme 75000 ou plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de doublon indésirables? Le dédoublonnage (renumérotation éventuelle) a-t-il déjà eu lieu dans les anciennes directions pour avoir des codes FANTOIR uniques par code commune (y compris les "communes nouvelles" ou récemment fusionnées en fusion simple) ?

Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry <[hidden email]> a écrit :
Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :
> Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
>> Bonjour,
>>
>> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
>> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
>> https://overpass-turbo.eu/s/OSX
>
> D'après la description du fichier FANTOIR
> (https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
> ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
> semble avoir été ràz, donc ignoré dans la version finale ?
>
> Si quelqu'un y voit plus clair que moi...

Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
choisi de ne pas considérer ce code direction pour composer ce qu'on
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
appliquée depuis, et assez pratique puisqu'elle permet très simplement
un lien avec la commune, vu que les 5 1ères positions du code
correspondent au code INSEE communal. Je ne sais pas quel avantage /
quelle interopérabilité nous apporterait l'inclusion du code direction
en 3è position, je sais en revanche qu'il nous casserait bien les pieds
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
et sa commune d'appartenance. On passerait notre temps à détricoter le
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...

vincent


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

deuzeffe
Le Code Officiel Géographique est ton ami.

HTH

Le 12/12/2019 à 22:19, Philippe Verdy a écrit :

> Mais est-ce que ça marche pour Paris (un seul code commune comme 75000
> ou plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de
> doublon indésirables? Le dédoublonnage (renumérotation éventuelle)
> a-t-il déjà eu lieu dans les anciennes directions pour avoir des codes
> FANTOIR uniques par code commune (y compris les "communes nouvelles" ou
> récemment fusionnées en fusion simple) ?
>
> Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry
> <[hidden email] <mailto:[hidden email]>> a écrit :
>
>     Bonsoir,
>
>     Le 11/12/2019 à 21:53, deuzeffe a écrit :
>      > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
>      >> Bonjour,
>      >>
>      >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
>      >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>      >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
>      >> https://overpass-turbo.eu/s/OSX
>      >
>      > D'après la description du fichier FANTOIR
>      >
>     (https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
>
>      > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième
>     "champ")
>      > semble avoir été ràz, donc ignoré dans la version finale ?
>      >
>      > Si quelqu'un y voit plus clair que moi...
>
>     Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
>     choisi de ne pas considérer ce code direction pour composer ce qu'on
>     appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
>     appliquée depuis, et assez pratique puisqu'elle permet très simplement
>     un lien avec la commune, vu que les 5 1ères positions du code
>     correspondent au code INSEE communal. Je ne sais pas quel avantage /
>     quelle interopérabilité nous apporterait l'inclusion du code direction
>     en 3è position, je sais en revanche qu'il nous casserait bien les pieds
>     à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
>     et sa commune d'appartenance. On passerait notre temps à détricoter le
>     ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...
>
>     vincent
>
>
>     _______________________________________________
>     Talk-fr mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

deuzeffe
In reply to this post by Vincent de Château-Thierry-2
Le 12/12/2019 à 22:12, Vincent de Château-Thierry a écrit :
> Bonsoir,

Pareil,

>> D'après la description du fichier FANTOIR
>> (https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
>> ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième
>> "champ") semble avoir été ràz, donc ignoré dans la version finale ?
>>
>> Si quelqu'un y voit plus clair que moi...
>
> Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
> choisi de ne pas considérer ce code direction pour composer ce qu'on
> appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
> appliquée depuis, et assez pratique puisqu'elle permet très simplement
> un lien avec la commune, vu que les 5 1ères positions du code
> correspondent au code INSEE communal. Je ne sais pas quel avantage /
> quelle interopérabilité nous apporterait l'inclusion du code direction
> en 3è position, je sais en revanche qu'il nous casserait bien les pieds
> à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
> et sa commune d'appartenance. On passerait notre temps à détricoter le
> ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...

Ah bin voilà, c'est parfait comme ça. Merci beaucoup !

Merci aussi pour l'icône "Télécharger en csv" ;)

--
deuzeffe - me coucherai moins ignorante.



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

verdy_p
In reply to this post by deuzeffe
Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes ne sont pas si uniques que ça (il y a tout un historique lié aux fusions/défusions, et réaménagement de frontières communales ou réaffectations de voies limitrophes) ! Le définition des tues est une compétence communale, mais comme les communes changent aussi, ce n'est pas en passant à l'échelle départementale avec le COG actuel qu'on résoud les ambiguités.
D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une simplification, un instantané valable à une année donnée et si on n'indique pas le millésime, il n'indique pas de commune précise (contrairement au code SIRET de la commune, qui change à chaque réaménagement légal, avec des limites toutefois en cas d'échanges parcellaires d'une commune à l'autre sans changer les entités légales).
Ensuite pour la fiscalité locale applicable et le cadastre ça devient vite compliqu (y compris avec des communes qui ont changé de département à l'occasion d'une fusion en commune nouvelle, les communes déléguées conservant encore le code de leur ancien département dont elle ne font plus partie!)
Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de classification, où la commune n'est qu'un indicateur à une date donnée (non précisée par le code lui-même).
De plus ce n'erst pas parce qu'une comune a cessé d'être de plein exercice que son code disparit tout de suite, étant donné que l'INSEE doit conserver les rapprochements statistiques d'une année sur l'autre au moins pendant une période assez longue pour les usages réglementaires et les recours légaux possibles : les codes historiques persistent longtemps dans les fichiers et conservent leur validité, même si ce ne sont plus les codes premiers pour les données concernant les nouveaux exercices: ils restent donc réservés et normalement pas réaffectables avant très longtemps.
Le COG lui-même doit donc être millésimé en tant que référence, il n'est pas unique.

Le jeu. 12 déc. 2019 à 22:25, deuzeffe <[hidden email]> a écrit :
Le Code Officiel Géographique est ton ami.

HTH


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

deuzeffe
Ne me fais pas croire que tu ne sais pas trouver les pages qui décrivent
très précisément le COG et tous les champs. C'est sûr que c'est moins
facile de trouver le dernier COG du printemps-été 2019 avec toutes la
liste de toutes les communes et leur identifiant unique que de peigner
la girafe, mais quand même.

Bref.

Le 12/12/2019 à 22:49, Philippe Verdy a écrit :

> Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes
> ne sont pas si uniques que ça (il y a tout un historique lié aux
> fusions/défusions, et réaménagement de frontières communales ou
> réaffectations de voies limitrophes) ! Le définition des tues est une
> compétence communale, mais comme les communes changent aussi, ce n'est
> pas en passant à l'échelle départementale avec le COG actuel qu'on
> résoud les ambiguités.
> D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
> simplification, un instantané valable à une année donnée et si on
> n'indique pas le millésime, il n'indique pas de commune précise
> (contrairement au code SIRET de la commune, qui change à chaque
> réaménagement légal, avec des limites toutefois en cas d'échanges
> parcellaires d'une commune à l'autre sans changer les entités légales).
> Ensuite pour la fiscalité locale applicable et le cadastre ça devient
> vite compliqu (y compris avec des communes qui ont changé de département
> à l'occasion d'une fusion en commune nouvelle, les communes déléguées
> conservant encore le code de leur ancien département dont elle ne font
> plus partie!)
> Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
> classification, où la commune n'est qu'un indicateur à une date donnée
> (non précisée par le code lui-même).
> De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
> exercice que son code disparit tout de suite, étant donné que l'INSEE
> doit conserver les rapprochements statistiques d'une année sur l'autre
> au moins pendant une période assez longue pour les usages réglementaires
> et les recours légaux possibles : les codes historiques persistent
> longtemps dans les fichiers et conservent leur validité, même si ce ne
> sont plus les codes premiers pour les données concernant les nouveaux
> exercices: ils restent donc réservés et normalement pas réaffectables
> avant très longtemps.
> Le COG lui-même doit donc être millésimé en tant que référence, il n'est
> pas unique.
>
> Le jeu. 12 déc. 2019 à 22:25, deuzeffe <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Le Code Officiel Géographique est ton ami.
>
>     HTH
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Jérôme Amagat
Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en région parisienne, il y en a aussi à Dunkerque et autour avec le code direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de code direction 0 et aussi des fautes de frappe. Mais il y en reste encore. Si ça tente des gens de continuer les corrections, on trouve les codes de 11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères : https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent), on pourrait ajouter le code insee de la commune avant le code déjà présent mais on aurait que les 9 1er caractères et il manquerait le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses car il y a après le code : "-le numéro" donc pour faire ça comme il faut il faudrait avec ces numéros créer les relations associateStreet pour y placer le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

verdy_p
In reply to this post by deuzeffe
Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en 2019.
Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a pas de synchro directe entre les deux, toujours des décalages)!


Je sais faire la différence merci.

Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le département métropole+direction ou pour les DOM; puis 3 pour la commune même dans les DOM, mais pas synchronisé immédiatement et partour avec le COG du même millésime), après le code RIVOLI du type de voie (1 lettre), et avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus code commune à 6 chiffres); le dernier caractère est une lettre-clé calculée sur les 11 caractères précédents (code RIVOLI du type de voie, département+direction+commune, numéro de voie)

Bref les codes commune complets du COG et ceux du FANTOIR sont différents en forme et en usage même si à l'origine le FANTOIR a basé ses codes commune sur le code INSEE des commune issu du COG. Le COG n'a aucun "code direction" et réduit les codes communes de 3 à 2 chiffres dans les DOM en ajoutant un chiffre au département.

On peut se passer de la lettre clé finale (après la lettre RIVOLI et les 6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste une vérification).

Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la lettre clé finale n'est plus correcte, mais quoi qu'il en soit elle n'est toujours pas identifiante mais permet de déduire le chiffre manquant dans le code commune complet à 6 chiffres).

Des corrections semi-automatiques sont possibles selon la forme trouvée:
- 4 chiffres plus 1 lettre : il manque la commune (requête géographique semi-automatique); la lettre clé finale est présente, on peut en déduire le code RIVOLI initial du type de voie grace à la lettre-clé finale après avoir déduit la commune, mais problème dans les départements ayant plusieurs directions, car alors on aura plusieurs codes RIVOLI de type de voie déduits et on ne peut pas choisir (correction donc manuelle, le code direction n'est pas forcément 0 à Paris, dans le Nord, dans le Rhône ou les Bouches-du-Rhône, mais les directions sont des secteurs géographiques dans un département, on s'en sort donc).
- 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI initiale pour le rendre unique, cas d'erreur.
- 1 lettre plus 4 chiffres : il manque les 6 chiffres du code département+direction+commune FANTOIR, puis la lettre-clé calculable. On peut cherche la commune par requête géographique (à confirmer, attention aux pièges des communes fusionnées, il peut y avoir encore plusieurs codes possibles car pas de synchro immédiate du FANTOIR avec le COG).
- 1 lettre plus 10 chiffres : il manque juste la lettre clé finale calculable automatiquement.


Le jeu. 12 déc. 2019 à 22:56, deuzeffe <[hidden email]> a écrit :
Ne me fais pas croire que tu ne sais pas trouver les pages qui décrivent
très précisément le COG et tous les champs. C'est sûr que c'est moins
facile de trouver le dernier COG du printemps-été 2019 avec toutes la
liste de toutes les communes et leur identifiant unique que de peigner
la girafe, mais quand même.

Bref.

Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
> Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes
> ne sont pas si uniques que ça (il y a tout un historique lié aux
> fusions/défusions, et réaménagement de frontières communales ou
> réaffectations de voies limitrophes) ! Le définition des tues est une
> compétence communale, mais comme les communes changent aussi, ce n'est
> pas en passant à l'échelle départementale avec le COG actuel qu'on
> résoud les ambiguités.
> D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
> simplification, un instantané valable à une année donnée et si on
> n'indique pas le millésime, il n'indique pas de commune précise
> (contrairement au code SIRET de la commune, qui change à chaque
> réaménagement légal, avec des limites toutefois en cas d'échanges
> parcellaires d'une commune à l'autre sans changer les entités légales).
> Ensuite pour la fiscalité locale applicable et le cadastre ça devient
> vite compliqu (y compris avec des communes qui ont changé de département
> à l'occasion d'une fusion en commune nouvelle, les communes déléguées
> conservant encore le code de leur ancien département dont elle ne font
> plus partie!)
> Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
> classification, où la commune n'est qu'un indicateur à une date donnée
> (non précisée par le code lui-même).
> De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
> exercice que son code disparit tout de suite, étant donné que l'INSEE
> doit conserver les rapprochements statistiques d'une année sur l'autre
> au moins pendant une période assez longue pour les usages réglementaires
> et les recours légaux possibles : les codes historiques persistent
> longtemps dans les fichiers et conservent leur validité, même si ce ne
> sont plus les codes premiers pour les données concernant les nouveaux
> exercices: ils restent donc réservés et normalement pas réaffectables
> avant très longtemps.
> Le COG lui-même doit donc être millésimé en tant que référence, il n'est
> pas unique.
>
> Le jeu. 12 déc. 2019 à 22:25, deuzeffe <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Le Code Officiel Géographique est ton ami.
>
>     HTH
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Bibi
In reply to this post by Jérôme Amagat

https://overpass-turbo.eu/s/OWF

Là tu ne devrais avoir que des incorrects.

Visiblement des Nantais ont lu ton message !

Jean-Yvon

Le 13/12/2019 à 02:07, Jérôme Amagat - [hidden email] a écrit :
Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en région parisienne, il y en a aussi à Dunkerque et autour avec le code direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de code direction 0 et aussi des fautes de frappe. Mais il y en reste encore. Si ça tente des gens de continuer les corrections, on trouve les codes de 11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères : https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent), on pourrait ajouter le code insee de la commune avant le code déjà présent mais on aurait que les 9 1er caractères et il manquerait le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses car il y a après le code : "-le numéro" donc pour faire ça comme il faut il faudrait avec ces numéros créer les relations associateStreet pour y placer le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Donat ROBAUX
Avant de voir ce message, j'ai déposé une petite issue sur Github:
https://github.com/osm-fr/osm-vs-fantoir/issues/71

A commenter, amender si le sujet vous parle.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Xavier BIZOT
In reply to this post by Bibi
Bonjour,

Le peu d'erreurs sur la Bretagne ont été corrigé de mon côté :)

Xavier

Le ven. 13 déc. 2019 à 11:09, <[hidden email]> a écrit :

https://overpass-turbo.eu/s/OWF

Là tu ne devrais avoir que des incorrects.

Visiblement des Nantais ont lu ton message !

Jean-Yvon

Le 13/12/2019 à 02:07, Jérôme Amagat - [hidden email] a écrit :
Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en région parisienne, il y en a aussi à Dunkerque et autour avec le code direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de code direction 0 et aussi des fautes de frappe. Mais il y en reste encore. Si ça tente des gens de continuer les corrections, on trouve les codes de 11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères : https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent), on pourrait ajouter le code insee de la commune avant le code déjà présent mais on aurait que les 9 1er caractères et il manquerait le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses car il y a après le code : "-le numéro" donc pour faire ça comme il faut il faudrait avec ces numéros créer les relations associateStreet pour y placer le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

deuzeffe
In reply to this post by verdy_p
Je te parle des codes communes pour lesquels tu n'as donné aucune
référence fiable et validée. Ne détourne pas la conversation steuplé.

Le 13/12/2019 à 05:30, Philippe Verdy a écrit :

> Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en 2019.
> Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a
> pas de synchro directe entre les deux, toujours des décalages)!
>
> COG: source INSEE (https://www.insee.fr/fr/information/2016807)
> FANTOIR: source DGFIP
> (https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/)
>
> Je sais faire la différence merci.
>
> Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le
> département métropole+direction ou pour les DOM; puis 3 pour la commune
> même dans les DOM, mais pas synchronisé immédiatement et partour avec le
> COG du même millésime), après le code RIVOLI du type de voie (1 lettre),
> et avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus
> code commune à 6 chiffres); le dernier caractère est une lettre-clé
> calculée sur les 11 caractères précédents (code RIVOLI du type de voie,
> département+direction+commune, numéro de voie)
>
> Bref les codes commune complets du COG et ceux du FANTOIR sont
> différents en forme et en usage même si à l'origine le FANTOIR a basé
> ses codes commune sur le code INSEE des commune issu du COG. Le COG n'a
> aucun "code direction" et réduit les codes communes de 3 à 2 chiffres
> dans les DOM en ajoutant un chiffre au département.
>
> On peut se passer de la lettre clé finale (après la lettre RIVOLI et les
> 6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste
> une vérification).
>
> Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la
> lettre clé finale n'est plus correcte, mais quoi qu'il en soit elle
> n'est toujours pas identifiante mais permet de déduire le chiffre
> manquant dans le code commune complet à 6 chiffres).
>
> Des corrections semi-automatiques sont possibles selon la forme trouvée:
> - 4 chiffres plus 1 lettre : il manque la commune (requête géographique
> semi-automatique); la lettre clé finale est présente, on peut en déduire
> le code RIVOLI initial du type de voie grace à la lettre-clé finale
> après avoir déduit la commune, mais problème dans les départements ayant
> plusieurs directions, car alors on aura plusieurs codes RIVOLI de type
> de voie déduits et on ne peut pas choisir (correction donc manuelle, le
> code direction n'est pas forcément 0 à Paris, dans le Nord, dans le
> Rhône ou les Bouches-du-Rhône, mais les directions sont des secteurs
> géographiques dans un département, on s'en sort donc).
> - 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI
> initiale pour le rendre unique, cas d'erreur.
> - 1 lettre plus 4 chiffres : il manque les 6 chiffres du code
> département+direction+commune FANTOIR, puis la lettre-clé calculable. On
> peut cherche la commune par requête géographique (à confirmer, attention
> aux pièges des communes fusionnées, il peut y avoir encore plusieurs
> codes possibles car pas de synchro immédiate du FANTOIR avec le COG).
> - 1 lettre plus 10 chiffres : il manque juste la lettre clé finale
> calculable automatiquement.
>
>
> Le jeu. 12 déc. 2019 à 22:56, deuzeffe <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Ne me fais pas croire que tu ne sais pas trouver les pages qui
>     décrivent
>     très précisément le COG et tous les champs. C'est sûr que c'est moins
>     facile de trouver le dernier COG du printemps-été 2019 avec toutes la
>     liste de toutes les communes et leur identifiant unique que de peigner
>     la girafe, mais quand même.
>
>     Bref.
>
>     Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
>      > Le COG ne répond pas à ça concernant le FANTOIR, et les codes
>     communes
>      > ne sont pas si uniques que ça (il y a tout un historique lié aux
>      > fusions/défusions, et réaménagement de frontières communales ou
>      > réaffectations de voies limitrophes) ! Le définition des tues est
>     une
>      > compétence communale, mais comme les communes changent aussi, ce
>     n'est
>      > pas en passant à l'échelle départementale avec le COG actuel qu'on
>      > résoud les ambiguités.
>      > D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
>      > simplification, un instantané valable à une année donnée et si on
>      > n'indique pas le millésime, il n'indique pas de commune précise
>      > (contrairement au code SIRET de la commune, qui change à chaque
>      > réaménagement légal, avec des limites toutefois en cas d'échanges
>      > parcellaires d'une commune à l'autre sans changer les entités
>     légales).
>      > Ensuite pour la fiscalité locale applicable et le cadastre ça
>     devient
>      > vite compliqu (y compris avec des communes qui ont changé de
>     département
>      > à l'occasion d'une fusion en commune nouvelle, les communes
>     déléguées
>      > conservant encore le code de leur ancien département dont elle ne
>     font
>      > plus partie!)
>      > Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
>      > classification, où la commune n'est qu'un indicateur à une date
>     donnée
>      > (non précisée par le code lui-même).
>      > De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
>      > exercice que son code disparit tout de suite, étant donné que
>     l'INSEE
>      > doit conserver les rapprochements statistiques d'une année sur
>     l'autre
>      > au moins pendant une période assez longue pour les usages
>     réglementaires
>      > et les recours légaux possibles : les codes historiques persistent
>      > longtemps dans les fichiers et conservent leur validité, même si
>     ce ne
>      > sont plus les codes premiers pour les données concernant les
>     nouveaux
>      > exercices: ils restent donc réservés et normalement pas
>     réaffectables
>      > avant très longtemps.
>      > Le COG lui-même doit donc être millésimé en tant que référence,
>     il n'est
>      > pas unique.
>      >
>      > Le jeu. 12 déc. 2019 à 22:25, deuzeffe <[hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email]
>     <mailto:[hidden email]>>> a écrit :
>      >
>      >     Le Code Officiel Géographique est ton ami.
>      >
>      >     HTH
>      >
>      >
>      > _______________________________________________
>      > Talk-fr mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.openstreetmap.org/listinfo/talk-fr
>      >
>
>     _______________________________________________
>     Talk-fr mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

verdy_p
La. N'est toi qui détourne la conversation, on parle bien du FANTOIR de la DGFIP, pas du COG de l'INSEE (cf le titre de ce fil)


Le ven. 13 déc. 2019 à 17:12, deuzeffe <[hidden email]> a écrit :
Je te parle des codes communes pour lesquels tu n'as donné aucune
référence fiable et validée. Ne détourne pas la conversation steuplé.

Le 13/12/2019 à 05:30, Philippe Verdy a écrit :
> Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en 2019.
> Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a
> pas de synchro directe entre les deux, toujours des décalages)!
>
> COG: source INSEE (https://www.insee.fr/fr/information/2016807)
> FANTOIR: source DGFIP
> (https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/)
>
> Je sais faire la différence merci.
>
> Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le
> département métropole+direction ou pour les DOM; puis 3 pour la commune
> même dans les DOM, mais pas synchronisé immédiatement et partour avec le
> COG du même millésime), après le code RIVOLI du type de voie (1 lettre),
> et avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus
> code commune à 6 chiffres); le dernier caractère est une lettre-clé
> calculée sur les 11 caractères précédents (code RIVOLI du type de voie,
> département+direction+commune, numéro de voie)
>
> Bref les codes commune complets du COG et ceux du FANTOIR sont
> différents en forme et en usage même si à l'origine le FANTOIR a basé
> ses codes commune sur le code INSEE des commune issu du COG. Le COG n'a
> aucun "code direction" et réduit les codes communes de 3 à 2 chiffres
> dans les DOM en ajoutant un chiffre au département.
>
> On peut se passer de la lettre clé finale (après la lettre RIVOLI et les
> 6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste
> une vérification).
>
> Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la
> lettre clé finale n'est plus correcte, mais quoi qu'il en soit elle
> n'est toujours pas identifiante mais permet de déduire le chiffre
> manquant dans le code commune complet à 6 chiffres).
>
> Des corrections semi-automatiques sont possibles selon la forme trouvée:
> - 4 chiffres plus 1 lettre : il manque la commune (requête géographique
> semi-automatique); la lettre clé finale est présente, on peut en déduire
> le code RIVOLI initial du type de voie grace à la lettre-clé finale
> après avoir déduit la commune, mais problème dans les départements ayant
> plusieurs directions, car alors on aura plusieurs codes RIVOLI de type
> de voie déduits et on ne peut pas choisir (correction donc manuelle, le
> code direction n'est pas forcément 0 à Paris, dans le Nord, dans le
> Rhône ou les Bouches-du-Rhône, mais les directions sont des secteurs
> géographiques dans un département, on s'en sort donc).
> - 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI
> initiale pour le rendre unique, cas d'erreur.
> - 1 lettre plus 4 chiffres : il manque les 6 chiffres du code
> département+direction+commune FANTOIR, puis la lettre-clé calculable. On
> peut cherche la commune par requête géographique (à confirmer, attention
> aux pièges des communes fusionnées, il peut y avoir encore plusieurs
> codes possibles car pas de synchro immédiate du FANTOIR avec le COG).
> - 1 lettre plus 10 chiffres : il manque juste la lettre clé finale
> calculable automatiquement.
>
>
> Le jeu. 12 déc. 2019 à 22:56, deuzeffe <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Ne me fais pas croire que tu ne sais pas trouver les pages qui
>     décrivent
>     très précisément le COG et tous les champs. C'est sûr que c'est moins
>     facile de trouver le dernier COG du printemps-été 2019 avec toutes la
>     liste de toutes les communes et leur identifiant unique que de peigner
>     la girafe, mais quand même.
>
>     Bref.
>
>     Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
>      > Le COG ne répond pas à ça concernant le FANTOIR, et les codes
>     communes
>      > ne sont pas si uniques que ça (il y a tout un historique lié aux
>      > fusions/défusions, et réaménagement de frontières communales ou
>      > réaffectations de voies limitrophes) ! Le définition des tues est
>     une
>      > compétence communale, mais comme les communes changent aussi, ce
>     n'est
>      > pas en passant à l'échelle départementale avec le COG actuel qu'on
>      > résoud les ambiguités.
>      > D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
>      > simplification, un instantané valable à une année donnée et si on
>      > n'indique pas le millésime, il n'indique pas de commune précise
>      > (contrairement au code SIRET de la commune, qui change à chaque
>      > réaménagement légal, avec des limites toutefois en cas d'échanges
>      > parcellaires d'une commune à l'autre sans changer les entités
>     légales).
>      > Ensuite pour la fiscalité locale applicable et le cadastre ça
>     devient
>      > vite compliqu (y compris avec des communes qui ont changé de
>     département
>      > à l'occasion d'une fusion en commune nouvelle, les communes
>     déléguées
>      > conservant encore le code de leur ancien département dont elle ne
>     font
>      > plus partie!)
>      > Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
>      > classification, où la commune n'est qu'un indicateur à une date
>     donnée
>      > (non précisée par le code lui-même).
>      > De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
>      > exercice que son code disparit tout de suite, étant donné que
>     l'INSEE
>      > doit conserver les rapprochements statistiques d'une année sur
>     l'autre
>      > au moins pendant une période assez longue pour les usages
>     réglementaires
>      > et les recours légaux possibles : les codes historiques persistent
>      > longtemps dans les fichiers et conservent leur validité, même si
>     ce ne
>      > sont plus les codes premiers pour les données concernant les
>     nouveaux
>      > exercices: ils restent donc réservés et normalement pas
>     réaffectables
>      > avant très longtemps.
>      > Le COG lui-même doit donc être millésimé en tant que référence,
>     il n'est
>      > pas unique.
>      >
>      > Le jeu. 12 déc. 2019 à 22:25, deuzeffe <[hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email]
>     <mailto:[hidden email]>>> a écrit :
>      >
>      >     Le Code Officiel Géographique est ton ami.
>      >
>      >     HTH
>      >
>      >
>      > _______________________________________________
>      > Talk-fr mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.openstreetmap.org/listinfo/talk-fr
>      >
>
>     _______________________________________________
>     Talk-fr mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: ref:FR:FANTOIR

Bibi
In reply to this post by Xavier BIZOT

Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à 11 chiffres (ou 11, un point-virgule et 11).

Vous ne m'en avez même pas laissé un.

Merci à Jérôme pour avoir débusqué les lièvres et à tous les chasseurs. Ne pas détourner cette phrase de son contexte^^.

Jean-Yvon

Le 13/12/2019 à 14:07, Xavier BIZOT - [hidden email] a écrit :
Bonjour,

Le peu d'erreurs sur la Bretagne ont été corrigé de mon côté :)

Xavier

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
123