Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-04-27 Par sujet deuzeffe 

On 27/04/2019 19:24, marc marc wrote:

Le 27.04.19 à 16:59, Jérôme Amagat a écrit :

il faut supprimer les ref:INSEE sur les node est les garder que sur
relation ce qui serait plus logique vu que c'est un code pour la commune
est pas pour la ville ou village représenté par ce node


c'est sans doute par là qu'il faudrait commencer : virer toutes les
codes communes qui sont sur les ville/villages


Pour l'instant, j'ai mis un was: devant les ref:INSEE (c'est le même pb 
pour les anciennes régions, d'ailleurs) uniquement sur les nodes. Pas 
touché aux relations (et ni prête à ni près de le faire ^^)


--
deuzeffe

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-04-27 Par sujet marc marc 
Le 27.04.19 à 16:59, Jérôme Amagat a écrit :
> il faut supprimer les ref:INSEE sur les node est les garder que sur 
> relation ce qui serait plus logique vu que c'est un code pour la commune 
> est pas pour la ville ou village représenté par ce node  

c'est sans doute par là qu'il faudrait commencer : virer toutes les 
codes communes qui sont sur les ville/villages

> mais je crois que cette suppression ne plaît pas à tout le monde.

ha ? Christian tu les utilises ? :-D
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-04-27 Par sujet Jérôme Amagat 
Le sam. 27 avr. 2019 à 13:51, deuzeffe  a écrit :

> Hello,
>
> Osmose remonte ces erreurs :
>
> https://osmose.openstreetmap.fr/fr/map/#country=france_limousin_haute_vienne=6040=1%2C2%2C3=9=45.859=1.345==
>
> (N° INSEE introuvable, nom OSM <> nom COG aka nom de commune <> code INSEE)
>
> Faut faire quoi ? Comment on répare ce genre de truc sans dénaturer la
> réalité du terrain ?
>

Je ne pense pas que ce test osmose soit utile et donc qu'il ne faut rien
toucher.
Déjà au minimum il ne faut pas tester les node mais seulement les
relations. Sur les node osmose s’attend à avoir le nom de la commune
correspondant au code insee alors que de plus en plus avec les communes
nouvelle on a des chefs lieu de communes avec un nom différent de la
commune.
Ou alors il faut supprimer les ref:INSEE sur les node est les garder que
sur relation ce qui serait plus logique vu que c'est un code pour la
commune est pas pour la ville ou village représenté par ce node mais je
crois que cette suppression ne plaît pas à tout le monde.
pour le problème quand le numéro INSEE est introuvable, c'est pratiquement
à chaque fois, que la commune à fusionner avec d'autre donc il y a moins de
commune donc moins de code insee. Mais il a été dit qu'il faut garder dans
osm ces anciens code insee car ils sont utiles. Peut être qu'il faudrait se
mettre d'accord pour changer les codes plus utilisés par l'insee dans un
nouveau tag disused:ref:INSEE=* ou quelque chose du genre.

Mais en l'état, tant que aucune décision de changement n'est prise, il ne
faut rien changer.
(sauf si le code n'a jamais existé, faute de frappe, erreur de copie...
mais ces problème doivent être très rare dans la liste d'erreur donnée par
osmose)



>
> Merci de votre aide.
> --
> deuzeffe
>
> On 29/12/2018 19:00, Christian Quest wrote:
> > Tout est maintenant traité... la chasse aux erreurs est ouverte !
> >
> > Le sam. 29 déc. 2018 à 17:19, Christian Quest  > > a écrit :
> >
> > Je pense que official_name est là pour ces noms administratifs non
> > respectueux des règles de toponymie... et name pour la version
> > "propre" Bresse-Vallons, Porte-des-Pierres-Dorées, etc...
> >
> > Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le
> > fignolage final ;)
> >
> > Les département 01 à 50 sont traités... et maintenant à vérifier !
> > Je fais une vérif manuelle avant upload, mais je peux laisser passer
> > des pépins vu la quantité même si je fais ça un département à la
> fois.
> >
> >
> > Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin
> > mailto:gwenael.jou...@laposte.net>> a
> > écrit :
> >
> > Merci pour ce boulot.
> >
> > Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma
> > zone :-)
> >
> >
> > Par contre je constate avec agacement que les règles d’écriture
> > des toponymes n’est toujours pas correctement appliquée ni par
> > les conseillers municipaux, ni par les préfets…
> > Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).
> >
> > C’est pourtant pas faute de leur rappeler :
> >
> http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf
> >
> >
> > Doit-on, par cohérence avec les documents réglementaires,
> > restituer ces fautes dans OSM ?
> >
> >
> >
> > Le 29/12/2018 à 14:52, Christian Quest a écrit :
> >  > Comme chaque fin d'année, c'est le chantier des fusions qui
> > s'ouvre ;)
> >  >
> >  > 608 communes fusionnent en 232 communes nouvelles d'après
> > wikipédia:
> >  >
> >  >
> >
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> >  >
> >  > J'ai donc ressorti mes scripts de mise à jour, car faire tout
> > ça à la main sans erreur c'est assez chaud !
> >  >
> >  > Première étape, récupérer les données du tableau wikipédia:
> > c'est fait, j'ai un json prêt à consommer.
> >  >
> >  > Deuxième étape: appliquer les modifications... je suis en
> > train de tester.
> >  >
> >  > C'est complexe car certaines communes nouvelles ont déjà été
> > créées, et il ne faut pas se mélanger avec le cas de communes
> > nouvelles créées ces dernières années qui absorbent encore
> > quelques communes.
> >  >
> >  > Troisième étape: vérification... là un peu d'humain sera bien
> > utile, donc si ça vous intéresse, ce fil de discussion est là
> > pour ça !
> >  >
> >  > Je compte appliquer les modifications aujourd'hui et demain
> > pour laisser le 31 et le 1er pour faire les vérifications et
> > corrections.
> >  >
> >  > --
> >  > Christian Quest - OpenStreetMap France
> >  >
> >  > ___
> >  > Talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-04-27 Par sujet deuzeffe 

Hello,

Osmose remonte ces erreurs : 
https://osmose.openstreetmap.fr/fr/map/#country=france_limousin_haute_vienne=6040=1%2C2%2C3=9=45.859=1.345==


(N° INSEE introuvable, nom OSM <> nom COG aka nom de commune <> code INSEE)

Faut faire quoi ? Comment on répare ce genre de truc sans dénaturer la 
réalité du terrain ?


Merci de votre aide.
--
deuzeffe

On 29/12/2018 19:00, Christian Quest wrote:

Tout est maintenant traité... la chasse aux erreurs est ouverte !

Le sam. 29 déc. 2018 à 17:19, Christian Quest > a écrit :


Je pense que official_name est là pour ces noms administratifs non
respectueux des règles de toponymie... et name pour la version
"propre" Bresse-Vallons, Porte-des-Pierres-Dorées, etc...

Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le
fignolage final ;)

Les département 01 à 50 sont traités... et maintenant à vérifier !
Je fais une vérif manuelle avant upload, mais je peux laisser passer
des pépins vu la quantité même si je fais ça un département à la fois.


Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin
mailto:gwenael.jou...@laposte.net>> a
écrit :

Merci pour ce boulot.

Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma
zone :-)


Par contre je constate avec agacement que les règles d’écriture
des toponymes n’est toujours pas correctement appliquée ni par
les conseillers municipaux, ni par les préfets…
Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).

C’est pourtant pas faute de leur rappeler :

http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf


Doit-on, par cohérence avec les documents réglementaires,
restituer ces fautes dans OSM ?



Le 29/12/2018 à 14:52, Christian Quest a écrit :
 > Comme chaque fin d'année, c'est le chantier des fusions qui
