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

[Christian Quest]

On 30/12/2015 10:43, osm.sanspourriel at spamgourmet.com wrote:
> 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.

Des choses assez récentes, justement liées au grand bazar actuel des
fusions.
Quelques mois en arrière on n'en avait aucune et pour récupérer les
arrondissements municipaux admin_level=9 + ref:INSEE suffisait... là on
récupère plein d'autre choses qui n'ont pas de rapport.


> 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.
>

Je pense mal me faire comprendre... je ne parle pas d'une modélisation
dans l'absolu "ex-nihilo" où oui, admin_level=9 me semblerait adapté. Je
parle d'une utilisation actuelle des données qui va être potentiellement
impactée si on ne prend pas en compte de nouveaux tags, impact qui
serait beaucoup plus limité si on faisait ça sur admin_level=10 qui
n'avait pas l'homogénéité de admin_level=9

> 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.
>

Si on connait ce tag... or les scripts et traitement existant ne le
connaissent pas. Il faut les modifier pour qu'ils ne soient pas impactés...

> 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
>

Mettre la plage temporelle dans le tag, ça les rend fort inutilisables
si ce n'est pas rendu plus générique. J'avais proposé quelque chose du
genre il y a un bout de temps, mais l'allergie ambiante aux données
"historiques" avait eu raison de cette proposition.
Les tags que tu présente me semble une fausse bonne idée.

Quelqu'un a regardé comment c'est géré dans d'autres pays ?

admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire, mais
on n'a pas d'info sur la date de changement.


J'avance sur le script... il prend maintenant en compte les nouvelles
communes déjà présentes.
J'ai aussi continué à compléter le CSV. Vous pouvez faire des pull
requests...

-- 
Christian Quest - OpenStreetMap France

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