[corrigé] Affichage des points

[Claude Mauguier]

Mmmmouiiiii... cache vidé ; la chose a l'air mieux, mais il n'empêche qu'en déplaçant la carte l'échantillon des points présents (théoriquement toujours dans le cadre de référence) en fait "s'éteindre" certains, tandis que d'autres "s'allument"... c'est tout zoli : on dirait un sapin de Noël...

[Dominique]

Quand il y a trop de points sélectionnés, pour ne pas ramer, le système se défend en ne les affichant pas tous (aléatoirement)

Pour éviter l'effet arbre de noël, il faut zoomer sur une surface plus petite contenant moins de points affichables

[yip]

Quand il y a trop de points sélectionnés, pour ne pas ramer, le système se défend en ne les affichant pas tous (aléatoirement)

la fonction infos_point renvoie maintenant un champs "distance" par rapport au centre de la geometrie.

Tu peux faire un " ORDER BY distance " dans les $conditions au lieu de "Order By point_type.importance"
Si tu veux t'en servir.
Comme ça quand il y a trop de points, ils seront au moins groupés au milieu et ça fera moins Noel.

Si oui, ça permettrait de virer la jointure avec point_type dans cette fonction.
cette jointure ne sert uniquement qu'à l'ORDER BY.
J'ai déja viré 2 autres jointures inutiles (precision_gps et point_type) et j'ai l'impression que ça marche un peu mieux (pas dans le git).
.

[sly]

Quand il y a trop de points sélectionnés, pour ne pas ramer, le système se défend en ne les affichant pas tous (aléatoirement)

la fonction infos_point renvoie maintenant un champs "distance" par rapport au centre de la geometrie.

Tu peux faire un " ORDER BY distance " dans les $conditions au lieu de "Order By point_type.importance"
Si tu veux t'en servir.
Comme ça quand il y a trop de points, ils seront au moins groupés au milieu et ça fera moins Noel.

- Calcul de la distance du point au centre de la bbox : Cette opération est forcément un peu plus lourde que si on avait pas à la calculer, j'avais donc modifié le code pour que l'on puisse la demander uniquement quand c'est vraiment utile (les points à proximité d'un autre), mais par exemple dans le cas de l'affichage par OL sur une bbox car ça ne nous sert pas forcément. Mais ma modif est semble-t-il passée à la trappe suite à une bagarre de yip avec git visiblement :
https://github.com/sletuffe/www.refuges ... 7caa1aab5e
C'est pas bien, grave, si on la veut, je peux la refaire

- La question est donc : la veut-on. Je pense qu'entre ordonner par distance au centre, ou ordonner par la catégorie de point, moi je préfère par catégorie (je préfère que s'affiche la maximum de cabane dans la limite imposé, que d'avoir à afficher arbitrairement au centre), quoi que l'on choisissent de toute façon, ça fera bizarre à l'affichage puisqu'il n'y a pas tout. Je pense que s'il est possible, (je l'ignore) d'avoir un message "seul 120 points ont été affichés, zoomez pour les voir tous" me semblerait bien utile pour expliquer ce qui se passe.

[Claude Mauguier]

Je pense que s'il est possible, (je l'ignore) d'avoir un message "seul 120 points ont été affichés, zoomez pour les voir tous" me semblerait bien utile pour expliquer ce qui se passe.

Tout à fait.

[Dominique]

- La question est donc : la veut-on. Je pense qu'entre ordonner par distance au centre, ou ordonner par la catégorie de point, moi je préfère par catégorie (je préfère que s'affiche la maximum de cabane dans la limite imposé, que d'avoir à afficher arbitrairement au centre), quoi que l'on choisissent de toute façon, ça fera bizarre à l'affichage puisqu'il n'y a pas tout. Je pense que s'il est possible, (je l'ignore) d'avoir un message "seul 120 points ont été affichés, zoomez pour les voir tous" me semblerait bien utile pour expliquer ce qui se passe.

Plutôt d'accord

[yip]

Désolé c'etait pas volontaire. git pull supprime tout quand on fait pas de commit avant, j'ai repris des anciens backup et pouf.

[sly]

Désolé c'etait pas volontaire. git pull supprime tout quand on fait pas de commit avant, j'ai repris des anciens backup et pouf.

Y'a pas grand mal, tout ce que j'ai fais est toujours dans l'historique.

ça y est, je comprends mieux, tu as une copie à coté de l'arborescence wri et de temps en temps (quand c'est la pagaille avec git) tu vas récupérer un fichier du backup et tu écrases.