s'ouvre ;)
 >
 > 608 communes fusionnent en 232 communes nouvelles d'après
wikipédia:
 >
 >

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
 >
 > J'ai donc ressorti mes scripts de mise à jour, car faire tout
ça à la main sans erreur c'est assez chaud !
 >
 > Première étape, récupérer les données du tableau wikipédia:
c'est fait, j'ai un json prêt à consommer.
 >
 > Deuxième étape: appliquer les modifications... je suis en
train de tester.
 >
 > C'est complexe car certaines communes nouvelles ont déjà été
créées, et il ne faut pas se mélanger avec le cas de communes
nouvelles créées ces dernières années qui absorbent encore
quelques communes.
 >
 > Troisième étape: vérification... là un peu d'humain sera bien
utile, donc si ça vous intéresse, ce fil de discussion est là
pour ça !
 >
 > Je compte appliquer les modifications aujourd'hui et demain
pour laisser le 31 et le 1er pour faire les vérifications et
corrections.
 >
 > --
 > Christian Quest - OpenStreetMap France
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org 
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France




--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-21 Par sujet Phyks 
Ok ! Merci pour la confirmation,
-- 
Phyks
Le 20/01/2019 à 20:08, osm.sanspourr...@spamgourmet.com a écrit :
> Oui on a déjà eu ça l'an dernier : tant que l'INSEE n'a pas fourni les
> nouveaux codes (par exemple en disant très probablement que le nouveau
> code de Vindry-sur-Turdine c'est l'ancien code de Poncharra-sur-Turdine,
> Osmose vérifie avec les anciens codes alors que Christian a anticipé les
> décisions de l'INSEE.
> 
> C'est bien un faux positif.
> 
> Jean-Yvon
> 
> Le 20/01/2019 à 17:48, Phyks - ph...@phyks.me a écrit :
>> Bonjour à tous,
>>
>> J'ai vu une erreur Osmose sur
>> https://www.openstreetmap.org/relation/9135480, disant que le code
>> commune ne correspond pas au nom de la commune. Cette commune a été
>> affectée par une fusion au 1er janvier.
>>
>> En creusant un peu, le code commune 69157 était utilisé par
>> Poncharra-sur-Turdine et semble bien avoir été attribué à la commune
>> nouvelle Vindry-sur-Turdine. En tout cas, c'est l'info que je trouve sur
>> Wikipedia et dans https://www.insee.fr/fr/information/2549968.
>>
>> J'ai marqué en faux positif sur Osmose pour l'instant, mais je ne sais
>> pas si cette erreur est normale / attendue ? D'autres cas similaires
>> existent peut être (réattribution d'un code commune précédent à une
>> nouvelle commune).
>>
>> Bonne journée,
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-20 Par sujet osm . sanspourriel 
Oui on a déjà eu ça l'an dernier : tant que l'INSEE n'a pas fourni les 
nouveaux codes (par exemple en disant très probablement que le nouveau 
code de Vindry-sur-Turdine c'est l'ancien code de Poncharra-sur-Turdine, 
Osmose vérifie avec les anciens codes alors que Christian a anticipé les 
décisions de l'INSEE.


C'est bien un faux positif.

Jean-Yvon

Le 20/01/2019 à 17:48, Phyks - ph...@phyks.me a écrit :

Bonjour à tous,

J'ai vu une erreur Osmose sur
https://www.openstreetmap.org/relation/9135480, disant que le code
commune ne correspond pas au nom de la commune. Cette commune a été
affectée par une fusion au 1er janvier.

En creusant un peu, le code commune 69157 était utilisé par
Poncharra-sur-Turdine et semble bien avoir été attribué à la commune
nouvelle Vindry-sur-Turdine. En tout cas, c'est l'info que je trouve sur
Wikipedia et dans https://www.insee.fr/fr/information/2549968.

J'ai marqué en faux positif sur Osmose pour l'instant, mais je ne sais
pas si cette erreur est normale / attendue ? D'autres cas similaires
existent peut être (réattribution d'un code commune précédent à une
nouvelle commune).

Bonne journée,
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-20 Par sujet Phyks 
Bonjour à tous,

J'ai vu une erreur Osmose sur
https://www.openstreetmap.org/relation/9135480, disant que le code
commune ne correspond pas au nom de la commune. Cette commune a été
affectée par une fusion au 1er janvier.

En creusant un peu, le code commune 69157 était utilisé par
Poncharra-sur-Turdine et semble bien avoir été attribué à la commune
nouvelle Vindry-sur-Turdine. En tout cas, c'est l'info que je trouve sur
Wikipedia et dans https://www.insee.fr/fr/information/2549968.

J'ai marqué en faux positif sur Osmose pour l'instant, mais je ne sais
pas si cette erreur est normale / attendue ? D'autres cas similaires
existent peut être (réattribution d'un code commune précédent à une
nouvelle commune).

Bonne journée,
-- 
Phyks

Le 13/01/2019 à 08:12, Christian Quest a écrit :
> L'INSEE va publier une liste en principe la semaine prochaine... je referai
> une passe en me basant dessus.
> 
> Le dim. 13 janv. 2019 à 01:49, Jérôme Amagat  a
> écrit :
> 
>> Plusieurs ajouts sur Wikipédia depuis le 1er janvier :
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> il y a des cas bizarres :( :
>> Beyrede-Jumet-Camous sans accent sur Beyrede dans l’arrêté préfectoral
>> alors qu'il y en avait sur l'ancienne commune de Beyrède-Jumet.
>> Fresnay-sur-Sarthe : composé de 3 communes qui ne se touchent pas toutes
>> alors qu'il me semble que c'est obligatoire. Il semble n'y avoir que
>> quelques mètres entre les anciennes communes de Fresnay-sur-Sarthe
>> et Saint-Germain-sur-Sarthe mais elle ne sont pas contiguës.
>> https://www.openstreetmap.org/relation/107624 et
>> https://www.openstreetmap.org/relation/107591.
>> Cette commune nouvelle de Fresnay-sur-Sarthe n'existe pas encore dans osm
>> contrairement aux autres.
>>
>>
>> Le lun. 31 déc. 2018 à 19:53, Christian Quest  a
>> écrit :
>>
>>> Il y a encore de très nombreux usages des limites de communes
>>> correspondant à quelques années en arrière et c'est donc utile de les
>>> conserver quelques années.
>>>
>>> Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
>>> appellations qui dureront bien plus longtemps car ces communes nouvelles
>>> sont souvent une création vécue comme artificielle par les habitants.
>>>
>>> En choisissant des tags non ambigus, on évite les erreurs pouvant laisser
>>> penser qu'une emprise "passée" est actuelle.
>>> Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent
>>> de ces infos, et rien de spécial à faire pour les contributeurs... ces
>>> infos étant très stables dans le temps, ce n'est pas là dessus qu'on
>>> contribue beaucoup ;)
>>>
>>>
>>> Le lun. 31 déc. 2018 à 19:07, JB  a écrit :
>>>
 Question bête d'un gars dont ce n'est pas le métier :
 Est-ce que c'est vraiment à conserver dans OSM ?
 Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
 anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
 quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
 pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
 est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
 ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
 chercher les éléments dans une autre base de données, quitte à ajouter
 l'information spatiale à partir d'éléments simples d'OSM ?
 Dubitatif, et toujours adepte de garder de l'information simple. Pour la
 comprendre quand on contribue. Moi, et surtout les nouveaux contributeurs
 potentiels, qui ne connaissent rien au sujet.
 JB.

 Le 31/12/2018 à 18:18, Christian Quest a écrit :

 Oui, il va falloir suivre les publications de dernière minute... quel
 bazar !
 Je suis presque chaud pour rajouter un 4ème épisode à ma série
 "Millésimons"*

 Bien vue la requête overpass, heureusement que mon script amis à jour
 les admin_level sur les anciennes frontières internes des communes
 nouvelles ;)

 Pour les EPCI, il va falloir attendre que la DGCL publie une liste à
 jour (base BANATIC).

 Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
 principe mis à jour admin_type:FR=ancienne commune nouvelle

 Effectivement si on veut que la somme des admin_level=9 correspondent à
 l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
 petits morceaux du puzzle...

 On peut toujours les retrouver avec le disused:admin_level=8

 C'est à bien documenter une fois qu'on aura trouvé un consensus ;)


 * https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf

 Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat  a
 écrit :

