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

[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 <jerome.amagat at gmail.com> 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 <cquest at openstreetmap.fr> 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 <jbosm at mailoo.org> 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 <jerome.amagat at gmail.com> 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 at openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>>
>>>>
>>>>
>>>> --
>>>> Christian Quest - OpenStreetMap France
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-fr mailing list
>>>> Talk-fr at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> 
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> 
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>