[OSM-talk-fr] bogues majeurs Osmose déjà signalé, toujours pas de réponse

[Philippe Verdy]

Concernant les nœuds sur lesquels il est impossible de cliquer car dès
qu'on clique dessus, cela affiche une boite d'info qui décale la carte et
recharge les liste des noeuds en rendant invisible celui qu'on a
sélectionné, j'avais suggéré que la recherche des noeuds signalés trouve en
priorité d'abord ceux en bas de la carte affichée avant ceux en haut (un
clic sur ceux du haut va automatiquement faire glisser la carte), et
ensuite de préférence d'abord ceux an centre, puis à droite, puis à gauche
(car une partie est masquée par la boite de sélection des types
d'anomalies).
Actuellement Osmose trouve des nœuds dans un ordre quelconque mais la
plupart du temps d'abord ceux en haut à droite (là où ils ne sont même pas
accessibles en cliquant dessus voire invisibles).

En interne Osmose doit chercher une liste de 200 nœuds maximum dans une
bounding box couvrant tout l'écran (même les parties cachées).
Techniquement il peut sans reconstruire ses index internes sur la base
faire une recherche sur plusieurs bounding boxes en commençant par une
sous-box centrale (il n'ira pas plus loin s'il a déjà obtenu 200 noeuds,
sinon il continuera la liste à concurrence de 200 en cherchant à droite,
puis à gauche, puis en dessous au centre, à droite et à gauche, puis
seulement en haut au centre, à droite et à gauche. Au maximum ça fait 9
requêtes seulement s'il y a peu ou pas de données à retourner. Mais au
moins on arrivera à localiser les objets et cliquer dessus, au moins en
zoomant sur une zone plus petite pour les voir tous.

Idéalement, Osmose devrait trouver les noeuds dans l'ordre des plus proches
du point central de la carte (dans l'ordre croissant de la distance au
centre de carte, mais ça peut pénaliser un peu le traitement car ça demande
un tri, alors qu'actuellement Osmose doit juste utiliser un index en "quad"
avec un ordre retourné arbitraire sans avoir besoin de faire de tri : il
n'utilise qu'une limite en nombre max à 200 et arrête sa requête à ce
point).

De fait de nombreux nœuds signalés ne sont pas visibles du tout : ils
peuvent apparaître à un niveau de zoom et pas moyen même de zoomer dessus
car il disparaissent. C'est très peu pratique d'autant plus qu'il y a
maintenant énormément de faux positifs (récurrents et causés par des bogues
de synchronisation de sa base) qu'on voit mais qui masquent tout le reste à
cause de la limite à 200.

Osmose ne remplit clairement plus son rôle.


Le 28 août 2016 à 21:57, Jérôme Seigneuret <jerome.seigneuret at gmail.com> a
écrit :

> Bon ben voilà tout est dit. C'est les mêmes bugs que je rencontre.
>
> Le 27 août 2016 à 21:34, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> Osmose continue à fournir un permalien incorrect avec les paramètres
>> URL-encodés (notamment la virgule codée "%2C" entre les valeurs de item= ou
>> level=) mais pas reconnus quand on utilise le lien (Osmose ne reconnait que
>> la virgule codée ",") De fait il continue à vouloir afficher la totalité
>> des signalements (tous types et tous niveaux) sans tenir compte de la
>> sélection.
>>
>> Bogue déjà signalé il y a plusieurs semaines, mais aucune réponse.
>>
>> ----
>>
>> Pas de réponse non plus concernant les noeuds affichés qu'on ne peut pas
>> cliquer (cela déplace la carte, pour afficher le détail le noeud disparait
>> aussitôt) et sur lesquels on ne peut pas zoomer non plus (ils ne sont
>> visibles qu'à certains niveaux de zoom)
>>
>> Là aussi déjà signalé et toujours aucune réponse.
>>
>> Ce sont des bogues fonctionnels qui empêchent sérieusement d'utiliser
>> Osmose.
>>
>> ----
>>
>> En plus du fait qu'il y a des signalements fantaisistes sur OSmose, sur
>> des éléments déjà corrigés depuis des semaines et qui réapparaissent: on a
>> beau cliquer sur "faux positif" (quand on peut, voir ci-dessus!), ils
>> réapparaissent le lendemain avec une nouvelle date.
>>
>> Exemple: fragments de frontière isolés, faux le plus souvent : L'analyse
>> des relations est fausse et cela semble indiquer une désynchronisation de
>> la base de données carto d'Osmose
>>
>> Ces cas sont de plus en plus nombreux il serait bon qu'en cas d'anomalie
>> déjà signalée comme faux positif et qui est redétectée le lendemain, Osmose
>> aille relire directement les données des objets concernés depuis OSM pour
>> vérifier si sa base est bien à jour, Osmose doit perdre le fil des "minute
>> diffs" assez souvent pour différentes raisons techniques, qui à la lognue
>> s'aggravent car les versions ne correspondent pas, et ne jamais s'en
>> souvenir : cette resynchronisation "hors diffs" devrait utiliser une file
>> d'attente pour faire des requêtes à la base OSM principale et remettre à
>> jour à la dernière version pour les analyses suivantes; cela permettrait de
>> nettoyer bon nombres de faux signalements sur des choses déjà corrigées ou
>> qui n'ont en fait jamais existé comme anomalies). Ce serait plus simple (et
>> moins long) que de recharger la base monde depuis un snapshot et reprendre
>> tous les diffs depuis ce snapshot.
>>
>> En plus cela doit avoir pour effet de faire grossir énormément la base
>> interne d'anomalies d'Osmose (surtout que maintenant cela porte sur le
>> monde entier) et que les performances doivent en souffrir. L'outil est de
>> moins en moins utilisable avec le temps et ne permet plus de suivre
>> vraiment ce qui se passe avec trop de choses fantaisistes dues à Osmose
>> lui-même ou ses propres problèmes de connexion avec le fil des diffs ou à
>> cause d'erreurs de traitement de certains diffs (qui font ignorer la suite
>> du diff avec un plantage interne ou à cause d'un conflit de version sur un
>> objet non synchronisé dans un diff plus ancien).
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160829/b9f7a722/attachment.htm>