Evolution de Leaflet

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: :laughing: :blue: :excl: :ours: :ordinary: :mouton: :forb:
Voir plus de smileys

Les BBCodes sont activés
[img] est activé
[flash] est désactivé
[url] est activé
Les smileys sont activés

Revue du sujet
   

Étendre la vue Revue du sujet : Evolution de Leaflet

par Dominique » 14 févr. 2016, 15:51

Claude Mauguier a écrit :Je constate en tout cas un progrès, dans la mesure où, lorsqu'on appelait la carte d'un massif, qu'on zoomait afin d'y voir plus clair, puis qu'on choisissait un point, enfin qu'on décidait ensuite de revenir en arrière pour retrouver la carte, celle-ci demeurait telle qu'on l'avait laissée, c'est à dire avec le même degré de zoom. Auparavant, on retombait sur la carte générale du massif et il fallait rezoomer afin de sortir du grouillement de points rassemblés sur une petite surface. Déjà un bon point ! :wink:
C'est la seule évolution visible :)
En effet, on avait ça il y a quelques années avec OpenLayers et je tenais à le restituer dans Leaflet.
ça fluidifie beaucoup la lecture du site.
On pointe sur l'icône "refuge" et apparait au même niveau l'icône "cabane". Bon, ça existait peut-être avant...?
ça existait avant :)

par Claude Mauguier » 14 févr. 2016, 15:37

Dominique a écrit :Comme il n'y a pas de remarque, j'ai passé les modifs en prod.
Signalez moi tout problème de carte.
Je constate en tout cas un progrès, dans la mesure où, lorsqu'on appelait la carte d'un massif, qu'on zoomait afin d'y voir plus clair, puis qu'on choisissait un point, enfin qu'on décidait ensuite de revenir en arrière pour retrouver la carte, celle-ci demeurait telle qu'on l'avait laissée, c'est à dire avec le même degré de zoom. Auparavant, on retombait sur la carte générale du massif et il fallait rezoomer afin de sortir du grouillement de points rassemblés sur une petite surface. Déjà un bon point ! :wink:
Autre bon point : les points doubles (genre refuge gardé + abri non gardé au même endroit), exemple La Combe (Bauges). On pointe sur l'icône "refuge" et apparait au même niveau l'icône "cabane". Bon, ça existait peut-être avant...?

par Dominique » 14 févr. 2016, 13:29

Comme il n'y a pas de remarque, j'ai passé les modifs en prod.
Signalez moi tout problème de carte.

par Dominique » 11 févr. 2016, 22:36

sly a écrit :et tu envoi par ftp sur dom.refuges.info pour tester, mais sans faire ssh+git pull ?

Mais si tu as des question sur comment de simplifier la vie avec git, demandes moi
Tout à fait. Mais ne t’inquiète pas: j'ai juste la flemme de créer une branche à chaque fois que je fais une modif d'envergure.
De toute façon, 99% du code sur lequel je travaille est sur https://github.com/Dominique92 (je ne copie sur WRI que le /dist compressé de ma lib leaflet)


Dominique a écrit : Donc ta remarque sur www est intéressante (j'ai pu vérifier que j'avais corrigé sur dom) mais n'est pas représentative de la validation qui est uniquement dispo sur dom.
Bigre, encore une phrase qui m'a perdu.
Je voulais juste dire: la version à tester est uniquement sur http://dom.refuges.info

Maintenant, si personne n'a de remarque, je balance sur GIT & WRI
C'est juste que j'ai touché beaucoup de choses et que ça risque d'être instable 2/3 jours.

par sly » 11 févr. 2016, 21:31

Dominique a écrit : Je gère la branche en local chez moi (et je ferai le merge à la main) :oops:
Tu peux aussi faire le "push" depuis chez toi non ? ha ou alors, comme tu ne fais pas une synchro "git pull" régulièrement, tu as, chez toi, une version désynchronisée qui n'inclue pas les modif de moi et léo ?
et tu envoi par ftp sur dom.refuges.info pour tester, mais sans faire ssh+git pull ?

Donc ta remarque sur www est intéressante (j'ai pu vérifier que j'avais corrigé sur dom) mais n'est pas représentative de la validation qui est uniquement dispo sur dom.
Bigre, encore une phrase qui m'a perdu.
Mais je vais dire que tant que ça te convient et que ça n'écrase pas les modifs des autres, moi ça me va.
Mais si tu as des question sur comment de simplifier la vie avec git, demandes moi

par Dominique » 11 févr. 2016, 21:23

sly a écrit :
Dominique a écrit : Attention: je n'ai pas archivé GIT ni WRI le nouveau code à tester !
je n'ai pas compris cette phrase ? tu n'as pas fait un push de tes modifs c'est ça ?
Tout à fait.
Je gère la branche en local chez moi (et je ferai le merge à la main) :oops:
Donc ta remarque sur www est intéressante (j'ai pu vérifier que j'avais corrigé sur dom) mais n'est pas représentative de la validation qui est uniquement dispo sur dom.

par sly » 11 févr. 2016, 21:17