> Bien jouer Christian!
>
> Il va falloir continuer à suivre la page Wikipédia
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> au cas ou il y ai des

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-16 Par sujet Jérôme Amagat 
L'INSEE a publié la liste des communes nouvelles créées en 2018 et donc ok
pour le 1er janvier 2019 : https://www.insee.fr/fr/information/2549968

Donc il me semble qu'il en manquait une sur la page Wikipédia.
Beyrède a un accent dans cette liste :)
Et il y a bien fusion entre des communes sans frontières communes... En
fait non :) les communes sont contiguës depuis peu.
Dans un arrêté préfectoral du 25 septembre  une commune cède 35 m² et 13 m²
d'un chemin communales aux 2 communes qui fusionnent pour que la fusion
puisse avoir lieu :)
(pour les curieux, ici page 25 :
http://www.sarthe.gouv.fr/IMG/pdf/recueil_mensuel_no67_-_septembre_2018.pdf
)


Le dim. 13 janv. 2019 à 08:13, Christian Quest  a
écrit :

> L'INSEE va publier une liste en principe la semaine prochaine... je
> referai une passe en me basant dessus.
>
> Le dim. 13 janv. 2019 à 01:49, Jérôme Amagat  a
> écrit :
>
>> Plusieurs ajouts sur Wikipédia depuis le 1er janvier :
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> il y a des cas bizarres :( :
>> Beyrede-Jumet-Camous sans accent sur Beyrede dans l’arrêté préfectoral
>> alors qu'il y en avait sur l'ancienne commune de Beyrède-Jumet.
>> Fresnay-sur-Sarthe : composé de 3 communes qui ne se touchent pas toutes
>> alors qu'il me semble que c'est obligatoire. Il semble n'y avoir que
>> quelques mètres entre les anciennes communes de Fresnay-sur-Sarthe
>> et Saint-Germain-sur-Sarthe mais elle ne sont pas contiguës.
>> https://www.openstreetmap.org/relation/107624 et
>> https://www.openstreetmap.org/relation/107591.
>> Cette commune nouvelle de Fresnay-sur-Sarthe n'existe pas encore dans osm
>> contrairement aux autres.
>>
>>
>> Le lun. 31 déc. 2018 à 19:53, Christian Quest 
>> a écrit :
>>
>>> Il y a encore de très nombreux usages des limites de communes
>>> correspondant à quelques années en arrière et c'est donc utile de les
>>> conserver quelques années.
>>>
>>> Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
>>> appellations qui dureront bien plus longtemps car ces communes nouvelles
>>> sont souvent une création vécue comme artificielle par les habitants.
>>>
>>> En choisissant des tags non ambigus, on évite les erreurs pouvant
>>> laisser penser qu'une emprise "passée" est actuelle.
>>> Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent
>>> de ces infos, et rien de spécial à faire pour les contributeurs... ces
>>> infos étant très stables dans le temps, ce n'est pas là dessus qu'on
>>> contribue beaucoup ;)
>>>
>>>
>>> Le lun. 31 déc. 2018 à 19:07, JB  a écrit :
>>>
 Question bête d'un gars dont ce n'est pas le métier :
 Est-ce que c'est vraiment à conserver dans OSM ?
 Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
 anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
 quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
 pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
 est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
 ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
 chercher les éléments dans une autre base de données, quitte à ajouter
 l'information spatiale à partir d'éléments simples d'OSM ?
 Dubitatif, et toujours adepte de garder de l'information simple. Pour
 la comprendre quand on contribue. Moi, et surtout les nouveaux
 contributeurs potentiels, qui ne connaissent rien au sujet.
 JB.

 Le 31/12/2018 à 18:18, Christian Quest a écrit :

 Oui, il va falloir suivre les publications de dernière minute... quel
 bazar !
 Je suis presque chaud pour rajouter un 4ème épisode à ma série
 "Millésimons"*

 Bien vue la requête overpass, heureusement que mon script amis à jour
 les admin_level sur les anciennes frontières internes des communes
 nouvelles ;)

 Pour les EPCI, il va falloir attendre que la DGCL publie une liste à
 jour (base BANATIC).

 Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
 principe mis à jour admin_type:FR=ancienne commune nouvelle

 Effectivement si on veut que la somme des admin_level=9 correspondent à
 l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
 petits morceaux du puzzle...

 On peut toujours les retrouver avec le disused:admin_level=8

 C'est à bien documenter une fois qu'on aura trouvé un consensus ;)


 * https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf

 Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat 
 a écrit :

> Bien jouer Christian!
>
> Il va falloir continuer à suivre la page Wikipédia
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au
> dernier moment et qui

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-12 Par sujet Christian Quest 
L'INSEE va publier une liste en principe la semaine prochaine... je referai
une passe en me basant dessus.

Le dim. 13 janv. 2019 à 01:49, Jérôme Amagat  a
écrit :

