<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">Le 5 oct. 2019 à 13:39, <a href="mailto:osm.sanspourriel@spamgourmet.com" class="">osm.sanspourriel@spamgourmet.com</a> a écrit :</div><div class=""><div text="#000000" bgcolor="transparent" class=""><p class="">En général les endroits habités ont une représentation
      surfacique.<br class=""></p></div></div></blockquote><div><br class=""></div>Où peut-on la trouver ? Le cadastre et la nomenclature FANTOIR ne sont pas des sources fiables, car leurs préoccupations n’ont rien à voir avec la dynamique historiques des appellations.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="transparent" class=""><p class="">
    </p><p class=""><br class=""></p><p class="">Je ne comprends pas la remarque de Christian sur les conflits de
      nom entre génération : si besoin on met old_name (et old_name:br
      ^^).</p><p class="">Ni d'ailleurs sur "Au gré du temps, des noms voisins
      apparaissent, le limitent ou l’avalent." : OSM représente
      l'actuel, si la version du cadastre n'est pas à jour on n'intègre
      pas bêtement et c'est tout.</p></div></div></blockquote>Je ne me crois pas capable d’arbitrer entre les générations et les usages administratifs. Ce qui a été  laissé de côté par un groupe générationnel ou administratif peut être revivifié par un autre.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="transparent" class=""><p class="">C'est comme si on disait qu'on n'importe pas les routes parce que
      de nouvelles routes vont être créées ou vont disparaître. Et bien
      non, on prend le bâti actuel et on fait des mises à jour.<br class="">
    </p><p class="">J'ai l'impression que Christian confond représentation en base et
      représentation graphique. Je ne dis pas qu'il faut rendre ces
      limites visibles sur la carte, le landuse me semble ici plus
      pertinent. Par contre Nominatim est à la ramasse. Car quand on dit
      logique floue on est d'accord sauf qu'entre logique floue et
      information ponctuelle il y a un monde : il suffit de voir comment
      Nominatim merdouille sur les lieux-dit pour essayer de dire que X
      est dans le hameau Y pour voir que la définition actuelle est
      insuffisante (et Nominatim pourrait aussi mieux exploiter la
      donnée actuelle).</p><p class="">Donc quand c'est dedans, c'est dedans, quand c'est dehors mais
      juste à côté et que les autres noms sont un peu plus loin, ça se
      discute. Si c'est isolated_dwelling très près alors mais pour
      city_block ou sur une zone administrative, non.<br class=""></p></div></div></blockquote>Ce serait trop simple, car, il y a des lieux habités qui semblent avoir perdu leur nom. Peut-être était-ce Le Petit Truc-muche, mais, comment savoir, à moins de remonter les ou d’interroger les habitants ? Et quand le cadastre donne 3 noms de  pour ce qui apparaît comme un hameau unique et qui était composé de 3 fermes très proches et ayant chacune leur nom ? A moins de rétrograder des Ker- en housename ?<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="transparent" class=""><p class="">
    </p><p class="">Ceci permet de faire fonctionner plus logiquement Nominatim (Cf.
      ticket <a href="https://github.com/openstreetmap/Nominatim/issues/1505" class="">#1505</a>)
      et accessoirement la modélisation proposée afin aussi d'éviter les
      problèmes de représentation des place= en surfacique (on affiche
      au niveau du nœud "centre" s'il existe mais on peut quand même
      avoir en plus une représentation surfacique).</p></div></div></blockquote><br class=""></div><div>On aurait donc des nom de lieu à 2 ou  3 niveaux de technique d’inscription, Il faudra des tutoriels costauds, pour s’y retrouver.</div><div><br class=""></div><div><br class=""></div><div>Christian R.</div></body></html>