[résolu] la recherche marche un peu mieux

Problèmes, bugs et difficultés rencontrés sur le site.
Avatar du membre
yip
Messages : 387
Enregistré le : 08 mars 2004, 23:32

Message par yip »

- j'ai pas trop regardé, mais je vais y jeter un oeil.
Regarde aussi sur Y.RI, j'y ai mis l'option administrative comme l'algo est le même, juste pour tests
Et j'ai déja posté plus haut concernant le style et la cohérence des resultats.
sly a écrit : Pose un message dans les news de la zone vosges ? c'est là qu'il sera vu par les bonnes personnes ;-)
A non, ça n'existe pas encore, mais je la sens bien cette idée.
:laughing:
On a pas de zone Vosges, et à une époque il etait pas prévu qu'on en crée :)
C'est pour faire une zone que j'ai fait ce découpage.
tu vas peut-etre te convertir a cette histoire de zones ;)
sly a écrit : Ha oui, j'avais oublié de te dire, on a ça dans openstreetmap aussi :
http://www.openstreetmap.org/browse/relation/2698607
Mais bon, trop tard...

L'avantage d'une construction collaborative c'est qu'un allemand pourra être plus au fait de savoir si son épine à lui appartient ou pas aux alpes.
yip a écrit :jusqu'a il y a peu, les "Pré-Alpes Suisses" n'etaient pas dans les Alpes. Un partie des Bornes non plus.
OSM n'y peut rien si nos "Préalpes Suisses" ne sont pas dedans.
Ya 2 moyens: tailler les préalpes, ou tailler les Alpes. j'ai choisi de tailler les Alpes.
Avatar du membre
sly
Messages : 5041
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

yip a écrit : tu vas peut-etre te convertir a cette histoire de zones ;)
Je suis déjà acquis à la cause. C'est un des tremplins pour faire de la segmentation pour plus tard.
Avatar du membre
sly
Messages : 5041
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

yip a écrit : Regarde aussi sur Y.RI, j'y ai mis l'option administrative comme l'algo est le même, juste pour tests
J'adore cette idée de présentation en hiérarchie. Ça occupe un peu de place par contre si on a pas mal de résultats, mais peut-être qu'a quelques détails cosmétiques près*, en tout cas c'est idéal pour bien situer.

* Juste des idées : éviter les liens sur les zones, on croit que c'est important, mettre un peu plus en valeur la réponse, gras c'est bien, mais je pense que ça peut être plus lisible encore

Évidement, ~2minutes pour obtenir mes 40 refuges ça le fait pas, mais ça n'est qu'un détail technique et j'imagine bien que la requête qui fait ça doit exister

Pour que tout le monde puisse voir de quoi on parle :
http://yip.refuges.info/point_formulaire_recherche.php
Cliquez administratif (A éviter, temps de calcul très long !)

Quelques remarques sur le formulaire lui même, juste une histoire d'ergnomie, de loin, je préférais l'ancien, mais les avis des autres sont à entendre.
Voilà l'ancien http://sly.refuges.info/point_formulaire_recherche.php pour comparer au nouveau http://yip.refuges.info/point_formulaire_recherche.php

- J'ai un immense écran et ça ne tient pas dans la hauteur, le bouton chercher n'est même pas visible du premier coup d'oeil ! Pas tenable à mon avis au niveau ergonomie, la majorité des gens doit pouvoir tout voir d'un coup (la générosité des margin y est pour beaucoup)

- question de goût forcément, mais ces cadres à toutes les sauces, ça fini par donner une sensation d'être enfermés (même dans l'ancien qui n'en avait pourtant qu'un), pas besoin d'un cadre pour entourer que ça va être un nom, restons simple, le luxe, c'est avoir de l'espace. A mon avis on peut tous les enlever. (de l'eau ? du confort ? oui certes, mais bien avant que ça soit du confort, c'est de l'eau, la case l'indique)

- goût toujours, tes champs input se balladent de droite et de gauche, je préfère l'alignement vertical, comme l'indentation dans le code ;-)

- "utilisable" ? qui irait chercher de l'inutilisable à part des modérateurs (si c'est parce que je suis connecté qu'il apparait, ok par contre)

- quand on est modérateur, on ne peut plus chercher les refuges pour lesquels on ne sait pas s'il y a de l'eau

Bref, je vais plutôt lister ce que j'aime du nouveau : les deux premiers champs nom+type positionné ainsi, j'aime, le tri au choix, abri sommaire est plus clair que "manque un mur".
et c'est tout ;-(

