[OSM-talk-fr] Re : Militantisme ?

[Emilie Laffray]

2010/6/4 Pieren <pieren3 at gmail.com>

> 2010/6/4 Emilie Laffray <emilie.laffray at gmail.com>
>
> Je préfère nettement des outils indiquant des changements plus ou moins
>> grands sur une zone en utilisant des règles heuristiques.
>>
>>
> Ca serait un sujet idéal pour un étudiant en recherche de projet...
>
> L'inconvénient majeur des deux outils précédement cités, c'est qu'ils se
> limitent à une petite zone parce qu'on part du principe qu'une seule
> personne s'intéressera à sa propre zone d'intérêt. Malheureusement, ces
> zones ne représentent qu'un faible pourcentage du territoire.
> Ce qu'il faudrait donc, c'est un outil capable de surveiller (monitorer)
> une zone grande comme la France mais en ne montrant que les changements
> dignes d'intéret et en regroupant les autres pour info. J'imagine un rapport
> qui pourrait être généré sur tous les edits de jour précédent sous forme
> d'une page html unique et/ou RSS à disposition de tout un chacun sur un
> serveur.
> Exemples:
> - quelqu'un intervient sur une zone limitée, par ex., trace 20 buildings de
> son quartier : 1. afficher une tuile mapnik surlignant les changeset et 2.
> une liste des tags utilisés sans les détails : avec 1. , on peut voir si
> quelqu'un dessine un bâtiment en forme de b... et pour 2. on voit si les
> tags employés correspondent à ce qui se fait d'habitude; on peut
> éventuellement surligner des tags non courants (ce qui ne veut pas dire que
> c'est automatiquement faux) et réduire les autres sous forme de lien.
> - détecter les robots et mettre leurs contributions dans un rapport séparé
> (mettre en avant les nouveaux bots qui peuvent contenir des erreurs) (sur ce
> point, l'obligation de déclarer les userbots avec un flag particulier serait
> un plus). On peut les détecter lorsqu'ils interviennent rapidement sur de
> grandes distances, ce qu'aucun éditeur pour 'humains' n'est capable de
> faire.
> - détecter les nouveaux en conservant l'historique des auteurs, leur date
> d'apparition et leur nombre d'edits. Toutes les contributions devraient être
> surveillées mais il faut placer en haut de page les nouveaux qui sont les
> plus gros pourvoyeurs de vandalismes (involontaires) et qui sont d'ailleurs
> souvent demandeurs pour qu'on les guide.
> - détecter les mauvaises habitudes par auteur par exemple, ceux qui ne
> connaissent pas les règles typographiques (les abbréviations par ex.) ou qui
> ne joignent pas les ways correctement aux intersections ou qui tracent les
> ronds-points dans le mauvais sens.
>

Oui tout a fait :)
Peut être que si on a des fonds avec l'association OSM, c'est un projet que
nous pourrions lancer!
Ça serait quelque chose de similaire face a un Google Summer Of Code. Je
suis sure que sur un tel projet, la fondation serait prête aussi a financer
un peu. D'ailleurs, je pense que le sujet devrait être discuter sur une
liste plus internationale comme potentiellement la liste "vandalisme" dans
un premier temps.
Parmi les règles que je regardais pour un tel projet, je voyais les règles
suivantes:
- Détection de changement de topologie (via des méthodes de calcul de
similarité géométriques)
  Ça permet de voir un grand changement mais pas d'avoir un gros changement
pour juste un point qui change de quelques mètres
- Règles heuristiques sur le tag name via un calcul de distance texte.
Autrement dit, une correction orthographique ne fera pas vraiment apparaître
de changement, mais changer un name complètement fera apparaître quelque
chose de gros. Par exemple, on pourrait aussi utiliser les règles de
maposmatic pour analyser initialement un name d'un highway pour réduire les
risques d'interférence.
- Règles heuristiques sur l'ajout de tags, et leur disparition. Ça implique
de créer des tables de relations entre les différents tags ou les
combinaisons sont logiques. Je pense qu'une étude statistique sur des
chaînes de Markov pourrait donner ce genre de résultat
- Règles heuristiques sur la modification d'un tag

Ce sont a peu près les règles que je vois pour le moment. Ce n'est qu'un
travail d'ébauche, mais clairement il faudrait que le système se passe d'une
base de données SQL pour des raisons de performance et d'avoir un timeframe
en adéquation avec le temps de processing. Je pense aussi que ça permettrait
aussi potentiellement d'utiliser des threads et/ou des machines distantes
pour exécuter les taches.

Emilie Laffray
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100604/46979edf/attachment.htm>