ça explique les trucs bizarre ou github dit que tu as tout effacé et tout remis (ça fait qu'on perd un peu pied avec le changement réél qu'il y a eu)
genre là : https://github.com/sletuffe/www.refuges ... 7caa1aab5e
(On voit bien "juste la modif" dans exportations/exportations.php alors que dans exportations/formulaire_exportations.php ça fait un gros bloc rouge et un gros bloc vert)

git, on va finir par y arriver, normalement, avec un peu plus l'habitude, y'a pas besoin de maintenir une copie des fichiers à coté, tout est là dans le dossier .git c'est juste le temps de s'y faire :

toujours un "git pul"l avant toute modif de code (sinon ça fait des merges qui peuvent mal se passer)
toujours un "git commit -a" une fois qu'on a fini, même si notre truc est dans un état bancal

et enfin, un "git push" quand on a atteint un certain état de stabilité, qui ,si on passe en prod, ne cassera rien d'important.

perso, j'aime bien bosser par session de ~1h ou je passe d'un état qui marche à un autre état qui marche ça réduit le temps ou l'un de vous pourrait faire une modif entre temps quoi pourrait occassionner des bizarreries
et là, je fais bien "pull, commit, push" dans ce lapse de 1h

Si jamais tu revois une "pagaille" à la limite, demandes moi, et je verrais quelle commande il te manque pour gérer le truc

[yip]

le prochain git pull va etre epique en terme de conflicts ...

Alors fais bien un commit d'abord de tes changements, et ensuite un git pull, sinon il va gueuler que le truc va écraser ta version locale

[sly]

faudrait faire plein de git commit/git pull, mais pas de push ?

Exact !

le "git commit -a" ne va faire qu'un enregistrement local dans ta version à toi.

Perso, je fais un "git commit -a" presque à chaque que je touche un truc qui constitue un "tout", et je fais un git pull très très régulièrement.

Par contre, il m'arrive d'attendre 2/3 jours avant de faire le push, mais j'évite si je peux de trop attendre pour que vous puissiez vous aussi avoir mes modifs, même si le risque de conflit est faible, je peux avoir changer l'appel à une fonction que vous aller utiliser dans son ancienne version alors que j'ai changé justement

[Dominique]

Je fais:
- pull (en général sur une base vide)
- modifs
- pull (et je regarde les merge)
- commit
Le tout par modif (2~3h max)

Je ne connais pas push

Note : je fais mon GIT sur XP/Tortoise avec FTP <-> la MV
Chacune de ces opérations nécessite 1 click dans l'explorateur et rien au clavier
(je suis allergique aux incantations unixiènnes)

[yip]

tortoise doit faire plus qu'il ne dit.

Je fais:
- pull (en général sur une base vide)
- modifs
- pull (et je regarde les merge)

A ce moment là toutes les modifs sont supprimees pour moi.
le nouveau pull a écrasé les modifs.

Franchement je sais pas comment vous arrivez a passer d'un etat stable a un autre etat stable en qq heures

[Dominique]

Franchement je sais pas comment vous arrivez a passer d'un etat stable a un autre etat stable en qq heures

ça marche sur de toutes petites modifs !

[Dominique]

A ce moment là toutes les modifs sont supprimees pour moi.
le nouveau pull a écrasé les modifs.

Ben non: c'est là qu'il propose des merges
Ceci dit, ne pas attendre de miracles sur les merges
Si 2 ont tout modifié, ça se terminera mal !

Note pour les grosses modifs: il existe des lock/unlock par fichier, seule possibilité pour ne pas se marcher sur les pieds

[Claude Mauguier]

Franchement je sais pas comment vous arrivez a passer d'un etat stable a un autre etat stable en qq heures

ça, à force de se payer des "murges", ils ont l'entrainement... (doivent carburer au 60° minimum... calva ?) alors avec la Kro, même s'ils se virent la jointure et glissent dans la merge, c'est de la bibine. (y a pas de smiley "ivrogne")