Ce que je n'aime pas dans l'ancien : "la précision du gps" à part pour un modérateur, bof. Le cadre encore un cadre, pas besoin. Non utilisable, même remarque qu'avant. La recherche par coordonnées et autour, franchement, je me demande qui peut bien taper des coordonnées GPS de tête. Le menu des massifs, comme le nouveau d'ailleurs, bien trop long à parcourir. Je me demande si une sélection dynamique en 2 étape : "choisi zone" puis "choisi massif dans zone" ne serait pas plus utilisable.

De manière plus globale, tous les formulaires d'interaction utilisateur ont fait l'objet d'un processus itératif sur le long terme, profitant de nombreux retours utilisateur pour en arriver là. Et sans vouloir dire que chaque pixel a été positionné précisément, je suggère plutôt de ne rien changer, ou alors très peu.
Exemple, tu as retiré la phrase " Tous les champs sont facultatifs." peut être parce que ça te semble logique, mais si elle est arrivée là, c'est qu'on a eu des retours nous indiquant que des gens en sont arrivé à remplir scrupuleusement chaque champs :
place : de 0 à 30
altitude : de 0 à 3000
Nous, développeurs et modérateurs de wri, sommes habitués au comportement du site, on sait assez bien quoi fait quoi et quoi sert à quoi. Mais ça n'est pas toujours le cas des internautes de passage.

En espérant ne pas t'avoir dégouté, mais tu voulais un retour, le voilà ;-)
Avatar du membre
yip
Messages : 387
Enregistré le : 08 mars 2004, 23:32

Message par yip »

En espérant ne pas t'avoir dégouté, mais tu voulais un retour, le voilà ;-)
Pas dégouté, le style et le design, c'est pas ca qui est important. Je referai le formulaire, la liste, c'est pas grave ça. c'est que des Tags.
(j'essaie de suivre les preco W3C pour les formulaires).
Un peu plus de ne pas avoir eu ton retour de specialiste sur le vrai sujet qu'il y a dessous :ordinary:

Ceci dit j'en tiendrai compte et je referai l'ergonomie.
content de voir que t'apprécie le tri par régions.

Alors les questions de fond:

=== les datas ===
La possibilité de trier, bon c'est pas un scoop avec Postgis, ce qui l'est plus c'est la façon dont ça merdoie qui est interessante.
-L'algo qui fait le tri ne sais pas où il doit ranger les polygones,
- certains massifs apparaissent plusieurs fois, a plusieurs endroits, ce qui alourdit la lecture.
-Les Zones/massifs apparaissent en double (Reunion/Corse/Nlle Caled))
-Les cartes Topos viennent au milieu de temps en temps
-Certaines Zones se chevauchent et l'algo fait des mélanges (je pense a Alpes et Alp Occidentales mais aussi a Alpes et Jura-Vosges.
Tout ceci rends l'arborescence plus lourde, et moins facile a lire.
- Et encore c'etait pire, j'ai redimmensionné des zones pour réduire une poignée de cas. Avec PostGis c'est un régal de régler ces problèmes de frontières :mrgreen:

J'ai inclus la categorie administrative pour comparer.
Le meme algo s'en sort comme un chef avec les divisions administratives, Et donne un résultat bien lisible. (Faut etre patient ;) )
En fait ça illustre ma grande passion: comment organiser nos données.
Je pense a ces contraintes :
-un poly devrait se situer intégralement dans le poly parent
-un poly ne devrait si possible n'avoir qu'un seul parent direct
Les réserves et les cartes topos ne respectent pas ces 2 contraintes, et ça gène un peu l'arborescence. mais ça reste gérable, sauf pour la suisse ou les cartes topo se melent au massif.
On peut les sortir de la chaine geographique,
on peut aussi pondre autre chose pour regrouper les données, là c'est le plus basique.

