WIP: custom pmtiles protocol to only display even zoom levels

etienneJr

Cette PR sert à tester l'idée évoquée dans #1086 de n'afficher que les niveaux de tuiles pairs.

Elle a vocation à être déployée en dev uniquement, pour pouvoir comparer le ressenti utilisateur avec la prod.

La protocole custom a été préparé avec l'aide de wipfll suite à question sur repo pmtiles.

Dans mes essais, la quantité de données de tuiles téléchargées lorsque qu'on zoome on dézoome entre les niveaux 5 et 14 est 2 à 3 fois plus faible.

Pour que maplibre sur- ou sous-zoome dans la dernière tuile, le protocole doit renvoyer une erreur, j'espère que ça ne provoquera pas de crash bleu ?

1. etienneJr

   @laem peux tu déployer cette branche hide-odd-zoom-levels en dev ?

2. etienneJr

   Perso en gardant comme ça 1 niveau sur 2, je ne vois pas de différence.

   Le seul truc un peu bizarre que j'ai noté, c'est si on est arrivé à un endroit direct à zoom très fort, puis qu'on dézoome jusqu'à zoom 13,xx alors on va avoir un mélange de tuile 14 sous-zoommée (au centre de la carte) et de tuile 12 sur-zoomée. Vous voyez la limite entre les 2 sur cette capture ?

   

   Je remarque d'ailleurs que quand maplibre ne trouve pas la tuile de niveau 13, il requête tout seul la tuile de niveau 12, j'en suis moi même surpris. Mais c'est super efficace, il n'y a jamais de trou dans le fond de cartes, même quand on glisse la carte à un zoom qui "n'existe pas" dans les tuiles.

3. laem

   Mince Étienne j'ai complètement zappé ta demande.

4. laem

   Voilà @etienneJr j'ai créé dev2.cartes.app juste pour toi :D En vrai c'est simple dans Dokloy, mais ça demande de faire un nouveau sous-domaine sur la zone DNS donc je n'en ferai pas 36 non plus.

5. etienneJr

   ah génial, merci ! mais il faudrait rebaser cette branche pour qu'on puisse comparer à armes égales.

   A première vue (test hyper rapide sur mon tel) ça me parait bien, mais je sais que tu vois beaucoup mieux que moi les petits détails, donc tu me diras ce que tu en penses.

   Si on part sur ce fonctionnement, il y aura des petites modifs à faire dans le calcul des tuiles :

   • diminuer un peu le niveau de simplification des lignes
   • inclure les éléments qui apparaissent à zoom impair dans la tuile paire précédente. c'est à dire : se permettre d'alourdir un tout petit peu les tuiles paires, vu qu'on gagne énormément grâce au non transfert des tuiles impaires.

   @pmiossec tu testeras aussi ?

6. laem

   D'acc, tu te charges du rebase ou tu veux que je prenne ?

7. etienneJr

   c'est fait.

8. laem

   Ah cool on peut préfixer de WIP: pour créer un brouillon, j'avais pas vu :)

9. laem

   J'ai redéployé. En quelques secondes de test je ne vois pas de différence.

10. laem

    C'est pas évident à tester, car changer le zoom dans l'URL et taper entrer ne fait pas dans mes tests gagner en poids.

11. laem

    En tentant un zoom à la main depuis rennes haut niveau vers rennes zoom 20 je mesure un léger gain de seulement 1mo sur 12mo.

12. etienneJr

    Bizarre, j'avais écrit là haut :

    Dans mes essais, la quantité de données de tuiles téléchargées lorsque qu'on zoome on dézoome entre les niveaux 5 et 14 est 2 à 3 fois plus faible.

    on demande aux gens de tester sur le forum osm-fr ?

13. etienneJr

    J'ai investigué : ya un gros pb avec le paramètre experimentalZoomLevelsToOverscale que j'ai introduit dans #1348 : pour pouvoir découper la tuile 14 en petits bouts quand on zoom dedans, bah... maplibre la recharge à chaque fois, dès qu'on bouge ou zoome un petit peu 😭​ ça fait exploser la quantité de données transférées, parce qu'en plus le cache du navigateur n'est pas utilisé (ça je n'ai pas compris pourquoi, un avis @laem ? )

