Merci pour les retours Sly !<br>Mes remarques :<br><br><div class="gmail_quote">Le 22 avril 2010 14:58, sly (sylvain letuffe) <span dir="ltr"><<a href="mailto:sylvain@letuffe.org">sylvain@letuffe.org</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On jeudi 22 avril 2010, kimaidou wrote:<br>
<br>
> Pour l'instant, c'est encore un embryon, mais les fonctionnalités basiques<br>
> sont à peu près en place, et donc j'en parle ici pour qu'on ne soit pas<br>
> plusieurs à faire un outil équivalent dans notre coin, mais pour rassembler<br>
> les bonnes volontés.<br>
<br>
</div>J'ai moi aussi eu l'ambition de créer un truc dans ce goût là, je trouve que<br>
ça manque cruellement. Mais j'ai pas encore eu le temps de taper la moindre<br>
ligne de code juste gemberger. Donc en gros ça sert pas à grand chose ;-)<br>
<br>
Je commentes tout de même histoire de faire mon chieur</blockquote><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> * Choix d'une ou plusieurs zones (bbox)<br>
> La taille de chaque bbox doit rester pas trop grande (limites de l'api et de<br>
> la xapi, cf description technique + loin)<br>
</div>Alors là, à mon avis, ça va être très limité. En bbox, même si xapi va plus<br>
loin que l'api standard ça reste très limité en surface et tu va te retrouver<br>
si ça monte en puissance avec des utilisateurs qui vont créer plein plein de<br>
bbox.<br></blockquote><div><br>Mon outil est vraiment "pensé" pour être utilisé par un utilisateur comme il pourrait utiliser le bouton "export" de <a href="http://osm.org">osm.org</a>.<br>J'avais dans l'optique un outil qui serait utilisé au niveau d'une commune, pas d'un pays entier. Je pense alors que les tailles limites des bbox liées aux api sont correctes.<br>
<br>Dans le cas ou un utilisateur est très gourmand (je veux contrôler le monde), c'est son problème.  S'il se fait bloquer parce qu'il envoit trop de bbox trop souvent, c'est que c'est outil ne lui est pas dédié et que justment il doit lui même mettre en place un outil plus lourd basé sur un serveur, les diffs, et compagnie.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Et soit chacun son installation mais j'y crois pas, python c'est pas clic clic<br>
next next, et même si tu utilises les mécanismes de python executable sous<br>
windows c'est pas un truc que chaque utilisateur va laisser tourner en<br>
permanence pour faire le suivi.<br></blockquote><div><br>Je suis pas d'accord, j'ai déjà créé des petites applications "clic clic next next" installable facilement sous windows ou nunux en python, et utilisables à la souris.<br>
<br>Je ne vois pas cet outil comme un truc qu'on fait tourner en permanence, mais qu'on fait tourner une fois par jour par exemple. Mais je ne vois pas en quoi ce ne serait pas possible de le faire en python si besoin<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Donc, l'avenir me semble obligatoirement coté webservice :<br>
Tu mets ton mail, tu choisi ton flux rss et roule ça fait tout tout seul et ça<br>
te prévient quand quelqu'un à supprimé les 500 bâtiments que tu venais de<br>
rentrer<br></blockquote><div><br>C'est justement la logique inverse de ce que je voulais faire. Je veux responsabiliser l'utilisateur de l'outil. Je lui donne un petit couteau, et il l'utilise quand il en a besoin.<br>
Je ne lui donne pas un F16 avec des missiles nucléaires.<br>Je préfère que pour le serveur OSM et les api, ce soit chaque utilisateur qui envoit depuis son outil des requêtes, et non un mega serveur qui aurait de plus en plus d'utilisateurs. C'est possible bien sûr, mais demande du temps, des ressources, de la maintenance, etc.<br>
<br>Bien sûr j'entends les critiques "oui mais tu reportes la charge sur <a href="http://osm.org">osm.org</a>". Je ne pense pas car je fais confiance à l'utilisateur. Cela fait longtemps qu'il est possible pour les programmeurs de faire des traitements en masses et des requêtes en masse sur Osm via les api, mais chacun est raisonnable et on n'a pas vu torp de débordements.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Et dans un cas de ce type, ton serveur va se faire bannir rapidos s'il doit<br>
télécharger tout osm par Xapi chaque semaine !<br></blockquote><div><br>Il est trop gourmand :)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
> Fonctionnement<br>
> ***********<br>
(...)<br>
<div class="im">> * il compare cette liste d'objet à celle obtenue lors de la dernière passe<br>
</div>Brrrrr...<br>
Et la zone qui n'a pas bougée en 6 mois, l'outil va aller la chercher chaque<br>
nuit pour rien ?<br>
C'est trop bête, <a href="http://planet.openstreetmap.org" target="_blank">planet.openstreetmap.org</a> propose chaque minute les objets qui<br>
ont été changés, il "suffirait" de les comparer à une liste de suivi et de<br>
créer l'alerte <br></blockquote><div><br>Cette idée est intéressante et mérite d'être creusée. Cela pourrait limiter les requêtes api et alléger le travail des serveurs osm<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
<br>
> Je cherche ici à faire un outil léger et portable, qu'on puisse lancer d'une<br>
> simple clé USB.<br>
</div>De toute façon il lui faut le net ! Autant déporter le calcul pour être<br>
utilisable avec un simple navigateur. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Néanmoins, j'apprécie ton principe de<br>

rechercher l'autonomie, mais au lieu de dépendre d'un webservice "suivi" tu<br>
dépend du webservice "xapi"<br></blockquote><div><br>J'ai bien sûr aussi eu ces interrogations "web service php/postgis ou outil local python via api", et je n'ai pas encore vraiment tranché, même si tu vois où mon coeur balance.<br>
Un serveur veut tout de suite dire maintenant lourde, sécurité, contrôle des utilisateurs, ressources, bande passante, etc.<br><br>Je me dit que si de plus en plus de personnes utilisent la xapi et l'api, on trouvera des solutions pour faire des api/xapi locales (par exemple une par pays) pour répartir la charge.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
sly, le rabas joie<br></blockquote><div> </div><div>Kimaidou, l'abat-jour <br></div></div>