[OSM-talk-fr] [dev] OsmWatch : outil pour voir les modifications/ajouts/suprression d'un ensemble d'objets

kimaidou kimaidou at gmail.com
Jeu 22 Avr 14:20:03 UTC 2010


Merci pour les retours Sly !
Mes remarques :

Le 22 avril 2010 14:58, sly (sylvain letuffe) <sylvain at letuffe.org> a écrit
:

> On jeudi 22 avril 2010, kimaidou wrote:
>
> > Pour l'instant, c'est encore un embryon, mais les fonctionnalités
> basiques
> > sont à peu près en place, et donc j'en parle ici pour qu'on ne soit pas
> > plusieurs à faire un outil équivalent dans notre coin, mais pour
> rassembler
> > les bonnes volontés.
>
> J'ai moi aussi eu l'ambition de créer un truc dans ce goût là, je trouve
> que
> ça manque cruellement. Mais j'ai pas encore eu le temps de taper la moindre
> ligne de code juste gemberger. Donc en gros ça sert pas à grand chose ;-)
>
> Je commentes tout de même histoire de faire mon chieur



> > * Choix d'une ou plusieurs zones (bbox)
> > La taille de chaque bbox doit rester pas trop grande (limites de l'api et
> de
> > la xapi, cf description technique + loin)
> Alors là, à mon avis, ça va être très limité. En bbox, même si xapi va plus
> loin que l'api standard ça reste très limité en surface et tu va te
> retrouver
> si ça monte en puissance avec des utilisateurs qui vont créer plein plein
> de
> bbox.
>

Mon outil est vraiment "pensé" pour être utilisé par un utilisateur comme il
pourrait utiliser le bouton "export" de osm.org.
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.

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.


> Et soit chacun son installation mais j'y crois pas, python c'est pas clic
> clic
> next next, et même si tu utilises les mécanismes de python executable sous
> windows c'est pas un truc que chaque utilisateur va laisser tourner en
> permanence pour faire le suivi.
>

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.

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


>
> Donc, l'avenir me semble obligatoirement coté webservice :
> Tu mets ton mail, tu choisi ton flux rss et roule ça fait tout tout seul et
> ça
> te prévient quand quelqu'un à supprimé les 500 bâtiments que tu venais de
> rentrer
>

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.
Je ne lui donne pas un F16 avec des missiles nucléaires.
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.

Bien sûr j'entends les critiques "oui mais tu reportes la charge sur osm.org".
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.


>
> Et dans un cas de ce type, ton serveur va se faire bannir rapidos s'il doit
> télécharger tout osm par Xapi chaque semaine !
>

Il est trop gourmand :)


> > Fonctionnement
> > ***********
> (...)
> > * il compare cette liste d'objet à celle obtenue lors de la dernière
> passe
> Brrrrr...
> Et la zone qui n'a pas bougée en 6 mois, l'outil va aller la chercher
> chaque
> nuit pour rien ?
> C'est trop bête, planet.openstreetmap.org propose chaque minute les objets
> qui
> ont été changés, il "suffirait" de les comparer à une liste de suivi et de
> créer l'alerte
>

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


>
> > Je cherche ici à faire un outil léger et portable, qu'on puisse lancer
> d'une
> > simple clé USB.
> De toute façon il lui faut le net ! Autant déporter le calcul pour être
> utilisable avec un simple navigateur.

Néanmoins, j'apprécie ton principe de
> rechercher l'autonomie, mais au lieu de dépendre d'un webservice "suivi" tu
> dépend du webservice "xapi"
>

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.
Un serveur veut tout de suite dire maintenant lourde, sécurité, contrôle des
utilisateurs, ressources, bande passante, etc.

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.

>
> sly, le rabas joie
>

Kimaidou, l'abat-jour
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100422/4bed19c9/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr