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 <cqu...@openstreetmap.fr> 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.ama...@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 <cqu...@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 <jb...@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.ama...@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@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 >>> >> _______________________________________________ >> 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