== les perfs==
Au sujet des perfs, j'ai remarqué qu'il n'y avait pas de timeout PG sur des requetes trop longues. hier j'en ai killé une via un sudo kill après 3 heures de CPU au taquet (cpu VM bridé je suppose m'enfin), ces requete interminables etaient lancée par le web comme n'importe quel quidam, pas par le phppgadmin.
Sly connais mieux ça que moi, tous les essais que j'ai fait avec des ST_Simplify etaient systématiquement plus long que sans, ça vient qu'on perd l'indexation ?
Les perfs, si elles sont assez rapide pour le geographique (le seul qui compte ?) risquent d'etre un peu limite si un système d'arbre comme ça est généralisé et appelé à tout va, ou alors faut optimiser les requetes.

Bon voila, si on part la dessus, je peux regarder comment porter l'idée vers les news par exemple
Avatar du membre
sly
Messages : 5041
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

yip a écrit : Un peu plus de ne pas avoir eu ton retour de specialiste sur le vrai sujet qu'il y a dessous :ordinary:
Lesquelles ? celles que tu exposes juste après ?
La possibilité de trier, bon c'est pas un scoop avec Postgis, ce qui l'est plus c'est la façon dont ça merdoie qui est interessante.
-L'algo qui fait le tri ne sais pas où il doit ranger les polygones,
- certains massifs apparaissent plusieurs fois, a plusieurs endroits, ce qui alourdit la lecture.
-Les Zones/massifs apparaissent en double (Reunion/Corse/Nlle Caled))
-Les cartes Topos viennent au milieu de temps en temps
-Certaines Zones se chevauchent et l'algo fait des mélanges (je pense a Alpes et Alp Occidentales mais aussi a Alpes et Jura-Vosges.
Tout ceci rends l'arborescence plus lourde, et moins facile a lire.
Mmmm en effet, exposé ainsi, ça semble pas complètement simple. Je m'étais contenté de regarder ton résultat et dire "c'est chouette" sans réfléchir à la galère qui se trame en dessous.
Ce qui nous ramène à la question des hiérarchies entre zones, ou à des requêtes bien lourdes qui vont déterminer si oui ou non Alpes est "dans" Alpes occidentales ou l'inverse.
Fichtre, je peux me contenter de donner ma langue à mon chat ?
idée en vrac :
- ordonnement par surface et ne prendre que le plus petit polygone d'un type unique.
- calculer la surface de la zone d'intersection et en faire je ne sais quoi ;-)
- Et encore c'etait pire, j'ai redimmensionné des zones pour réduire une poignée de cas. Avec PostGis c'est un régal de régler ces problèmes de frontières :mrgreen:
Que tu corriges les alpes occidentales pour qu'elles soient bien uniquement dans les Alpes, à la limite, c'est un plus pour ces zones, mais ça veut dire que l'algo merdera un jour ou ne pourra pas gérer tous les cas.
Corriger les données pour faire marcher un algo, ça risque de foirer un jour. (Genre, lorsque la classification "montagnarde" inclurera un truc comme "le Bugey" qui ne sera pas arbitraire parce que ça nous arrange, mais parce que culturellement c'est comme ça qu'on l'appel, et que ce bugey, le vrai, intersecte le Jura sans qu'il y soit intégralement inclus)
J'en arrive à me demander : notre volonté de hiérarchiser jura et bugey a-t-elle un sens ?
En fait ça illustre ma grande passion: comment organiser nos données.
Passion à laquelle je rajouterais : peut-on, doit-on, et est-ce systématique ?
ces requete interminables etaient lancée par le web comme n'importe quel quidam, pas par le phppgadmin.
Indirectement, c'est nous qui les avons construites, c'est donc à nous d'éviter qu'elles ne se lancent.
Reste que pour la sécurité du serveur, un kill automatique à ~15minutes ne serait pas de trop.
Sly connais mieux ça que moi, tous les essais que j'ai fait avec des ST_Simplify etaient systématiquement plus long que sans, ça vient qu'on perd l'indexation ?
En règle générale, oui : toute transformation (de coordonnées, de simplification, de géométrie) désactive la possibilité d'utiliser les indexes. Auxquelles il faut rajouter le temps de faire la transformatin elle-même.
Les perfs, si elles sont assez rapide pour le geographique (le seul qui compte ?) risquent d'etre un peu limite si un système d'arbre comme ça est généralisé et appelé à tout va, ou alors faut optimiser les requetes.
Oui et oui.
Mais si on arrive pas l'optimisation, il faut alors accepter de se séparer de l'idée.
Bon voila, si on part la dessus, je peux regarder comment porter l'idée vers les news par exemple
Cette page est très visitée, si on arrive pas à faire quelques chose pour les perfs, je vote niet ou simplification quitte à perdre une fonctionnalité.
En outre, une page de news doit rester courte selon moi, un système avec présentation en hiérarchie comme la recherche n'y serait pas adapté car, contrairement à la recherche où l'internaute à toute les chances de chercher dans un massif donné, ce qui va grouper, pour les news, c'est éparpiller donc ça n'apportera que de l'espace perdu.

En revanche, je soutiens toujours l'idée de pouvoir enregistré un filtre "nouvelles sur $zone" (par session, par préférence utilisateur ou par un menu)
Avatar du membre
yip
Messages : 387
Enregistré le : 08 mars 2004, 23:32

Message par yip »

ou à des requêtes bien lourdes qui vont déterminer si oui ou non Alpes est "dans" Alpes occidentales ou l'inverse.
Que tu corriges les alpes occidentales pour qu'elles soient bien uniquement dans les Alpes
Contrairement a ce que pourrait laisser penser leur nom, il n'y a pas de relation entre les 2.
C'est un non-sens qui peut pas se corriger. c'est comme dire que la Suisse est incluse ou pas, dans la France. Ils sont les deux du même type, il y a rien a faire, rien a corriger.

