[OSM-talk-fr] Communes nouvelles - fusion de communes

Mer 30 Déc 09:43:29 UTC 2015

pour les *old_ref:INSEE*, je serais plus pour des old_ref:INSEE:-2016-01-01=
(millésimons ! ;-))

Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je 
trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des 
communes associées, déléguées..., bref des choses homogènes qui existent 
déjà, les outils existants ne devraient pas avoir des comportement 
inattendus.
Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau 
administratif et qui n'est pas de niveau 9 ?
Les exceptions sont les arrondissements municipaux et ils sont bien une 
subdivision des trois communes PLM comme le sont les communes déléguées, 
donc au même niveau. Pas de même nature, d'où l'autre attribut.

En ajoutant sur les communes devenues déléguées un tag spécifique style :
*? **admin_type:FR=commune déléguée*
on a moyen de changer sans problème.

Ma requête :
/relation[admin_level=9]({{bbox}})//
// ); out center;/

*? source=le JO ou l’arrêté préfectoral**
***Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti 
(maintenant c'est JORFTEXT000031690191)

dep,nouvelle,anciennes,date,population,chflieu,jorf
29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT000031690191

*? start_date=2016-01-01 ou end_date ou autre chose**
*(pour les communes déléguées)
Comme c'est "seulement" le niveau administratif qui change, ça ma gène 
un peu de mettre un start_date ou un end_date.
C'est pour cela que je proposais :
admin_level:-2016-01-01=8
admin_level:2016-01-01-=9
(plus un admin_level=8 jusqu'à demain soir et 9 au delà,
admin_level=8 et
admin_level:proposed=9 permettent de scripter le changement à minuit)
Comme ça les outils marchent (admin_level est correct) et on ne perd pas 
l'information.
Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet 
d'affiner. Allez, des volontaires pour faire une animation en CSS par 
exemple pour visualiser les changements ? Ça pourrait être parlant pour 
la promotion d'OSM auprès de la PQR ou des voisins de bureau de Christian.

Jean-Yvon

Le 30/12/2015 08:23, Christian Quest - cquest at openstreetmap.fr a écrit :
> Franchement, le admin_level=9 me gène pour la confusion qu'il va créer 
> pour les outils l'utilisant déjà actuellement (et il y en a vu que ces 
> découpages étaient exhaustifs).
>
> Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a 
> des trucs qui merdent à court terme ici ou là.
>
> Sur le process, je propose de faire ça en deux temps et via le script 
> que j'ai écrit:
> 1) création des nouvelles relations avec admin_level:proposed=8 / 
> start_date=2016-01-01
> ça laisse un peu de temps pour vérifier...
> 2) bascule en admin_level=8 et modif des anciennes communes
>
> L'important étant d'avoir le CSV global bien propre. Le script permet 
> d'être homogène et ne mobilise plus de temps humain qu'on peut 
> remettre à profit sur le contrôle du résultat.
>
>
> relation commune délégués :
> type=boundary
> boundary=administrative
> name=*
> ? admin_level=9
> ? source=le JO ou l’arrêté préfectoral
> ? admin_type:FR=commune déléguée
> ? start_date=2016-01-01 ou end_date ou autre chose
>
> il faut bien sur tomber d'accord sur
> quel admin_level?
> tag spécifique oui(lequel?) ou non?
> le truc c'est que le tag spécial commune déléguée peut être facilement 
> supprimé plus tard si on décide qu'il est inutile mais plus difficile 
> a ajouté quant tous sera fini.
>
>
> Le 30 décembre 2015 à 00:46, Donat ROBAUX <donat.r at gmail.com 
> <mailto:donat.r at gmail.com>> a écrit :
>
>     Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à
>     consulter WP... Ils sont vachement plus à jour que nous. Donc nous
>     on est carrément à la ramasse. Ils ont fouillé dans tous les RAA
>     (pas eu le temps de passer partout). Faut dire qu'ils ne sont pas
>     très pratique à consulter.
>     Va falloir aller faire du pompage chez WP ;)
>
>     Pour info et comme je disais dans un précédent mail: sur
>     Légifrance, les arrêtés étant publiés par date d'arrêté et non par
>     publication au JO, j'ai dû remonter jusqu'à la page 7. Des arrêtés
>     datent de juillet et sont publiés seulement le 29/12/2015. Tu
>     m'étonnes que l'INSEE ne peut pas être à jour... (re clin d’œil à
>     Christian dans le cadre de la BAN).
>
>     Donat
>
>
>         ---------- Message transféré ----------
>         From: "Jérôme Amagat" <jerome.amagat at gmail.com
>         <mailto:jerome.amagat at gmail.com>>
>         To: "Discussions sur OSM en français"
>         <talk-fr at openstreetmap.org <mailto:talk-fr at openstreetmap.org>>
>         Cc:
>         Date: Tue, 29 Dec 2015 20:56:15 +0100
>         Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
>         pour la liste des communes nouvelles la page wikipedia :
>         https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
>         basée sur les arrêtés préfectoraux, me semble bien mieux et
>         plus à jour le JO vu qu'il faut attendre que ces même arrêté
>         soit publié au JO
>
>
>     _______________________________________________
>     Talk-fr mailing list
>     Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>     _______________________________________________
>     Talk-fr mailing list
>     Talk-fr at openstreetmap.org <mailto: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

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20151230/440df161/attachment.htm>