> Plusieurs ajouts sur Wikipédia depuis le 1er janvier :
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> il y a des cas bizarres :( :
> Beyrede-Jumet-Camous sans accent sur Beyrede dans l’arrêté préfectoral
> alors qu'il y en avait sur l'ancienne commune de Beyrède-Jumet.
> Fresnay-sur-Sarthe : composé de 3 communes qui ne se touchent pas toutes
> alors qu'il me semble que c'est obligatoire. Il semble n'y avoir que
> quelques mètres entre les anciennes communes de Fresnay-sur-Sarthe
> et Saint-Germain-sur-Sarthe mais elle ne sont pas contiguës.
> https://www.openstreetmap.org/relation/107624 et
> https://www.openstreetmap.org/relation/107591.
> Cette commune nouvelle de Fresnay-sur-Sarthe n'existe pas encore dans osm
> contrairement aux autres.
>
>
> Le lun. 31 déc. 2018 à 19:53, Christian Quest  a
> écrit :
>
>> Il y a encore de très nombreux usages des limites de communes
>> correspondant à quelques années en arrière et c'est donc utile de les
>> conserver quelques années.
>>
>> Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
>> appellations qui dureront bien plus longtemps car ces communes nouvelles
>> sont souvent une création vécue comme artificielle par les habitants.
>>
>> En choisissant des tags non ambigus, on évite les erreurs pouvant laisser
>> penser qu'une emprise "passée" est actuelle.
>> Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent
>> de ces infos, et rien de spécial à faire pour les contributeurs... ces
>> infos étant très stables dans le temps, ce n'est pas là dessus qu'on
>> contribue beaucoup ;)
>>
>>
>> Le lun. 31 déc. 2018 à 19:07, JB  a écrit :
>>
>>> Question bête d'un gars dont ce n'est pas le métier :
>>> Est-ce que c'est vraiment à conserver dans OSM ?
>>> Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
>>> anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
>>> quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
>>> pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
>>> est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
>>> ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
>>> chercher les éléments dans une autre base de données, quitte à ajouter
>>> l'information spatiale à partir d'éléments simples d'OSM ?
>>> Dubitatif, et toujours adepte de garder de l'information simple. Pour la
>>> comprendre quand on contribue. Moi, et surtout les nouveaux contributeurs
>>> potentiels, qui ne connaissent rien au sujet.
>>> JB.
>>>
>>> Le 31/12/2018 à 18:18, Christian Quest a écrit :
>>>
>>> Oui, il va falloir suivre les publications de dernière minute... quel
>>> bazar !
>>> Je suis presque chaud pour rajouter un 4ème épisode à ma série
>>> "Millésimons"*
>>>
>>> Bien vue la requête overpass, heureusement que mon script amis à jour
>>> les admin_level sur les anciennes frontières internes des communes
>>> nouvelles ;)
>>>
>>> Pour les EPCI, il va falloir attendre que la DGCL publie une liste à
>>> jour (base BANATIC).
>>>
>>> Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
>>> principe mis à jour admin_type:FR=ancienne commune nouvelle
>>>
>>> Effectivement si on veut que la somme des admin_level=9 correspondent à
>>> l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
>>> petits morceaux du puzzle...
>>>
>>> On peut toujours les retrouver avec le disused:admin_level=8
>>>
>>> C'est à bien documenter une fois qu'on aura trouvé un consensus ;)
>>>
>>>
>>> * https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf
>>>
>>> Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat  a
>>> écrit :
>>>
 Bien jouer Christian!

 Il va falloir continuer à suivre la page Wikipédia
 https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
 au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au
 dernier moment et qui paraissent que début janvier.

 Les intercom et les arrondissements départementaux ne sont constitués
 que de communes entières. Il y a des communes nouvelles de plusieurs
 intercom ou d'arrondissements et donc des intercom et arrondissement qui
 ont du être modifiés.
 Je pense que cette requête overpass turbo permet de trouver des
 frontières où il y a un problèmes ( frontières d'intercom mais pas de
 communes) :
 https://overpass-turbo.eu/s/ER6
 (on peut faire pareil pour les arrondissement mais on trouve des
 frontières où il n'y a pas forcement des problèmes)

 En ce début d'année, il peut y avoir des changements dans les intercom
 et les arrondissements non liés aux communes nouvelles mais malheureusement
 je ne crois pas qu'il y ai de listes

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2019-01-12 Par sujet Jérôme Amagat 
Plusieurs ajouts sur Wikipédia depuis le 1er janvier :
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
il y a des cas bizarres :( :
Beyrede-Jumet-Camous sans accent sur Beyrede dans l’arrêté préfectoral
alors qu'il y en avait sur l'ancienne commune de Beyrède-Jumet.
Fresnay-sur-Sarthe : composé de 3 communes qui ne se touchent pas toutes
alors qu'il me semble que c'est obligatoire. Il semble n'y avoir que
quelques mètres entre les anciennes communes de Fresnay-sur-Sarthe
et Saint-Germain-sur-Sarthe mais elle ne sont pas contiguës.
https://www.openstreetmap.org/relation/107624 et
https://www.openstreetmap.org/relation/107591.
Cette commune nouvelle de Fresnay-sur-Sarthe n'existe pas encore dans osm
contrairement aux autres.


Le lun. 31 déc. 2018 à 19:53, Christian Quest  a
écrit :

> Il y a encore de très nombreux usages des limites de communes
> correspondant à quelques années en arrière et c'est donc utile de les
> conserver quelques années.
>
> Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
> appellations qui dureront bien plus longtemps car ces communes nouvelles
> sont souvent une création vécue comme artificielle par les habitants.
>
> En choisissant des tags non ambigus, on évite les erreurs pouvant laisser
> penser qu'une emprise "passée" est actuelle.
> Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent
> de ces infos, et rien de spécial à faire pour les contributeurs... ces
> infos étant très stables dans le temps, ce n'est pas là dessus qu'on
> contribue beaucoup ;)
>
>
> Le lun. 31 déc. 2018 à 19:07, JB  a écrit :
>
>> Question bête d'un gars dont ce n'est pas le métier :
>> Est-ce que c'est vraiment à conserver dans OSM ?
>> Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
>> anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
>> quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
>> pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
>> est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
>> ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
>> chercher les éléments dans une autre base de données, quitte à ajouter
>> l'information spatiale à partir d'éléments simples d'OSM ?
>> Dubitatif, et toujours adepte de garder de l'information simple. Pour la
>> comprendre quand on contribue. Moi, et surtout les nouveaux contributeurs
>> potentiels, qui ne connaissent rien au sujet.
>> JB.
>>
>> Le 31/12/2018 à 18:18, Christian Quest a écrit :
>>
>> Oui, il va falloir suivre les publications de dernière minute... quel
>> bazar !
>> Je suis presque chaud pour rajouter un 4ème épisode à ma série
>> "Millésimons"*
>>
>> Bien vue la requête overpass, heureusement que mon script amis à jour les
>> admin_level sur les anciennes frontières internes des communes nouvelles ;)
>>
>> Pour les EPCI, il va falloir attendre que la DGCL publie une liste à jour
>> (base BANATIC).
>>
>> Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
>> principe mis à jour admin_type:FR=ancienne commune nouvelle
>>
>> Effectivement si on veut que la somme des admin_level=9 correspondent à
>> l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
>> petits morceaux du puzzle...
>>
>> On peut toujours les retrouver avec le disused:admin_level=8
>>
>> C'est à bien documenter une fois qu'on aura trouvé un consensus ;)
>>
>>
>> * https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf
>>
>> Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat  a
>> écrit :
>>
>>> Bien jouer Christian!
>>>
>>> Il va falloir continuer à suivre la page Wikipédia
>>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>>> au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au
>>> dernier moment et qui paraissent que début janvier.
>>>
>>> Les intercom et les arrondissements départementaux ne sont constitués
>>> que de communes entières. Il y a des communes nouvelles de plusieurs
>>> intercom ou d'arrondissements et donc des intercom et arrondissement qui
>>> ont du être modifiés.
>>> Je pense que cette requête overpass turbo permet de trouver des
>>> frontières où il y a un problèmes ( frontières d'intercom mais pas de
>>> communes) :
>>> https://overpass-turbo.eu/s/ER6
>>> (on peut faire pareil pour les arrondissement mais on trouve des
>>> frontières où il n'y a pas forcement des problèmes)
>>>
>>> En ce début d'année, il peut y avoir des changements dans les intercom
>>> et les arrondissements non liés aux communes nouvelles mais malheureusement
>>> je ne crois pas qu'il y ai de listes de ces changements :)
>>> (J'ai fait l'un de ces changements dans osm dans l'Ain, un intercom en
>>> absorbe un autre)
>>>
>>> J'ai vu que pour les ancienne communes nouvelles qui ont fusionnées en
>>> de plus grandes communes nouvelles, il y a parfois admin_level=9.
>>> Je pense que ça

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-31 Par sujet Christian Quest 
Il y a encore de très nombreux usages des limites de communes correspondant
à quelques années en arrière et c'est donc utile de les conserver quelques
années.

Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
appellations qui dureront bien plus longtemps car ces communes nouvelles
sont souvent une création vécue comme artificielle par les habitants.

En choisissant des tags non ambigus, on évite les erreurs pouvant laisser
penser qu'une emprise "passée" est actuelle.
Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent de
ces infos, et rien de spécial à faire pour les contributeurs... ces infos
étant très stables dans le temps, ce n'est pas là dessus qu'on contribue
beaucoup ;)


Le lun. 31 déc. 2018 à 19:07, JB  a écrit :

