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

[kimaidou]

Bonjour Pieren, les autres

Le 22 avril 2010 17:50, Pieren <pieren3 at gmail.com> a écrit :

> Hmmm, j'ai encore des doutes sur la possibilité de faire cet outil.


Moi aussi , mais le besoin est vraiment là, alors on va trouver les
solutions !

Il faut garder à l'esprit que l'XAPI est plus limité que l'API et que par le
> passé, il a été souvent indisponible sur de longues périodes.


Je ne pense pas que ce soit un argument. Si ce type d'outil grand public est
demandé, il faudra qu'on (nous) trouvions les ressources nécessaires, par
exemple pour mettre en place une xapi dédiée, ou une xapi par pays, etc.
Sur ce point, est ce que quelqu'un sait ou trouver comment installer et
faire fonctionner sa propre xapi ?


> Avec l'XAPI:
> - on ne peut chercher qu'un seul tag par requête
> - on n'a pas accès à l'historique
> - je ne crois pas qu'on puisse accéder aux objets par leur id
>
> Pour les deux derniers points, il faudra donc passer par l'API normale, ce
> qui n'est pas anodin comme décision. Les admins ont déjà bloqué des IP pour
> utilisation abusive de l'API. Et il a été à chaque fois précisé que l'API
> est à disposition pour éditer les données, pas pour autre chose. Les
> applications qui ont besoin des données en lecture seule sont
> systématiquement orientées vers les planet dump. Mais évidemment, les dump
> ne contiennent pas les historiques.
>

Pour l'historique, ce n'est peut-être pas si grave.
J'enregistre en local la version de l'objet, je compare à la version
actuelle, je donne juste un lien vers la page osm.org décrivant l'objet, la
personne utilisera les outils en ligne s'il veut voir tout l'historique.

C'est vrai que ce n'est pas anodin, car alors je ne pourrais pas proposer la
fonctionnalité "suivre tous les objets pour lesquels j'ai fait au moins une
édition. En effet comme tu dis plus loin, c'est très gourmand pour l'api.
Tant pis, on pourra trouver un autre moyen peut-être.

>
> Si tu surveilles uniquement une certaine liste de tags, le nombre de
> requêtes s'allongera proportionnellement à la taille de la liste.
>

Entièrement d'accord aussi, ce point n'est pas non plus anodin, mais encore
une fois je crois que ce n'est pas l'outil qui est responsable, mais la
personne qui l'utilise. Par exemple un utilisateur bête pourrait très bien
ouvrir 20 fenêtres Firefox et lancer 20 export ou 30 requêtes xapi en même
temps, autant de fois qu'il le souhaite. La seule différente dans ce cas
c'est que l'utilisateur peut contrôler le nombre de bêtises qu'il fait.
Pour le responsabiliser dans l'utilisation de l'outil, on pourrait penser
mettre des règles pour contrôler le nombre de requête avant de les envoyer,
et alors prévenir l'utilisateur "Vous allez lancer 40 requêtes couteuses
pour la xapi, ce qui n'est pas permis par cet outil, merci de sélectionner
moins de tags à suivre/une bbox plus petite, etc."


> Si tu surveilles des objets par auteur, tu ne peux utiliser l'XAPI que pour
> ceux dont tu es le dernier auteur. Après modif par quelqu'un d'autre, c'est
> perdu via l'XAPI, il faudra revenir à l'API et faire une requête pour chaque
> élément si tu as conservé les osm-id auparavant. S'ils sont effacés, tu
> risques de faire des requêtes inutiles. Et l'expérience montre que des
> requêtes par élément individuel est extrêmement long. Si ta zone est
> importante, tu seras rapidement repéré par les admins.
>

Je suis conscient de tout cela. Et en effet la seule manière de faire était
de parcourir tous les objets un par un avec l'api pour chercher si
l'utilisateur avait modifié l'objet dans son historique. Je connais bien les
limitations des 2 api et xapi.
Si on veut éviter ceci, il faudrait donc s'orienter sur le téléchargement
des dump, diffs, etc pour ne pas utiliser l'api.

Bon, je suis responsable et mesuré, je ne vais donc pas offrir à n'importe
qui un outil qui pourrait faire exploser les serveurs d'OSM. Néanmoins, je
trouve cela très dommage d'être ainsi limité. Avoir une api/xapi qu'on ne
peut pas utiliser, c'est comme avoir un couteau non aiguisé: c'est joli mais
frustrant.


>
> La piste des planet diff est sans doute plus intéressante mais si tu ne
> veux pas perdre l'historique, il faudra traiter tous les diffs-files et le
> faire par bbox (une ou plusieurs si j'ai bien compris). Encore une fois, sur
> un pc qu'on allume de temps en temps, c'est pas anodin comme traitement.
> Bref, l'idée est bonne mais j'attend de voir.
>

Tu as rassemblé dans ce mail tous les obstacles que j'avais déjà rencontré
en codant mon bout de soft, et comme tu vois je ne pars pas à l'aveuglette,
mais je cherche des solutions. C'est notamment ce qui a motivé mon annonce
ici.

Bref il reste du  boulot :)

Kimaidou



> Pieren
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100424/c012e913/attachment.htm>