<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 30/12/2015 10:43,
      <a class="moz-txt-link-abbreviated" href="mailto:osm.sanspourriel@spamgourmet.com">osm.sanspourriel@spamgourmet.com</a> wrote:<br>
    </div>
    <blockquote cite="mid:5683A741.90902@gmx.net" type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      pour les <b>old_ref:INSEE</b>, je serais plus pour des
      old_ref:INSEE:-2016-01-01=<br>
      (millésimons ! ;-))<br>
      <br>
      Pour le <b>admin_level=9</b>, 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.<br>
    </blockquote>
    <br>
    Des choses assez récentes, justement liées au grand bazar actuel des
    fusions.<br>
    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.<br>
    <br>
    <br>
    <blockquote cite="mid:5683A741.90902@gmx.net" type="cite"> Tu ne
      penses pas au niveau ComCom qui n'est pas (plus) un niveau
      administratif et qui n'est pas de niveau 9 ?<br>
      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.<br>
      <br>
    </blockquote>
    <br>
    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<br>
    <br>
    <blockquote cite="mid:5683A741.90902@gmx.net" type="cite"> En
      ajoutant sur les communes devenues déléguées un tag spécifique
      style :<br>
      <b>? </b><b>admin_type:FR=commune déléguée</b><br>
      on a moyen de changer sans problème.<br>
      <br>
    </blockquote>
    <br>
    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...<br>
    <br>
    <blockquote cite="mid:5683A741.90902@gmx.net" type="cite"> Ma
      requête :<br>
      <i>relation[admin_level=9]({{bbox}})</i><i><br>
      </i><i> ); out center;</i><br>
      <br>
      <b>? source=le JO ou l’arrêté préfectoral</b><b><br>
      </b><b> </b>Le JO c'est plutôt mieux, mais pour Audierne il
      n'était pas sorti (maintenant c'est JORFTEXT000031690191)<br>
      <pre>dep,nouvelle,anciennes,date,population,chflieu,jorf
29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT000031690191</pre>
      <br>
      <b>? start_date=2016-01-01 ou end_date ou autre chose</b><b><br>
      </b>(pour les communes déléguées)<br>
      Comme c'est "seulement" le niveau administratif qui change, ça ma
      gène un peu de mettre un start_date ou un end_date.<br>
      C'est pour cela que je proposais :<br>
      admin_level:-2016-01-01=8 <br>
      admin_level:2016-01-01-=9<br>
      (plus un admin_level=8 jusqu'à demain soir et 9 au delà, <br>
      admin_level=8 et<br>
      admin_level:proposed=9 permettent de scripter le changement à
      minuit) <br>
      Comme ça les outils marchent (admin_level est correct) et on ne
      perd pas l'information.<br>
      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.<br>
      <br>
      Jean-Yvon<br>
      <br>
    </blockquote>
    <br>
    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.<br>
    Les tags que tu présente me semble une fausse bonne idée.<br>
    <br>
    Quelqu'un a regardé comment c'est géré dans d'autres pays ?<br>
    <br>
    admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire,
    mais on n'a pas d'info sur la date de changement.<br>
    <br>
    <br>
    J'avance sur le script... il prend maintenant en compte les
    nouvelles communes déjà présentes.<br>
    J'ai aussi continué à compléter le CSV. Vous pouvez faire des pull
    requests...<br>
    <pre class="moz-signature" cols="72">-- 
Christian Quest - OpenStreetMap France</pre>
  </body>
</html>