> Question bête d'un gars dont ce n'est pas le métier :
> Est-ce que c'est vraiment à conserver dans OSM ?
> Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
> anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
> quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
> pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
> est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
> ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
> chercher les éléments dans une autre base de données, quitte à ajouter
> l'information spatiale à partir d'éléments simples d'OSM ?
> Dubitatif, et toujours adepte de garder de l'information simple. Pour la
> comprendre quand on contribue. Moi, et surtout les nouveaux contributeurs
> potentiels, qui ne connaissent rien au sujet.
> JB.
>
> Le 31/12/2018 à 18:18, Christian Quest a écrit :
>
> Oui, il va falloir suivre les publications de dernière minute... quel
> bazar !
> Je suis presque chaud pour rajouter un 4ème épisode à ma série
> "Millésimons"*
>
> Bien vue la requête overpass, heureusement que mon script amis à jour les
> admin_level sur les anciennes frontières internes des communes nouvelles ;)
>
> Pour les EPCI, il va falloir attendre que la DGCL publie une liste à jour
> (base BANATIC).
>
> Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
> principe mis à jour admin_type:FR=ancienne commune nouvelle
>
> Effectivement si on veut que la somme des admin_level=9 correspondent à
> l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
> petits morceaux du puzzle...
>
> On peut toujours les retrouver avec le disused:admin_level=8
>
> C'est à bien documenter une fois qu'on aura trouvé un consensus ;)
>
>
> * https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf
>
> Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat  a
> écrit :
>
>> Bien jouer Christian!
>>
>> Il va falloir continuer à suivre la page Wikipédia
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au
>> dernier moment et qui paraissent que début janvier.
>>
>> Les intercom et les arrondissements départementaux ne sont constitués que
>> de communes entières. Il y a des communes nouvelles de plusieurs intercom
>> ou d'arrondissements et donc des intercom et arrondissement qui ont du être
>> modifiés.
>> Je pense que cette requête overpass turbo permet de trouver des
>> frontières où il y a un problèmes ( frontières d'intercom mais pas de
>> communes) :
>> https://overpass-turbo.eu/s/ER6
>> (on peut faire pareil pour les arrondissement mais on trouve des
>> frontières où il n'y a pas forcement des problèmes)
>>
>> En ce début d'année, il peut y avoir des changements dans les intercom et
>> les arrondissements non liés aux communes nouvelles mais malheureusement je
>> ne crois pas qu'il y ai de listes de ces changements :)
>> (J'ai fait l'un de ces changements dans osm dans l'Ain, un intercom en
>> absorbe un autre)
>>
>> J'ai vu que pour les ancienne communes nouvelles qui ont fusionnées en de
>> plus grandes communes nouvelles, il y a parfois admin_level=9.
>> Je pense que ça n'a pas de sens, elles n'ont plus de rôle administratif
>> et ne devrait pas avoir de admin_level=* et avoir disused:admin_level=8 et
>> même disused:boundary=administrative.
>> Les ancienne communes d'avant la 1ere communes nouvelles, elles gardent
>> admin_level=9 si elles sont communes déléguées.
>> Si elle ne le sont pas, je pense que si on veux être logique il ne
>> devrait plus y avoir de admin_level=*
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
>

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-31 Par sujet JB 

Question bête d'un gars dont ce n'est pas le métier :
Est-ce que c'est vraiment à conserver dans OSM ?
Avant, on avait juste les admin_level=8. On a transformé en =9 pour les 
anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en 
quelque chose d'autre parce qu'une commune a intégré la nouvelle commune 
pour faire une autre nouvelle commune ? Est-ce que le modèle de tags 
d'OSM est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra 
quelque chose ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur 
potentiel n'ira pas chercher les éléments dans une autre base de 
données, quitte à ajouter l'information spatiale à partir d'éléments 
simples d'OSM ?
Dubitatif, et toujours adepte de garder de l'information simple. Pour la 
comprendre quand on contribue. Moi, et surtout les nouveaux 
contributeurs potentiels, qui ne connaissent rien au sujet.

JB.

Le 31/12/2018 à 18:18, Christian Quest a écrit :
Oui, il va falloir suivre les publications de dernière minute... quel 
bazar !
Je suis presque chaud pour rajouter un 4ème épisode à ma série 
"Millésimons"*


Bien vue la requête overpass, heureusement que mon script amis à jour 
les admin_level sur les anciennes frontières internes des communes 
nouvelles ;)


Pour les EPCI, il va falloir attendre que la DGCL publie une liste à 
jour (base BANATIC).


Pour les anciennes communes nouvelles qui se sont étendues, j'ai en 
principe mis à jour admin_type:FR=ancienne commune nouvelle


Effectivement si on veut que la somme des admin_level=9 correspondent 
à l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur 
les plus petits morceaux du puzzle...


On peut toujours les retrouver avec le disused:admin_level=8

C'est à bien documenter une fois qu'on aura trouvé un consensus ;)


* https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf

Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat > a écrit :


Bien jouer Christian!

Il va falloir continuer à suivre la page Wikipédia

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019

au cas ou il y ai des oublies ou des arrêtés préfectoraux signés
au dernier moment et qui paraissent que début janvier.

Les intercom et les arrondissements départementaux ne sont
constitués que de communes entières. Il y a des communes nouvelles
de plusieurs intercom ou d'arrondissements et donc des intercom et
arrondissement qui ont du être modifiés.
Je pense que cette requête overpass turbo permet de trouver des
frontières où il y a un problèmes ( frontières d'intercom mais pas
de communes) :
https://overpass-turbo.eu/s/ER6
(on peut faire pareil pour les arrondissement mais on trouve des
frontières où il n'y a pas forcement des problèmes)

En ce début d'année, il peut y avoir des changements dans les
intercom et les arrondissements non liés aux communes nouvelles
mais malheureusement je ne crois pas qu'il y ai de listes de ces
changements :)
(J'ai fait l'un de ces changements dans osm dans l'Ain, un
intercom en absorbe un autre)

J'ai vu que pour les ancienne communes nouvelles qui ont
fusionnées en de plus grandes communes nouvelles, il y a parfois
admin_level=9.
Je pense que ça n'a pas de sens, elles n'ont plus de rôle
administratif et ne devrait pas avoir de admin_level=* et avoir
disused:admin_level=8 et même disused:boundary=administrative.
Les ancienne communes d'avant la 1ere communes nouvelles, elles
gardent admin_level=9 si elles sont communes déléguées.
Si elle ne le sont pas, je pense que si on veux être logique il ne
devrait plus y avoir de admin_level=*




___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr



--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-31 Par sujet Christian Quest 
Oui, il va falloir suivre les publications de dernière minute... quel bazar
!
Je suis presque chaud pour rajouter un 4ème épisode à ma série
"Millésimons"*

Bien vue la requête overpass, heureusement que mon script amis à jour les
admin_level sur les anciennes frontières internes des communes nouvelles ;)

Pour les EPCI, il va falloir attendre que la DGCL publie une liste à jour
(base BANATIC).

Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
principe mis à jour admin_type:FR=ancienne commune nouvelle

Effectivement si on veut que la somme des admin_level=9 correspondent à
l'admin_level=8 qui les regroupe, il ne faudrait le garder que sur les plus
petits morceaux du puzzle...

On peut toujours les retrouver avec le disused:admin_level=8

C'est à bien documenter une fois qu'on aura trouvé un consensus ;)


* https://medium.com/@cq94/mill%C3%A9simons-3fa21714abdf

Le lun. 31 déc. 2018 à 13:15, Jérôme Amagat  a
écrit :

