<div dir="ltr"><div>A ce jour le contributeur ne m'a toujours pas répondu et je lui avait simplement demandé si il avait demandé si il avait besoin des données présente et si il était possible de fusionner les landuse.<br>

<br></div>N'hésitez pas à prendre le relais, je ne souhaite pas le relancer <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 31 mars 2013 13:57, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/3/29 <a href="mailto:arnaud.sig@gmail.com" target="_blank">arnaud.sig@gmail.com</a> <span dir="ltr"><<a href="mailto:arnaud.sig@gmail.com" target="_blank">arnaud.sig@gmail.com</a>></span><div class="im">

<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>C'est évident que l'utilisation de ce tag n'est pas le plus
      approprié...<br>
      Mais de là à supprimer les données patiemment tracées.<br>
      Comme le suggère kimaidou, il faudrait peut être partir sur
      l'utilisation d'un tag plus approprié plutôt que fusionner les
      données et les perdre.<span><font color="#888888"><br></font></span></div></div></blockquote><div><br></div></div><div>Ca n'est pas qu'un problème de mauvais tag. Il faut aussi se poser la question de l'intérêt d'un tel import, même si on avait l'autorisation de le faire de la DGFiP. Plusieurs points:<br>


</div><div>- il y a encore un énorme problème de cohérence géométrique entre communes qui fait qu'il y a très souvent des espaces vides ou au contraire des communes qui se superposent aux frontières. Tous ceux qui ont importés des limites communales savent de quoi je parle. Si on peut s'accommoder d'approximations de quelques mètres ou dizaines de mètres pour les limites (conflation), ça ne fonctionne évidemment plus pour le niveau parcellaire.<br>


</div><div>- tous les jours, des milliers de parcelles sont divisées ou fusionnées au gré d'aquisitions, partages, ventes. Le parcellaire change aussi vite, voir plus, que le bâti. Bâti que nous sommes déjà incapables de tenir à jour correctement.<br>


- le découpage parcellaire ne correspond pas au découpage visible sur le terrain. Il est courant qu'une propriété "individuelle" soit composée de plusieurs parcelles. Si on peut souvent faire correspondre des éléments du terrain sur le découpage cadastral comme les murs, les haies et tout ce qui sert à fixer son pré carré, la plupart des limites parcellaires ne correspondront à rien.<br>


</div><div>- la surcharge pour les éditeurs n'est pas négligeable. En plus des polygones des bâtiments et des landuse, on verra un troisière ensemble de polygones qui s'entrelaceront avec les autres. Les éditeurs actuels d'OSM ne sont pas capables de gérer ces couches de données (même avec le filtrage de JOSM qui a ses limites) et cela rendra l'édition des données tout simplement inabordable pour le commun des contributeurs.<br>


<br></div><div>Bref, importer le parcellaire est le meilleur moyen de tuer les nouvelles contributions sur une zone.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>

Pieren<br></div></font></span></div></div></div>
<br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>