GIS et les fonds de carte Stamen

Je découvre que Stamen a cessé à la mi aout de fournir ses fonds de carte. Les requêtes vers les cartes Stamen sont actuellement toujours servies via une redirection 302 et le rendu est donc préservé pour l’instant. Juste ça double le nombre de requêtes HTTP relatives aux cartes.
Mais la redirection va cesser en octobre et les cartes apparaîtront alors sans fond de carte (blanches) si l’adresse du provider n’est pas changée dans le code utilisateur.
Il faut donc reparamétrer les scripts (et le plugin GIS ?) pour utiliser la nouvelle adresse d’hébergement, sur stadiamaps.com
Pour cela il faut y créer un compte.
C’est décrit comme plus performant et ça reste gratuit pour des petits volumes et usages non commerciaux.

Peut être certains sont plus avancés dans ces découvertes et dans la mise en pratique ?

Stadiamaps n’est gratuit que pour max 200 000 tuiles par mois.
Si une carte nécessite 10 tuiles, et que l’utilisateur change le zoom une fois, ça fait 10 000 affichages par mois, c’est à dire 333 par jour seulement.
Et 160 seulement s’il faut 2 fonds de carte (un pour la déco et un pour les noms).
Je me goure pas ?
Du coup ça devient assez vite payant = mini 20€ par mois cf Pricing & Tiers | Stadia Maps

Ça serait ptet intéressant de mettre en cache.
Pour certaines cartes ya des CDN alternatifs aussi.

Oui, j’avais bokkmarké ça par ici Here comes the future of Stamen Maps | Stamen

On a déjà adapté le code de la lib qui gère les différents fonds de cartes dans GIS cf Update Stamen providers to reflect that they are now hosted by Stadia Maps by ianthetechie · Pull Request #520 · leaflet-extras/leaflet-providers · GitHub et je pense répercuter ça dans GIS prochainement.

1 « J'aime »

Et voici la PR pour assurer la continuité des fonds stamen dans GIS #63 - update stamen - gis - SPIP on GIT

Ah super b_b.

L’impact du changement chez Stamen est tout de même assez lourd puisque pour un SPIPeur il ne suffit pas de routinièrement mettre GIS à jour, il faut aussi créer un compte chez Stadiamap, ce que ne feront pas les utilisateurs non informés. Et il faudra passer à la caisse pour pas mal de sites, au vu des calculs grossiers exposés plus haut, ou passer à un fond qui ne soit pas Stamen.

D’où l’envie de les copier localement pour les servir localement, puisque ces tiles sont CC BY 3.0, et que concernant le volume disque, je n’ai besoin que d’une partie restreinte de la planète et à des niveaux de zooms restreints.
Mais où est le dépôt des tuiles ? Je n’ai rien vu de tel dans Stamen Design · GitHub , du moins pour les couches watercolor et label que j’utilise.

À défaut il faudrait développer un capteur-resserveur de tiles…

Indépendamment de Stamen/Stadia ou de tout autre provider, il pourrait être utile d’avoir une fonction « cacher les tuiles sur mon serveur » dans gis, pour diminuer les requêtes à un serveur centralisé.

Cela pourrait se faire assez simplement et de façon générique via une action api /gis_tile_cache.api/{provider_name}/{base64_tile_url}, sous reserve qu’on puisse s’inserer dans leaflet à l’endroit ou les URLs de tile sont construites pour transformer l’URL. Alternative, modifier directement les URLs dans le L.TileLayer.Provider.providers en remplaçant la partie https:// par https://monsite.spip.org/gis_tile_cache.api/{provider_name}/ et suivrait donc l’URL complète de la tile.

Ensuite on peut avoir la politique de cache que l’on souhaite dans l’action, comme par exemple ne rafraichir les tuiles que si elles ont plus d’un mois etc. L’avantage est que ton fond de carte présenté à l’identique à tous les utilisateurs serait toujours issu de tes tuiles en cache. L’inconvénient est que ça rajoutera de la latence sur la navigation dans la carte, plus ou moins selon la capacité et la réactivité du serveur qui host le site.

Maintenant il faut quand même pas non plus trop s’étonner de devoir payer à un moment, tout le monde ne peut pas faire tout gratuitement…

2 « J'aime »

C’est un peu ce que j’envisageais mais je pensais pas le faire dans le plugin GIS lui même :

  • en prenant la tile localement lorsqu’elle est présente
  • en interrogeant le provider initialement et en stockant la tile dans un sous dossier {tile_set}/{x}/{y}/{z} lorsqu’elle n’y est pas déjà
  • en restreignant ce stockage local à la zone géographique et aux niveaux de zooms les plus fréquemment requis, pour limiter le volume de stockage

Via une règle dans le .htaccess, on peut demander à servir directement la tile une fois qu’elle a été enregistrée localement, et j’imagine que l’accès direct à l’image locale peut être plus rapide que par le CDN fastly utilisé par Stamen, qui n’était pas spécialement une flèche…

De plus, en ce qui me concerne, j’utilise 2 fonds de cartes superposés : l’un pour le fond, et l’autre pour les noms de localités; et en disposant des tiles localement, il serait possible de les fusionner par un script, afin, au final, de ne devoir servir qu’une seule tile au lieu de 2.

A part ça oui c’est normal de payer parfois… à moins que le service soit considéré comme un service de base dans un pays démocratique, et financé par les impôts, comme les routes… ou qu’il ne soit considéré comme assez important par une communauté bénévole… et/ou de bosser pour créer le service équivalent…

On pourrait aussi en faire des webp plutôt que les actuels jpg ou png :-/…

C’est bien à ça que sert l’entrée correspondante dans le changelog :slight_smile:

« On » pourrait oui, mais ça pose question sur l’espace disque nécessaire, et certains fournisseurs de tuiles interdisent la mise en cache dans leur conditions d’usage.

Maintenant il faut quand même pas non plus trop s’étonner de devoir payer à un moment, tout le monde ne peut pas faire tout gratuitement…

Et oui, comme expliqué sur maps.stamen.com cela coûtait entre 100 000 $ et 200 000 $ à Stamen de diffuser ces tuiles.

Environ 600Mo pour un jeu de tuile JPG des niveaux de zoom 1 à 12, restreint aux tiles couvrant la France à partir du niveau 8.

Il y a des outils dédiés pour ça :

1 « J'aime »

Voici mon script pour récupérer les tiles localement : Script gettiles.sh

En l’état c’est fait pour le provider stamen seulement (juste il faut éditer l’url pour requêter un autre provider).
Il y a une attente de 2s entre 2 requêtes pour éviter d’être blacklisté (sinon l’accès est refusé au bout d’un moment).
Les autres paramètres sont : le jeu de tuiles, le niveau de zoom, le viewport.

Et voici un script qui fusionne 2 jeux de tiles GIS en les superposant, pour n’avoir plus qu’à utiliser qu’un seul jeu de tuiles au lieu de 2 (fond de carte + labels)

https://contrib.spip.net/Script-merge_trees-pour-fusionner-des-jeux-de-tiles