> Bien jouer Christian!
>
> Il va falloir continuer à suivre la page Wikipédia
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au
> dernier moment et qui paraissent que début janvier.
>
> Les intercom et les arrondissements départementaux ne sont constitués que
> de communes entières. Il y a des communes nouvelles de plusieurs intercom
> ou d'arrondissements et donc des intercom et arrondissement qui ont du être
> modifiés.
> Je pense que cette requête overpass turbo permet de trouver des frontières
> où il y a un problèmes ( frontières d'intercom mais pas de communes) :
> https://overpass-turbo.eu/s/ER6
> (on peut faire pareil pour les arrondissement mais on trouve des
> frontières où il n'y a pas forcement des problèmes)
>
> En ce début d'année, il peut y avoir des changements dans les intercom et
> les arrondissements non liés aux communes nouvelles mais malheureusement je
> ne crois pas qu'il y ai de listes de ces changements :)
> (J'ai fait l'un de ces changements dans osm dans l'Ain, un intercom en
> absorbe un autre)
>
> J'ai vu que pour les ancienne communes nouvelles qui ont fusionnées en de
> plus grandes communes nouvelles, il y a parfois admin_level=9.
> Je pense que ça n'a pas de sens, elles n'ont plus de rôle administratif et
> ne devrait pas avoir de admin_level=* et avoir disused:admin_level=8 et
> même disused:boundary=administrative.
> Les ancienne communes d'avant la 1ere communes nouvelles, elles gardent
> admin_level=9 si elles sont communes déléguées.
> Si elle ne le sont pas, je pense que si on veux être logique il ne devrait
> plus y avoir de admin_level=*
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-31 Par sujet Jérôme Amagat 
Bien jouer Christian!

Il va falloir continuer à suivre la page Wikipédia
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
au cas ou il y ai des oublies ou des arrêtés préfectoraux signés au dernier
moment et qui paraissent que début janvier.

Les intercom et les arrondissements départementaux ne sont constitués que
de communes entières. Il y a des communes nouvelles de plusieurs intercom
ou d'arrondissements et donc des intercom et arrondissement qui ont du être
modifiés.
Je pense que cette requête overpass turbo permet de trouver des frontières
où il y a un problèmes ( frontières d'intercom mais pas de communes) :
https://overpass-turbo.eu/s/ER6
(on peut faire pareil pour les arrondissement mais on trouve des frontières
où il n'y a pas forcement des problèmes)

En ce début d'année, il peut y avoir des changements dans les intercom et
les arrondissements non liés aux communes nouvelles mais malheureusement je
ne crois pas qu'il y ai de listes de ces changements :)
(J'ai fait l'un de ces changements dans osm dans l'Ain, un intercom en
absorbe un autre)

J'ai vu que pour les ancienne communes nouvelles qui ont fusionnées en de
plus grandes communes nouvelles, il y a parfois admin_level=9.
Je pense que ça n'a pas de sens, elles n'ont plus de rôle administratif et
ne devrait pas avoir de admin_level=* et avoir disused:admin_level=8 et
même disused:boundary=administrative.
Les ancienne communes d'avant la 1ere communes nouvelles, elles gardent
admin_level=9 si elles sont communes déléguées.
Si elle ne le sont pas, je pense que si on veux être logique il ne devrait
plus y avoir de admin_level=*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-30 Par sujet JB 
Ce qui est bien, dans un wiki pléthorique, c'est qu'on trouve toujours 
ce qu'on veut. Même avec l'indication en en-tête :
"Some methods are common, others are less widely used or discouraged. 
Some methods are strongly discouraged for the main OSM project but 
accepted and in widespread use in the separate Open Historical Map 
 project."
Les pages moins ésotériques n'indiquent juste pas la méthode : 
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

JB.

Le 30/12/2018 à 18:07, osm.sanspourr...@spamgourmet.com a écrit :


Heureusement la position d'extension temporelle ne s'est pas faite 
sans réfléchir aux conséquences.


Ajouter le paramètre temporel en variable aurait cassé toutes les 
valeurs, imposant à tout utilisateur des données de regarder s'il 
s'agit d'une valeur normale ou d'une valeur temporelle.


Là on introduit de nouvelles clés évaluées seulement par l'humain ou 
par la machine à un instant t et remplaçant donc la clé suffixée par 
cette même clé non suffixée.


Date_namespace_suffix_as_"keyname:DATESPEC=..." 



C'est la même logique que le disused: utilisé aussi par Christian mais 
cette fois-ci en utilisant le suffixe et non le préfixe.


Lifecycle prefix (: = ) 
: 
si tu te fiches de l'aspect temporel tu ignores simplement ces clés, 
si ça t'intéresse tu les gères. La logique de JB serait : tu casses 
tout ce qui existe dès que tu introduis un paramètre temporel.


Jean-Yvon


Le 30/12/2018 à 09:46, JB - jb...@mailoo.org a écrit :

Le 29/12/2018 à 21:54, Christian Quest a écrit :


admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce 
que les précédentes communes fusionnées ont été mise à jour comme 
cela par quelqu'un de façon systématique ?


La syntaxe est déconseillée : pas de valeur variable dans la clé (ici 
la date), la partie variable est dans la valeur (à droite du "=").



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-30 Par sujet osm . sanspourriel 
Heureusement la position d'extension temporelle ne s'est pas faite sans 
réfléchir aux conséquences.


Ajouter le paramètre temporel en variable aurait cassé toutes les 
valeurs, imposant à tout utilisateur des données de regarder s'il s'agit 
d'une valeur normale ou d'une valeur temporelle.


Là on introduit de nouvelles clés évaluées seulement par l'humain ou par 
la machine à un instant t et remplaçant donc la clé suffixée par cette 
même clé non suffixée.


Date_namespace_suffix_as_"keyname:DATESPEC=..." 



C'est la même logique que le disused: utilisé aussi par Christian mais 
cette fois-ci en utilisant le suffixe et non le préfixe.


Lifecycle prefix (: = ) 
: 
si tu te fiches de l'aspect temporel tu ignores simplement ces clés, si 
ça t'intéresse tu les gères. La logique de JB serait : tu casses tout ce 
qui existe dès que tu introduis un paramètre temporel.


Jean-Yvon


Le 30/12/2018 à 09:46, JB - jb...@mailoo.org a écrit :

Le 29/12/2018 à 21:54, Christian Quest a écrit :


admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce 
que les précédentes communes fusionnées ont été mise à jour comme 
cela par quelqu'un de façon systématique ?


La syntaxe est déconseillée : pas de valeur variable dans la clé (ici 
la date), la partie variable est dans la valeur (à droite du "=").



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-30 Par sujet JB 

Le 29/12/2018 à 21:54, Christian Quest a écrit :


admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce que 
les précédentes communes fusionnées ont été mise à jour comme cela par 
quelqu'un de façon systématique ?


La syntaxe est déconseillée : pas de valeur variable dans la clé (ici la 
date), la partie variable est dans la valeur (à droite du "=").



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Jérôme Amagat 
Un problème avec Pont-l'Évêque relation 279314
la commune nouvelle na pas été créé mais une partie des tag est sur
l'ancienne commune qui porte le même nom.
J'ai pas l'impression que le même problème ai eu lieu ailleurs.

J'ai pas fait les modifications
(Pas le temps de le faire maintenant)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet osm . sanspourriel 
J'ai ajouté les noms en breton quand ils étaient triviaux (pour les 
seules communes nouvelles de Bretagne). Une petite passe par les 
brittophones ?


Restera à mettre à jour les noms des mairies, arrêts de gares et autres 
bureaux de poste au fur et à mesure des changements effectifs.


Erreur qui m'a semblé générique : les communes nouvelles reprenant le 
nom d'une ancienne commune sont dépourvus des liens wikidata et 
wikipedia alors qu'il faut reprendre ceux de l'ancienne commune de même 
nom. J'ai corrigé pour les communes bretonnes.


Ça va être simple pour savoir si on parle de la nouvelle ou de 
l'ancienne commune. Ce ne sont pas les Brestois de Brest-même qui vont 
me contredire ;-). Non je n'ai pas ajouté alt_name=-même sur les 
anciennes communes !


Pour la population, avec les nouveaux recensements INSEE, la mise à jour 
de population= va devoir s'appuyer sur le niveau 9 s'il existe, simple ! 
Et sinon additionner les niveaux 9 pour faire le niveau 8.


Le prochain script de Christian ? Faites vos vœux pour 2019 ;-).

Jean-Yvon

Le 29/12/2018 à 21:54, Christian Quest - cqu...@openstreetmap.fr a écrit :
Le script ne touche pas du tout aux noeuds place=*, il ne fait que 
créer les nouvelles relations, mettre à jour les anciennes relations 
et les way (ceux qui passent de admin_level 8 à 9).


Pour...

admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce que 
les précédentes communes fusionnées ont été mise à jour comme cela par 
quelqu'un de façon systématique ?




Le sam. 29 déc. 2018 à 20:49, > a écrit :


Bonjour, premier test première remarque (outre les louanges
méritées) :

les communes actuelles comme par exemple Châtelaudren

n'ont pas de end_date.

Plus exactement

admin_level:-2018-12-31=8

admin_level:2019-01-01-=9

disused:admin_level c'est faux aujourd'hui ;-) et les
admin_level:- et admin_level:- sont et resteront valables.

