Mètres par pixel Web Mercator

La résolution au sol en Web Mercator répond à une question cartographique très concrète : à ce niveau de zoom et à cette latitude, combien de mètres au sol un pixel de la carte représente-t-il ? Les serveurs de tuiles, les SDK mobiles et les notebooks SIG ont tous besoin de ce chiffre pour dimensionner des tampons, tracer des échelles graphiques, choisir des rayons de regroupement raisonnables et convertir des distances à l’écran en distances géographiques sans passer par une bibliothèque de projection complète. La formule classique multiplie la circonférence équatoriale de la sphère WGS84 utilisée par EPSG:3857 par le cosinus de la latitude, puis divise par le nombre de pixels qui couvrent le monde à ce zoom : deux cent cinquante-six fois deux élevé à la puissance du niveau de zoom. À l’équateur et au zoom zéro, on retrouve la constante bien connue d’environ cent cinquante-six mille cinq cent quarante-trois mètres par pixel ; chaque pas de zoom divise cette valeur par deux et les latitudes plus élevées la réduisent selon cos(latitude). Cette capacité renvoie les mètres par pixel ainsi que des utilitaires comme les mètres par bord de tuile et la circonférence à la latitude, afin que vous alimentiez l’interface d’échelle, les seuils d’accrochage et les charges utiles de l’API depuis un unique chemin de parse déterministe. Un zoom négatif ou une latitude hors de la plage géographique est rejeté avec une erreur de validation claire au lieu d’inventer une fausse résolution.

Comment les mètres par pixel Web Mercator sont calculés

En rassemblant les éléments, on obtient que meters_per_pixel est égal à cos(phi) fois deux pi R divisé par tile_size fois deux élevé à la z — ou, de manière équivalente, la constante de résolution initiale publiée fois cos(phi) sur deux élevé à la z. Le résultat est une arithmétique en virgule flottante déterministe : aucune graine aléatoire, aucun horodatage, aucun appel réseau et aucune dérive de modèle, de sorte qu’un zoom et une latitude identiques produisent toujours un JSON identique. La latitude doit se situer dans l’intervalle géographique fermé de moins quatre-vingt-dix à plus quatre-vingt-dix degrés ; les valeurs hors de cette plage ne sont pas des latitudes terrestres valides et échouent avec invalid_input.

Ce que vous envoyez et ce que vous recevez

Les deux champs sont obligatoires. Envoyez deux nombres : le zoom comme niveau entier non négatif de slippy-map et la latitude comme valeur finie en degrés décimaux avec le nord positif. Les champs manquants, les chaînes non numériques, NaN et Infinity échouent avec invalid_input et ne sont pas facturés. Un zoom négatif échoue avec un message indiquant que le zoom doit être non négatif ; une latitude en dehors de moins quatre-vingt-dix à plus quatre-vingt-dix échoue avec un message out-of-range, afin que les clients corrigent les erreurs de GPS ou de géocodeur au lieu de deviner. En cas de succès, la réponse renvoie le zoom et la latitude nettoyés, la valeur principale meters_per_pixel, meters_per_tile comme cette valeur fois deux cent cinquante-six, circumference_at_latitude_m pour les calculs d’échelle graphique, equatorial_circumference_m à titre de référence, initial_resolution_m_per_px au zoom zéro à l’équateur, earth_radius_m, tile_size_px, une étiquette de méthode et une chaîne de formule compacte. Les vérifications classiques comprennent le zoom douze à l’équateur pour environ trente-huit mètres par pixel, le zoom zéro à latitude zéro pour la constante de résolution initiale complète, et un zoom urbain de latitude moyenne comme douze près de cinquante et un degrés, qui donne une valeur de mètres par pixel nettement inférieure à celle de l’équateur. La tarification des appels API réussis est la base publiée de $0.002 par élément ; les échecs de validation ne consomment pas de solde prépayé.

Où les calculateurs de mètres par pixel apparaissent dans le travail réel

Comme cette capacité est un moteur de parse pur, la tarification de l’API est la base publiée de $0.002 par élément réussi et une validation échouée ne consomme pas de solde. Si vous avez ensuite besoin d’indices de tuile X/Y à partir de lat/lon, de décodage de quadkey Bing, de distance orthodromique ou de points de destination le long d’un cap, traitez-les comme des intentions de recherche et des pages d’atterrissage distinctes plutôt que de surcharger cette page de résolution au sol — l’intention SEO ici est précisément les mètres par pixel Web Mercator à partir du zoom et de la latitude.