14. etienneJr

    même sans experimentalZoomLevelsToOverscale, il y a un pb de multiples chargements, parce que les tuiles ne sont pas mises en cache dans le navigateur. re 😭

    tickets en lien avec le sujet (je n'ai que survolé, c'est trop long et technique)

    • chez maplibre https://github.com/maplibre/maplibre-gl-js/issues/4074
    • et j'ai posé la question ici : https://github.com/maplibre/maplibre-gl-js/discussions/6910
    • chez pmtiles https://github.com/protomaps/PMTiles/issues/272

    mais experimentalZoomLevelsToOverscale l'amplifie x4 environ, donc je le désactive de suite tant qu'on n'a pas résolu ce pb.

    ça sert à rien de réfléchir à des tuiles plus légères si maplibre les charge des dizaines de fois. ​😤​

15. etienneJr

    qq vidéos pour illustrer ce pb de cache https://cartes.app/#19.41/48.114718/-1.680773

    sans experimentalZoomLevelsToOverscale la même tuile est rechargée 9 fois => 3Mo de données pour rien <video src="https://codeberg.org/attachments/e56d3732-624b-4dca-b2bf-5aa158ac9bb9" title="without" controls></video>

    avec experimentalZoomLevelsToOverscale: 2 la même tuile est rechargée 28 fois => 9Mo <video src="https://codeberg.org/attachments/f6d9b3f1-6f17-46af-9da3-dbedb3641f2d" title="with" controls></video>

16. laem

    Ah la la, je crois que c'est Firefox qui merde dans la mise en cache des appels HTTP range requests sur lesquels sont basés pmtiles. Je viens de confirmer, Chromium met ça en cache. J'imagine que MapLibre repose sur le cache du nav, ce qui est pas bête.

    J'avais déjà noté ça ici https://codeberg.org/cartes/web/issues/1081

    Passer à des tuiles x,y,z n'est pas très compliqué à faire, ça nous fait juste un serveur en plus à maintenir, mais ça évite aussi de charger le module protomaps maplibre côté client.

17. etienneJr

    [edit] ah oui, maintenant que je vois le ticket et le post bsky je m'en souviens, alors qu'hier soit je séchai complètement... 😵

    Pour info, j'observe le même comportement sur edge que sur firefox...

    Idée à tester : utiliser notre procotol custom pour renvoyer une erreur plutôt que la tuile quand maplibre demande les zooms 15 à 22, il devrait alors utiliser la tuile z14 qu'il a en mémoire.

18. laem

    Va falloir que je mette en place la solution toute trouvée : les tuiles xyz via pmtiles serve. Aussi bien ça me prendra moins d'1h.

19. etienneJr

    est-ce qu'on pourra encore mettre en place l'astuce de n'afficher que les zooms pairs ?

20. laem

    Oui je pense, la notion de protocole en maplibre n'est pas liée au fait de taper directement dans un PMTiles. Dans tous les cas, ça me dit bien de tester pour voir si c'est plus rapide.

21. etienneJr

    J'ai rebase avec une nouvelle version du custom protocol qui utilise le nouveau server xyz qui permet une mise en cache des tuiles par le navigateur

    Ce qui permet un nouveau test comparatif (j'ai gardé le cache actif dans la console, mais je l'ai vidé juste avant chaque test avec la fonction Effacer les cookies et données du site pour mimer une première vue des tuiles)

    je regarde uniquement le fichier planet.pmtiles

    de z5 France à z18 ...	avant	après
    ... au centre d'Orléans	76 requêtes, 6.2 Mo	41 requêtes, 3.2 Mo
    ... au centre de Rennes	85-93 requêtes, 9.5-10.1 Mo	58 requêtes, 5.6-6.8 Mo
    ... au centre de Lyon	80 requêtes, 9.8 Mo	46 requêtes, 5.6 Mo

    ➡️​ on économise environ la moitié des requêtes et la moitié des Mo transférés (à la première vision des tuiles, car après on économise surtout grâce au cache du navigateur)

22. etienneJr

    @laem j'imagine qu'il n'y a pas de déploiement auto sur dev2 ? pourras tu le faire ?

23. etienneJr

    Retour des utilisateurs sur le forum OSM-FR : c'est trop perturbant. Donc standby ici pour le cas général, mais on peut garder l'idée pour un futur "mode léger".