Faire de même pour les ref:INSEE
 ?

Chirstian Q. un script a repasser ?

Christian R. des name:br à ajouter ;-)

Jean-Yvon

Le 29/12/2018 à 17:19, Christian Quest - cqu...@openstreetmap.fr
 a écrit :

Je pense que official_name est là pour ces noms administratifs
non respectueux des règles de toponymie... et name pour la
version "propre" Bresse-Vallons, Porte-des-Pierres-Dorées, etc...

Je n'ai pas fait ces corrections dans mes scripts, ça sera pour
le fignolage final ;)

Les département 01 à 50 sont traités... et maintenant à vérifier !
Je fais une vérif manuelle avant upload, mais je peux laisser
passer des pépins vu la quantité même si je fais ça un
département à la fois.


Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin
mailto:gwenael.jou...@laposte.net>>
a écrit :

Merci pour ce boulot.

Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma
zone :-)


Par contre je constate avec agacement que les règles
d’écriture des toponymes n’est toujours pas correctement
appliquée ni par les conseillers municipaux, ni par les préfets…
Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).

C’est pourtant pas faute de leur rappeler :

http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf


Doit-on, par cohérence avec les documents réglementaires,
restituer ces fautes dans OSM ?



Le 29/12/2018 à 14:52, Christian Quest a écrit :
> Comme chaque fin d'année, c'est le chantier des fusions qui
s'ouvre ;)
>
> 608 communes fusionnent en 232 communes nouvelles d'après
wikipédia:
>
>

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>
> J'ai donc ressorti mes scripts de mise à jour, car faire
tout ça à la main sans erreur c'est assez chaud !
>
> Première étape, récupérer les données du tableau wikipédia:
c'est fait, j'ai un json prêt à consommer.
>
> Deuxième étape: appliquer les modifications... je suis en
train de tester.
>
> C'est complexe car certaines communes nouvelles ont déjà
été créées, et il ne faut pas se mélanger avec le cas de
communes nouvelles créées ces dernières années qui absorbent
encore quelques communes.
>
> Troisième étape: vérification... là un peu d'humain sera
bien utile, donc si ça vous intéresse, ce fil de discussion
est là pour ça !
>
> Je compte appliquer les modifications aujourd'hui et demain
pour laisser le 31 et le 1er pour faire les vérifications et

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Christian Quest 
Le script ne touche pas du tout aux noeuds place=*, il ne fait que créer
les nouvelles relations, mettre à jour les anciennes relations et les way
(ceux qui passent de admin_level 8 à 9).

Pour...

admin_level:-2018-12-31=8
admin_level:2019-01-01-=9

je ne connaissais pas la syntaxe, je peux les ajouter, mais est-ce que les
précédentes communes fusionnées ont été mise à jour comme cela par
quelqu'un de façon systématique ?



Le sam. 29 déc. 2018 à 20:49,  a écrit :

> Bonjour, premier test première remarque (outre les louanges méritées) :
>
> les communes actuelles comme par exemple Châtelaudren
> 
> n'ont pas de end_date.
>
> Plus exactement
>
> admin_level:-2018-12-31=8
>
> admin_level:2019-01-01-=9
>
> disused:admin_level c'est faux aujourd'hui ;-) et les admin_level:-
> et admin_level:- sont et resteront valables.
>
> Faire de même pour les ref:INSEE
>  ?
>
> Chirstian Q. un script a repasser ?
>
> Christian R. des name:br à ajouter ;-)
>
> Jean-Yvon
> Le 29/12/2018 à 17:19, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Je pense que official_name est là pour ces noms administratifs non
> respectueux des règles de toponymie... et name pour la version "propre"
> Bresse-Vallons, Porte-des-Pierres-Dorées, etc...
>
> Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le
> fignolage final ;)
>
> Les département 01 à 50 sont traités... et maintenant à vérifier !
> Je fais une vérif manuelle avant upload, mais je peux laisser passer des
> pépins vu la quantité même si je fais ça un département à la fois.
>
>
> Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin 
> a écrit :
>
>> Merci pour ce boulot.
>>
>> Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)
>>
>>
>> Par contre je constate avec agacement que les règles d’écriture des
>> toponymes n’est toujours pas correctement appliquée ni par les conseillers
>> municipaux, ni par les préfets…
>> Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).
>>
>> C’est pourtant pas faute de leur rappeler :
>>
>> http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf
>>
>>
>> Doit-on, par cohérence avec les documents réglementaires, restituer ces
>> fautes dans OSM ?
>>
>>
>>
>> Le 29/12/2018 à 14:52, Christian Quest a écrit :
>> > Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)
>> >
>> > 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
>> >
>> >
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> >
>> > J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la
>> main sans erreur c'est assez chaud !
>> >
>> > Première étape, récupérer les données du tableau wikipédia: c'est fait,
>> j'ai un json prêt à consommer.
>> >
>> > Deuxième étape: appliquer les modifications... je suis en train de
>> tester.
>> >
>> > C'est complexe car certaines communes nouvelles ont déjà été créées, et
>> il ne faut pas se mélanger avec le cas de communes nouvelles créées ces
>> dernières années qui absorbent encore quelques communes.
>> >
>> > Troisième étape: vérification... là un peu d'humain sera bien utile,
>> donc si ça vous intéresse, ce fil de discussion est là pour ça !
>> >
>> > Je compte appliquer les modifications aujourd'hui et demain pour
>> laisser le 31 et le 1er pour faire les vérifications et corrections.
>> >
>> > --
>> > Christian Quest - OpenStreetMap France
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet osm . sanspourriel 

Bonjour, premier test première remarque (outre les louanges méritées) :

les communes actuelles comme par exemple Châtelaudren 
 
n'ont pas de end_date.


Plus exactement

admin_level:-2018-12-31=8

admin_level:2019-01-01-=9

disused:admin_level c'est faux aujourd'hui ;-) et les 
admin_level:- et admin_level:- sont et resteront valables.


Faire de même pour les ref:INSEE 
 ?


Chirstian Q. un script a repasser ?

Christian R. des name:br à ajouter ;-)

Jean-Yvon

Le 29/12/2018 à 17:19, Christian Quest - cqu...@openstreetmap.fr a écrit :
Je pense que official_name est là pour ces noms administratifs non 
respectueux des règles de toponymie... et name pour la version 
"propre" Bresse-Vallons, Porte-des-Pierres-Dorées, etc...


Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le 
fignolage final ;)


Les département 01 à 50 sont traités... et maintenant à vérifier !
Je fais une vérif manuelle avant upload, mais je peux laisser passer 
des pépins vu la quantité même si je fais ça un département à la fois.



Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin 
mailto:gwenael.jou...@laposte.net>> a écrit :