Dominique a écrit : Ben non, il y a autant d'appels de constructeur de layer que de type d'affichage (demander les points à l'intérieur d'un massif c'est "api/polygones", massif no sélectionné devient "api/bbox" et les paramètres sont différents).
Oui mais le traitement du retour pourrait être le même non ? seuls les paramètres de l'api changeraient.
Enfin si c'est plus simple, il doit y avoir 3 fois un bout de code de 10 lignes, c'est pas la mort.
Dominique a écrit : Attention: je n'ai pas archivé GIT ni WRI le nouveau code à tester !
je n'ai pas compris cette phrase ? tu n'as pas fait un push de tes modifs c'est ça ?

par sly » 11 févr. 2016, 21:12

Dominique a écrit :
sly a écrit :Si je ne coche rien, on dirait bien qu'il appel type_point= et ça affiche tout ;-p
Ben oui, c'est ce que j'essayais d'argumenter sur le TRAC: c'est le comportement par défaut (sans ajouter de code ni dans vues/nav.js ni dans l'API).
J'ai laissé comme ça pour l'instant bien que le résultat soit bizarre.

- Soit on accepte que l'API ne réponde rien à &type_point=

- Soit l'API accepte &type_point='none' (résultat nul). mais ça me fait ajouter du code dans le nav.js

- Une solution simple pour le code de l'API et nav.js: ajouter un type de point 0 ne correspondant à aucun point dans la base. J'ajouterai 0 à toute requête, ce qui donnerait &type_point=0 pour tout décoché qui ne retournerait rien :idea:

- Soit on développe un code particulièrement décalé dans vues/nav.js qui passe le BBOX au fond de l'Atlantique ou qui détruit provisoirement la layer tant qu'on n'a pas recoché un type de point.

- Soit on se contente de ce comportement bizarre: si on demande rien, on a tout :oops:
C'est marrant que tu n'aies pas listé la seule solution élégante ;-) :
ne simplement pas faire d'appel à l'API.


Mais bon, js, leaflet, classes, mega abstractions je suis souvent largué, peut être qu'a la fin ce n'est plus le développeur qui modèle son outil, mais l'outil qui façonne la manière dont le développeur pense.

par Dominique » 11 févr. 2016, 19:47

Ben non, il y a autant d'appels de constructeur de layer que de type d'affichage (demander les points à l'intérieur d'un massif c'est "api/polygones", massif no sélectionné devient "api/bbox" et les paramètres sont différents).

Ceci dit, ce n'est pas une excuse pour ne pas avoir implémenté la même URL ni la même étiquette sur tous les appels. Je corrige. Merci pour le bug :)

*** EDIT *** C'est OK avec le nouveau code dom.R.I
Attention: je n'ai pas archivé GIT ni WRI le nouveau code à tester !
Il faut aller sur http://dom.refuges.info

par Dominique » 11 févr. 2016, 19:43

sly a écrit :Si je ne coche rien, on dirait bien qu'il appel type_point= et ça affiche tout ;-p
Ben oui, c'est ce que j'essayais d'argumenter sur le TRAC: c'est le comportement par défaut (sans ajouter de code ni dans vues/nav.js ni dans l'API).
J'ai laissé comme ça pour l'instant bien que le résultat soit bizarre.

- Soit on accepte que l'API ne réponde rien à &type_point=

- Soit l'API accepte &type_point='none' (résultat nul). mais ça me fait ajouter du code dans le nav.js

- Une solution simple pour le code de l'API et nav.js: ajouter un type de point 0 ne correspondant à aucun point dans la base. J'ajouterai 0 à toute requête, ce qui donnerait &type_point=0 pour tout décoché qui ne retournerait rien :idea:

- Soit on développe un code particulièrement décalé dans vues/nav.js qui passe le BBOX au fond de l'Atlantique ou qui détruit provisoirement la layer tant qu'on n'a pas recoché un type de point.

- Soit on se contente de ce comportement bizarre: si on demande rien, on a tout :oops:

par sly » 11 févr. 2016, 19:18

par sly » 10 févr. 2016, 17:52

Si je ne coche rien, on dirait bien qu'il appel type_point= et ça affiche tout ;-p

Evolution de Leaflet

par Dominique » 10 févr. 2016, 17:35

Bonjour

je procède à une importante mise à jour du programme d'affichage des cartes.

Parmi les nouvelles fonctionnalités:
- mémorisation des emplacements, zoom, fournisseur du fond de carte et sélection des types de points pendant la navigation entre les pages (sauf affichage d'un nouveau point)
- pour les modérateurs: nouvelle ergonomie de l'éditeur de contour massif.

En ce qui concerne le logiciel (donc pas visible de l'extérieur mais pouvant générer des bugs):
- update des dernières mises à niveau des plugins Leaflet (mais pas Leaflet 1.0 beta qui n'est pas mur)
- passage des informations géographiques en geoJson directement de la base au kernel de Leaflet (et vice versa)

Pour l'instant, le nouveau logiciel peut être testé ici: http://dom.refuges.info/
Je vous serais reconnaissant de l'agiter dans tous les sens avant la mise en production.
(il est configuré avec la base de test, vous pouvez tout casser sans crainte)

Vos remarques et suggestions sont les bienvenues.

Haut