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
