<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 19 mai 2014 11:38, 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">
2014-05-17 0:36 GMT+02:00 Christian Quest <<a href="mailto:cquest@openstreetmap.fr">cquest@openstreetmap.fr</a>>:<br>
<div class=""><br>
> 1) pour tout ce qui est calcul d'itinéraires et positionnement de données<br>
> opendata ne contenant qu'une adresse on va très très prochainement pouvoir<br>
> géocoder en s'appuyant sur BANO<br>
<br>
</div>Je ne suis pas très à l'aise vis à vis de ce projet. D'un côté, je<br>
comprend l'envie d'aller vite et d'offrir une base adresse<br>
s'affranchissant des contraintes de l'import dans OSM. C'est aussi à<br>
cette tentation qu'à céder mapbox en créant le projet "openaddresses"<br>
([1]), en voulant s'affranchir, lui, des problèmes de licences.</blockquote><div><br></div><div>Non, <a href="http://openaddresses.io">openaddresses.io</a> ne s'affranchit pas des "problèmes" de licence.</div>
<div><a href="http://openaddresses.io">openaddresses.io</a> n'est qu'un catalogue, qui répertorie les sources d'adresses. Ce catalogue est en CC0 (il me semble), mais les données des différents dataset ont chacun leur licence propre.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ca<br>
nous fait donc déjà deux bases adresses "libres".<br></blockquote><div><br></div><div>Pareil... <a href="http://openadresses.io">openadresses.io</a> ne contient aucune adresse, juste la liste des fichiers adresses disponibles ic ou là (comme ceux de BANO).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On voit bien où ça nous mène : un fork des données avec des outils qui<br>
seront obligés de jongler avec plusieurs bases (OSM pour la navigation<br>
et bano pour le géocodage, par exemple). C'est exactement contre ça<br>
qu'OSM a été créer : ne plus avoir à chercher à gauche et à droite<br>
voir qui fait quoi, qui fait le mieux et comment et avec quelle<br>
license pour travailler avec des données géographiques mais avoir le<br>
tout centralisé dans une seule base (et aussi pour les mises à jour).<br></blockquote><div><br></div><div><br></div><div>Il n'est pas possible de mettre à jour BANO autrement que via OSM.</div><div>Le problème des mise à jour parallèles n'est donc pas un problème pour BANO.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Donc "hourra pour bano" si ça sert à accélerer l'intégration des<br>
adresses dans OSM. Mais "bof" si ça devient une solution pérenne pour<br>
compenser nos faiblesses comme dans la modélisation ou les contraintes<br>
de l'import (et qu'il vaudrait mieux surmonter).<br></blockquote><div><br></div><div><br></div><div>Bien sûr qu'il faut les surmonter et rapidement... pour permettre l'amélioration des données OSM et par ricochet de BANO.</div>
<div>L'idée est vraiment de faire d'une pierre deux coups. </div></div><div class="gmail_extra"><br></div>L'intérêt est surtout d'avoir une base d'adresses utilisable immédiatement, en complément d'OSM, pour aider à compléter OSM.</div>
<div class="gmail_extra">Ca évite qu'on se rue bêtement sur les adresses pour les importer à la va-vite dans OSM (je l'ai fait dans quelques communes et en fait ma valeur ajoutée a été très limitée) pour atteindre une masse critique nécessaire à beaucoup d'usages sans apporter grand chose en terme de qualité, de contrôle de terrain et autre.</div>
<div class="gmail_extra"><div><br></div>-- <br><div dir="ltr">Christian Quest - OpenStreetMap France</div>
</div></div>