Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
mettre la date ou l'intervalle de dates entre parenthèses après la
référence, avec en plus la possibilités de plusieurs refs anciennes
séparées par point-virgule avec chacune la mention de dates? Un seul tag
alors...
Le 30 déc. 2015 10:45, <osm.sanspourr...@spamgourmet.com> a écrit :
> 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 - cqu...@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 <dona...@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.ama...@gmail.com>
>>> To: "Discussions sur OSM en français" <talk-fr@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@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
>
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