Merci pour ce boulot.

Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)


Par contre je constate avec agacement que les règles d’écriture
des toponymes n’est toujours pas correctement appliquée ni par les
conseillers municipaux, ni par les préfets…
Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).

C’est pourtant pas faute de leur rappeler :
http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf


Doit-on, par cohérence avec les documents réglementaires,
restituer ces fautes dans OSM ?



Le 29/12/2018 à 14:52, Christian Quest a écrit :
> Comme chaque fin d'année, c'est le chantier des fusions qui
s'ouvre ;)
>
> 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
>
>

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>
> J'ai donc ressorti mes scripts de mise à jour, car faire tout ça
à la main sans erreur c'est assez chaud !
>
> Première étape, récupérer les données du tableau wikipédia:
c'est fait, j'ai un json prêt à consommer.
>
> Deuxième étape: appliquer les modifications... je suis en train
de tester.
>
> C'est complexe car certaines communes nouvelles ont déjà été
créées, et il ne faut pas se mélanger avec le cas de communes
nouvelles créées ces dernières années qui absorbent encore
quelques communes.
>
> Troisième étape: vérification... là un peu d'humain sera bien
utile, donc si ça vous intéresse, ce fil de discussion est là pour
ça !
>
> Je compte appliquer les modifications aujourd'hui et demain pour
laisser le 31 et le 1er pour faire les vérifications et corrections.
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Christian Quest 
Tout est maintenant traité... la chasse aux erreurs est ouverte !

Le sam. 29 déc. 2018 à 17:19, Christian Quest  a
écrit :

> Je pense que official_name est là pour ces noms administratifs non
> respectueux des règles de toponymie... et name pour la version "propre"
> Bresse-Vallons, Porte-des-Pierres-Dorées, etc...
>
> Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le
> fignolage final ;)
>
> Les département 01 à 50 sont traités... et maintenant à vérifier !
> Je fais une vérif manuelle avant upload, mais je peux laisser passer des
> pépins vu la quantité même si je fais ça un département à la fois.
>
>
> Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin 
> a écrit :
>
>> Merci pour ce boulot.
>>
>> Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)
>>
>>
>> Par contre je constate avec agacement que les règles d’écriture des
>> toponymes n’est toujours pas correctement appliquée ni par les conseillers
>> municipaux, ni par les préfets…
>> Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).
>>
>> C’est pourtant pas faute de leur rappeler :
>>
>> http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf
>>
>>
>> Doit-on, par cohérence avec les documents réglementaires, restituer ces
>> fautes dans OSM ?
>>
>>
>>
>> Le 29/12/2018 à 14:52, Christian Quest a écrit :
>> > Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)
>> >
>> > 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
>> >
>> >
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> >
>> > J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la
>> main sans erreur c'est assez chaud !
>> >
>> > Première étape, récupérer les données du tableau wikipédia: c'est fait,
>> j'ai un json prêt à consommer.
>> >
>> > Deuxième étape: appliquer les modifications... je suis en train de
>> tester.
>> >
>> > C'est complexe car certaines communes nouvelles ont déjà été créées, et
>> il ne faut pas se mélanger avec le cas de communes nouvelles créées ces
>> dernières années qui absorbent encore quelques communes.
>> >
>> > Troisième étape: vérification... là un peu d'humain sera bien utile,
>> donc si ça vous intéresse, ce fil de discussion est là pour ça !
>> >
>> > Je compte appliquer les modifications aujourd'hui et demain pour
>> laisser le 31 et le 1er pour faire les vérifications et corrections.
>> >
>> > --
>> > Christian Quest - OpenStreetMap France
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Christian Quest 
Je pense que official_name est là pour ces noms administratifs non
respectueux des règles de toponymie... et name pour la version "propre"
Bresse-Vallons, Porte-des-Pierres-Dorées, etc...

Je n'ai pas fait ces corrections dans mes scripts, ça sera pour le
fignolage final ;)

Les département 01 à 50 sont traités... et maintenant à vérifier !
Je fais une vérif manuelle avant upload, mais je peux laisser passer des
pépins vu la quantité même si je fais ça un département à la fois.


Le sam. 29 déc. 2018 à 15:41, Gwenaël Jouvin  a
écrit :

> Merci pour ce boulot.
>
> Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)
>
>
> Par contre je constate avec agacement que les règles d’écriture des
> toponymes n’est toujours pas correctement appliquée ni par les conseillers
> municipaux, ni par les préfets…
> Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).
>
> C’est pourtant pas faute de leur rappeler :
>
> http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf
>
>
> Doit-on, par cohérence avec les documents réglementaires, restituer ces
> fautes dans OSM ?
>
>
>
> Le 29/12/2018 à 14:52, Christian Quest a écrit :
> > Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)
> >
> > 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
> >
> >
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> >
> > J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la
> main sans erreur c'est assez chaud !
> >
> > Première étape, récupérer les données du tableau wikipédia: c'est fait,
> j'ai un json prêt à consommer.
> >
> > Deuxième étape: appliquer les modifications... je suis en train de
> tester.
> >
> > C'est complexe car certaines communes nouvelles ont déjà été créées, et
> il ne faut pas se mélanger avec le cas de communes nouvelles créées ces
> dernières années qui absorbent encore quelques communes.
> >
> > Troisième étape: vérification... là un peu d'humain sera bien utile,
> donc si ça vous intéresse, ce fil de discussion est là pour ça !
> >
> > Je compte appliquer les modifications aujourd'hui et demain pour laisser
> le 31 et le 1er pour faire les vérifications et corrections.
> >
> > --
> > Christian Quest - OpenStreetMap France
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Gwenaël Jouvin 
Merci pour ce boulot.

Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)


Par contre je constate avec agacement que les règles d’écriture des toponymes 
n’est toujours pas correctement appliquée ni par les conseillers municipaux, ni 
par les préfets…
Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).

C’est pourtant pas faute de leur rappeler :
http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf


Doit-on, par cohérence avec les documents réglementaires, restituer ces fautes 
dans OSM ?



Le 29/12/2018 à 14:52, Christian Quest a écrit :
> Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)
> 
> 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
> 
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> 
> J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la main 
> sans erreur c'est assez chaud !
> 
> Première étape, récupérer les données du tableau wikipédia: c'est fait, j'ai 
> un json prêt à consommer.
> 
> Deuxième étape: appliquer les modifications... je suis en train de tester.
> 
> C'est complexe car certaines communes nouvelles ont déjà été créées, et il ne 
> faut pas se mélanger avec le cas de communes nouvelles créées ces dernières 
> années qui absorbent encore quelques communes.
> 
> Troisième étape: vérification... là un peu d'humain sera bien utile, donc si 
> ça vous intéresse, ce fil de discussion est là pour ça !
> 
> Je compte appliquer les modifications aujourd'hui et demain pour laisser le 
> 31 et le 1er pour faire les vérifications et corrections.
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

2018-12-29 Par sujet Christian Quest 
Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)

608 communes fusionnent en 232 communes nouvelles d'après wikipédia:

https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019

J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la main
sans erreur c'est assez chaud !

Première étape, récupérer les données du tableau wikipédia: c'est fait,
j'ai un json prêt à consommer.

Deuxième étape: appliquer les modifications... je suis en train de tester.

C'est complexe car certaines communes nouvelles ont déjà été créées, et il
ne faut pas se mélanger avec le cas de communes nouvelles créées ces
dernières années qui absorbent encore quelques communes.

Troisième étape: vérification... là un peu d'humain sera bien utile, donc
si ça vous intéresse, ce fil de discussion est là pour ça !

Je compte appliquer les modifications aujourd'hui et demain pour laisser le
31 et le 1er pour faire les vérifications et corrections.

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr