idée long terme : gérer les catégories dans un pmtiles ?

etienneJr

Je note ici une idée bizarre, pour si jamais on se retrouve un jour avec l'instance overpass débordé par trop d'utilisateurs 😀

De la même façon qu'on calcule un fond de cartes dans un pmtiles avec un layer POI, on pourrait pré-calculer un pmtiles avec un layer pour chacune de nos catégories. Quand l'utilisateur activerait une catégorie, au lieu de faire une requête overpass sur la zone affichée, ça activerait l'affichage du layer du pmtiles.

J'avais fait ici une preuve de concept pour PlayGuide. Les marqueurs de lieux sont lus dans un pmtiles. On y voit un des avantages : aux zooms <14, la tuile ne contient pas forcément les lieux individuels mais bien plus souvent uniquement l'info du nb de lieux dans la zone géographique, qui permet d'afficher un cluster avec le nombre de lieux. Ca permet de proposer cet affichage des catégories quel que soit le zoom sans générer des requêtes overpass trop lourdes car sur une zone géographique trop grande, car tout a été précalculé dans le pmtiles.

En revanche, si je n'ai pas sauté le pas pour PlayGuide, c'était à cause de la mise à jour du pmtiles. Pour cartes.app, pour avoir la mise à jour minute de ces tuiles catégories (comme on a aujourd'hui la mise à jour minute de l'instance overpass), il faudrait déployer une instance tilekiln et tout paramétrer pour que les tuiles soient générées non pas au format shortbread, mais qu'elles contiennent nos catégories.

1. laem

   Ah oui c'est intéressant comme idée !

2. etienneJr

   j'ai commencé à regarder tilekiln (poussé par la proposition de cquest de l'utiliser pour un cyclosm vectoriel), mais j'ai biaisé le principe :

   • d'habitude osm2pgsql est utilisé comme pour les tuiles raster, le filtrage se fait au remplissage de la base, avec 1 table par type d'objet, qui ici deviendront chacune des couches vectorielles. Ca oblige à avoir figé le schéma quand on crée la base.
   • ici je prépare (comme j'avais fait quand on avait testé Underpass-API à la place d'overpass) une base osm2pgsql qui contient tout OSM. Puis je crée des VIEW pour la filtrer selon les tags. Enfin, une requête sql classique de tilekiln fait un SELECT dans la view en choisissant les tags à afficher.
     • une modif dans le SELECT est bien prise en compte après redémarrage de tilekiln serve pour générer une tuile à jour
     • je n'ai pas encore géré la fusion des nodes/ways/relations
     • je n'ai pas encore testé les mises à jours minute

   Exemple simpliste ici, j'ai préparé :

   • une couche building grâce à :
     • une VIEW (au lieu d'une table) qui sélectionne tous les ways qui ont le tag building=*.
     • puis un SELECT qui prend tous les objets, mais choisit d'inclure les valeurs de building et source dans la tuile
   • une couche amenity grâce à :
     • une VIEW (au lieu d'une table) qui sélectionne tous les nodes qui ont le tag amenity=*.
     • puis un SELECT qui prend tous les objets, mais choisit d'inclure name, amenity et opening_hours dans la tuile