← Retour aux issues

Why do we produce our own tiles ?

publié le , mis à jour
Avatar Codeberg de laemlaem

Tiles are the data of the map that we display after applying a style, we've started the project by using MapTiler. MapTiler uses and develops OpenMapTiles, the leading open source MapLibre tile format. We first started to personalize the style, keeping raw OMT (OpenMapTiles) tiles. But we met two problems :

    1. MapTiler's API is too expensive for the number of views we started to soon get (a few thousands per month...) : more than 150 € / month, > than our global web and API server costs
    1. lots of data we wanted to show to the user where missing from the OMT spec
  1. could have been resolved by using VersaTiles indeed to host them on our servers. But switching our style to the shortbread format was quite some work. To generate tiles, we're using Tilemaker too. Some of VersaTiles's stack was already used in our cartesapp/server. Last but not least, we switched to protomaps for serving, which is awesome, VersaTiles appears to still use MBtiles. We've thought about switching to Protomaps's tile specification, but we're not convinced yet

We still let the user chose untouched MapTiler styles, they're great. E.g. the winter style is incredible (https://cartes.app/?style=winter#13.94/45.96529/6.46702/160.8/50). We're thinking of including MapTiler's styles as premium paid features. When we'll have 100 k monthly users, paying MapTiler for these specialised styles will not be possible anymore.

  1. We've modified the OMT specification to fit our objectives (see this file https://github.com/cartesapp/serveur/blob/master/tilemaker/resources/process-openmaptiles.lua). E.g. showing railways on higher zoom than motorways. Or displaying more touristic places. Or coworking spaces. Any tile spec is an editorial choice (because exposing everything that OSM holds is too bandwidth heavy), and we've gone our own way. We're also adding layers that these projects do not, e.g. trees (very important : Apple decided trees are worthwile, Google and Organic did not) and ocean depths which makes a very realistic globe. We've also integrated indoorequal to provide indoor floors maps. Another customisation that we're proud of is coloring the roads according to their maxspeed. < 20 km/h roads are white, < 30 are light gray, etc. Last but not least, we've just finished the integration of a new icon set and telemetrics about which icons are missing.

See https://github.com/cartesapp/serveur, tiles are handled there. Styles are in this repo.

  1. Avatar Codeberg de laemlaem

    Some additional commentaries in French from this discussion : https://codeberg.org/cartes/web/issues/1033#issuecomment-5844980


    dans la même logique que l'instance overpass, je proposerais bien qu'un serveur osmfr héberge et serve un pmtiles mondial incluant les types et IDs. Voire 1 fichier en openmaptiles et 1 fichier en shortbread. Avec un script qui fait la mise à jour tous les x jours.

    Perso je ne suis pas très intéressé par ces standards. Ils sont figés, trop peu axés utilisateurs. Ils sont super pour les applications qui intègrent une carte, comme la page contact d'un magasin. Mais pas pour une application de cartographie qui a besoin du contrôle total.

    D'ailleurs s'il fallait n'en retenir un je pense que ce serait le format Protomaps (actuellement en v4 https://docs.protomaps.com/basemaps/layers). Ce qu'a fait l'auteur de Protomaps pour rendre accessible les tuiles maison est dingue, j'ai une grande confiance en lui et il est très critique d'OMT notamment sur le plan de la licence.

    Comme ça on pourra garder le calcul spécifique des tuiles de Cartes juste sur la France.

    Pour ces raisons, et pour éviter la complexité actuelle du protocole fait maison pour partager le style principal entre deux serveurs de tuiles, je pense à l'inverse qu'il faut aller vers la couverture du monde avec nos propres tuiles, évoluant vite selon les besoins de l'interface.

    Cela dit, la publication de tuiles standard avec Id serait une excellente chose, mais je n'ai pas envie de passer du temps sur cette évidence qui aurait du être corrigée il y a déjà 10 ans.


✏️ Participer à la discussion