<div class="gmail_quote">2010/7/20 Benoît ROUSSEAU <span dir="ltr"><<a href="mailto:adressepossible@free.fr">adressepossible@free.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  
  

<div bgcolor="#ffffff" text="#000000">
Dans le même ordre d'idée, trouves-tu alors normal d'avoir à calculer
l'inclusion en temps réel de POI services (beaucoup plus couteux en
temps) où places-tu les POI sur le way des bâtiments y compris pour
ceux inclus (restaurant dans ton exemple).<br>
<br></div></blockquote><div><br>Les POI peuvent être sur le way du bâtiment, sur un node attaché au way ou un node à l'intérieur du polygone. Tous les cas de figures sont possibles puisque personne n'est forcé d'en respecté un en particulier. Mais la plupart des contributeurs vont utiliser le polygone comme point de repère ("mon boulanger se trouve dans ce bâtiment-là"). Il faut donc pouvoir lier ce polygone avec son adresse avec le moins de doute possible, en y mettant les tags adresses soit sur le way, soit sur un node, peu importe.<br>
</div></div>Je n'ai pas compris ta question sur l'inclusion de POI services. Mais si tu parles de mon exemple de liste des pharmacies d'une ville, ça devrait pouvoir se faire dans un prétraitement automatique et non en temps réel (mais pourquoi pas). Si les adresses ne sont pas liées aux POIs à travers le polygone du bâti, cela devient plus compliqué et plus incertain pour tous ceux qui voudront exploiter ces adresses dans le futur (avec des résultats qui pourront varier d'une appli à l'autre). Il restera toujours les cas plus complexes comme celui que tu cites qui nécessiteront probablement d'avoir le tag addr sur chaque POI (une pratique qu'il faudrait réserver à ce genre de cas). Mais ces cas seront ultra-minoritaires.<br>
<br>Pieren<br>