Ce que j'ai corrigé c'est que j'ai élargi les Alpes(au pif celui la et pas l'autre) aux BornesAravis.
Car comment on gère la partie qui n'y etait pas ?
Mettons qq1 est abonné a tout ce qui se passe sur la zone Alpes (super idée ça, RSS ou cookie).
Il ne connaitrait pas les news d'une partie des Bornes, alors qu'il aurait pu croire, s'etant abonné aux alpes....
Actuellement la question se pose avec les "calanques de Marseille".
Corriger les données pour faire marcher un algo, ça risque de foirer un jour. (Genre, lorsque la classification "montagnarde" inclurera un truc comme "le Bugey" qui ne sera pas arbitraire parce que ça nous arrange, mais parce que culturellement c'est comme ça qu'on l'appel, et que ce bugey, le vrai, intersecte le Jura sans qu'il y soit intégralement inclus)
Le but c'est d'avoir une organisation de donnée qui rende "impossible" les foirage, et de pas avoir a les gerer en code.
C'est la meme difference que mettre un flag DEFAULT sur une colonne SQL, ou la coder a chaque fois a la meme valeur par defaut en PHP.
J'ai corrigé les données pour que les hiérarchies soient claires. Désormais, tout nouveau point créé dans les Bornes, sera dans les Alpes. Le cas d'un point qui est, dedans, mais en fait n'y est pas n'est plus possible, et on a pas a le gerer.
culturellement c'est comme ça qu'on l'appel, et que ce bugey, le vrai, intersecte le Jura sans qu'il y soit intégralement inclus
Ok, on inclut un autre Bugey avec de nouvelles limites car les gens du pays estiment que leur région va de chambery à Besançon.
On inclut aussi un autre Jura car les gens du pays estiment que leur région va de Voreppe à Munich (c'est pas des conneries )

Tu imagines le puzzle sur la carte de la page d'accueil?
Ca peut se resoudre en faisant une categorie particuliere, la categorie "affichage", mais ca va pas dans le sens d'assecher les gouttes...

oui Culturellement, c'est certainement le cas un peu partout. Rien n'est aussi carré que notre découpage. Certains diront que Bellegarde est dans le Bugey, d'autres diront que c'est dans le Jura.
Comment on trie les données ? les points qui sont entre les deux ?
On pond du code, et pas du leger, du code qui fait des choix arbitraires, sur des critères peu fiables comme la surface (mais si on fait une zone "Montagnes Francaises" qui devient comparable en surface a Alpes ?).
pour que les différences culturelles régionales soient respéctées.
En fonctionnalités on y gagne strictement rien.
L'utilisateur aujourd'hui utilise principalement les cartes pour trouver sa cabane. Si c'est un intégriste Jurassien, et qu'en cliquant le Jura il voit qu'on a exclut Bellegarde de son cher pays, il va avoir les boules.
Grand bien lui en fasse, c'est quand meme pas la mission de WRI de contenter tous les égos régionaux. Notre découpage est forcément un compromis. Les gens viennent ici pour le contenu et le découpage n'est pas le but en soi.

Heureusement, on en est pas la ;) Tout est déjà bien hiérarchisé en fait en base, et ça permet de bien bosser.
Tout ca pour dire que je suis pour la suppression de la zone alpes, et son remplacement par une zones "Alpes Orientales/Centrales/Suisses/del'Est"( peu importe le nom) complémentaire
Je trouve pas catastrophique que les "Alpes Occidentales" se retrouvent en bout de chaine, sans rien au dessus.
Si le but est de pas embrouiller les gens avec des zones qui ne les interessent pas, Dire qu'un point est dans les Alpes Occidentales, c'est suffisament explicite même pour un réunionnais.


Oula, je suis encore plus intégriste que d'habitude aujourd'hui, va falloir prendre les cachets bientot ;)

PS: a propos des perfs, +1,on peut laisser tomber si pas de solution. C'est accessoire. +1 le kill automatique.
Avatar du membre
sly
Messages : 5041
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Bon, bon, on va pas trop ce prendre la tête sur des cas hypothétiques du futur,
je propose qu'on attende d'avoir un cas réél, on verra à ce moment là.

Toutefois, je n'arrive pas a voir ou est vraiment le problème d'avoir plein de zones qui se chevauchent ou qui chevauchent des "secteurs" (appelés aujourd'hui massifs) , mais je le découvrirais peut-être à l'usage

La seule contrainte que je vois utile de s'imposer, c'est de faire en sorte que nos "secteurs" (massifs) eux ne se chevauchent pas afin d'obtenir une appartenance à "le secteur principal"