Calcul de distance entre deux points SQL
Calculez instantanément la distance entre deux coordonnées latitude/longitude, comparez les unités, générez un exemple de requête SQL et visualisez le résultat dans un graphique clair et responsive.
Calculateur interactif
Entrez deux points géographiques et cliquez sur “Calculer la distance”. Le calcul repose sur la formule de Haversine, très utilisée pour estimer la distance orthodromique sur la surface terrestre.
Guide expert du calcul de distance entre deux points en SQL
Le sujet du calcul de distance entre deux points SQL est essentiel dans de nombreux projets de données. Dès qu’une application manipule des coordonnées géographiques, il devient nécessaire de mesurer des écarts, classer des lieux par proximité, filtrer des points dans un rayon donné ou encore optimiser des recherches cartographiques. On retrouve ce besoin dans le e-commerce local, la logistique, les applications de mobilité, les annuaires géolocalisés, les services de livraison, les analyses marketing et les systèmes SIG.
En SQL, ce calcul peut être abordé de plusieurs façons. Certaines équipes commencent avec une formule mathématique directement écrite dans une requête. D’autres s’appuient sur des fonctions spatiales natives fournies par le moteur de base de données, comme ST_Distance, ST_Distance_Sphere ou des types géographiques spécialisés. Le bon choix dépend du volume de données, du niveau de précision attendu, du moteur utilisé et de la nécessité éventuelle d’indexer les colonnes spatiales.
La bonne pratique moderne consiste généralement à distinguer deux cas : le calcul ponctuel entre deux valeurs connues, et la recherche de proximité sur un grand ensemble de lignes. Dans le premier cas, une formule de distance suffit souvent. Dans le second, l’usage d’index spatiaux et de colonnes de type géographique devient déterminant pour éviter des performances insuffisantes.
Pourquoi ce calcul est stratégique dans les bases de données modernes
Le calcul de distance entre deux points n’est pas un simple exercice académique. C’est une opération métier critique. Une plateforme de livraison veut identifier le livreur le plus proche d’un restaurant. Une chaîne de magasins souhaite afficher le point de vente le plus proche d’un visiteur. Une collectivité publique peut analyser l’accessibilité des services essentiels. Une application de mobilité peut comparer des trajets et des zones de desserte.
Si l’on rapatrie toutes les coordonnées côté application pour effectuer les calculs en mémoire, on augmente la latence, le trafic réseau et la complexité de traitement. En réalisant ces calculs directement dans la base SQL, on exploite la proximité des données, la puissance des index et la capacité du moteur à trier, filtrer et agréger rapidement. C’est la raison pour laquelle les développeurs, data engineers et administrateurs de base cherchent souvent à industrialiser ce type de logique dans des vues, procédures, fonctions ou requêtes optimisées.
Comprendre les coordonnées et la formule utilisée
Pour mesurer une distance géographique, on part généralement de deux couples (latitude, longitude). Les coordonnées sont exprimées en degrés décimaux. La latitude décrit la position nord-sud, la longitude la position est-ouest. Comme la Terre n’est pas plate, une simple distance euclidienne en 2D n’est pas adaptée dès que l’on travaille à l’échelle géographique réelle.
La formule de Haversine est très populaire car elle calcule la distance orthodromique approximative entre deux points situés sur une sphère. Elle offre un excellent compromis entre simplicité, précision et portabilité SQL. Son principe est de convertir les angles en radians, puis d’exploiter les fonctions trigonométriques pour obtenir l’angle central entre les deux points. Enfin, cet angle est multiplié par le rayon terrestre.
Étapes mathématiques du calcul
- Convertir latitudes et longitudes en radians.
- Calculer les écarts de latitude et de longitude.
- Appliquer la formule de Haversine pour obtenir l’angle central.
- Multiplier par le rayon moyen terrestre, souvent 6 371 km.
- Convertir le résultat en mètres, miles ou milles nautiques selon le besoin.
Exemple d’implémentation SQL avec Haversine
Un calcul manuel en SQL reste utile si vous devez conserver une compatibilité forte entre plusieurs moteurs ou si votre environnement n’utilise pas encore les extensions spatiales. Voici la logique générale :
- les colonnes source stockent la latitude et la longitude en degrés décimaux ;
- la requête calcule une distance par ligne vers un point de référence ;
- vous pouvez ensuite trier par distance croissante ou filtrer les résultats sous un certain seuil.
Le piège principal consiste à oublier les radians. Les fonctions trigonométriques SQL attendent généralement des radians et non des degrés. Une autre erreur fréquente est de vouloir filtrer directement tout un grand jeu de données avec la formule complète. Dans ce cas, il est préférable d’appliquer d’abord une boîte englobante simple sur latitude et longitude, puis d’affiner avec Haversine.
MySQL, PostgreSQL et SQL Server : quelles différences ?
Le moteur SQL influence fortement la manière de calculer la distance. MySQL propose des fonctions spatiales utiles et reste accessible pour des cas courants. PostgreSQL avec PostGIS est souvent considéré comme la référence pour les usages géospatiaux avancés grâce à son écosystème riche, ses types géométriques et géographiques, ainsi que ses opérateurs spécialisés. SQL Server offre aussi des capacités géographiques robustes avec le type geography et des méthodes intégrées adaptées aux requêtes métier.
| Moteur | Fonction ou type courant | Cas d’usage typique | Point fort | Point d’attention |
|---|---|---|---|---|
| MySQL 8+ | ST_Distance_Sphere | Recherche simple de proximité, applications web | Syntaxe simple, mise en oeuvre rapide | Fonctionnalités géospatiales moins riches que PostGIS |
| PostgreSQL + PostGIS | ST_Distance, geography | SIG, analytics spatiales, production à grande échelle | Écosystème géospatial très complet | Courbe d’apprentissage plus élevée |
| SQL Server | geography::Point, STDistance | Systèmes d’information d’entreprise | Bon support natif dans l’écosystème Microsoft | Conventions propres au moteur à maîtriser |
Statistiques et repères utiles pour améliorer la précision
Quand on parle de distance géographique, le rayon de la Terre joue un rôle direct dans le résultat. Or la Terre n’est pas une sphère parfaite. Selon le contexte, on utilise un rayon moyen ou des mesures plus fines issues du référentiel WGS84. Pour la majorité des projets SQL, le rayon moyen de 6 371 km fonctionne bien. Mais il est utile de connaître les ordres de grandeur réels.
| Mesure terrestre | Valeur | Usage fréquent | Impact pratique |
|---|---|---|---|
| Rayon moyen terrestre | 6 371,0 km | Haversine standard | Excellent compromis précision/simplicité |
| Rayon équatorial WGS84 | 6 378,137 km | Références géodésiques | Légère variation selon la latitude |
| Rayon polaire WGS84 | 6 356,752 km | Calculs scientifiques plus fins | Montre l’aplatissement réel de la Terre |
| Circonférence équatoriale | 40 075 km | Repère global | Utile pour valider des ordres de grandeur |
Comment écrire des requêtes performantes
La précision ne suffit pas. Une requête doit aussi être rapide. Si vous avez une table de quelques centaines de lignes, une formule inline dans le SELECT ne posera pas de problème. Avec plusieurs centaines de milliers ou millions de points, la stratégie doit changer. Les fonctions trigonométriques appliquées à chaque ligne peuvent devenir coûteuses, en particulier si le moteur ne peut pas exploiter d’index sur l’expression complète.
Bonnes pratiques de performance
- Créer des index spatiaux quand le moteur le permet.
- Utiliser des types géographiques natifs plutôt que deux colonnes flottantes isolées lorsque c’est possible.
- Filtrer d’abord par boîte englobante avant de calculer la distance exacte.
- Éviter les conversions répétées en radians si une colonne dérivée ou un type spatial est disponible.
- Limiter le nombre de lignes candidates avec WHERE, TOP ou LIMIT.
Une boîte englobante consiste à déduire un minimum et un maximum de latitude et de longitude autour d’un point central. Ce filtre approximatif réduit énormément le volume de lignes avant le calcul précis. C’est un classique d’optimisation. Ensuite seulement, on trie par distance et on récupère les résultats pertinents.
Cas d’usage concrets du calcul de distance en SQL
1. Recherche de magasins à proximité
Un site e-commerce local peut demander la position de l’utilisateur et lister les boutiques les plus proches. La requête SQL calcule la distance depuis le point utilisateur vers chaque magasin, puis trie les résultats. Un filtre à 10 km ou 25 km améliore l’expérience et la pertinence commerciale.
2. Allocation de ressources logistiques
Dans une flotte de livraison, connaître le dépôt ou le véhicule le plus proche réduit les coûts et les délais. Ici, la distance sert parfois de pré-filtre avant une logique de routage plus sophistiquée intégrant le réseau routier réel.
3. Analyse territoriale et reporting
Les analystes peuvent calculer l’éloignement de populations par rapport à des hôpitaux, écoles, équipements publics ou points de service. Dans ce contexte, SQL permet de produire des indicateurs massifs sur des bases volumineuses, souvent en complément d’outils SIG.
Quelle méthode choisir selon votre besoin
- Projet simple, faible volumétrie : formule de Haversine en SQL ou côté application.
- Application web à trafic moyen : fonctions spatiales natives du moteur, avec filtre de proximité.
- Projet cartographique ou analytique avancé : type géographique natif et index spatial.
- Exigence scientifique élevée : référentiel géodésique précis et outils spécialisés au-delà de la simple formule sphérique.
Exemples d’erreurs fréquentes à éviter
- Confondre ordre latitude/longitude selon les fonctions du moteur.
- Utiliser des degrés au lieu des radians dans les fonctions trigonométriques.
- Comparer des résultats dans des unités différentes sans conversion explicite.
- Effectuer un scan complet de table alors qu’un index spatial est possible.
- Supposer que la distance “à vol d’oiseau” équivaut à la distance routière.
Il faut également faire attention au stockage. Si les coordonnées sont enregistrées comme chaînes de caractères ou nombres imprécis, la qualité des calculs se dégrade. Le plus sûr est de stocker des décimaux suffisamment précis ou d’utiliser directement des types spatiaux dédiés.
Quand utiliser ST_Distance au lieu de Haversine manuel
Si votre moteur dispose d’une fonction spatiale native fiable, elle doit souvent être privilégiée. D’une part, le code est plus lisible. D’autre part, le moteur est généralement mieux optimisé pour traiter ses propres types géographiques que des expressions trigonométriques répétées à la main. PostGIS est particulièrement puissant pour cela, mais SQL Server et MySQL ont aussi beaucoup progressé. Le calcul manuel garde toutefois sa place pour les environnements hétérogènes, les démonstrations pédagogiques ou les cas où l’on doit garder un contrôle total sur la formule appliquée.
Ressources institutionnelles et académiques à consulter
Pour approfondir les notions géodésiques, cartographiques et les systèmes de coordonnées, ces sources sont particulièrement utiles :
Conclusion
Le calcul de distance entre deux points en SQL est un pilier de la donnée géographique opérationnelle. Pour les cas simples, la formule de Haversine apporte une solution élégante et portable. Pour les environnements exigeants, les fonctions spatiales natives, les types géographiques et les index spécialisés offrent une base bien plus robuste. La meilleure approche consiste à aligner précision, performance et maintenabilité avec vos objectifs métier. Si vous gérez quelques points, une formule suffit. Si vous gérez un service géolocalisé à grande échelle, investissez dans une modélisation spatiale propre, des tests de précision et une stratégie d’indexation solide.
En résumé, réussir ce type de calcul ne consiste pas seulement à obtenir un nombre en kilomètres. Il s’agit de concevoir une chaîne technique cohérente, de la qualité des coordonnées jusqu’à l’exécution de la requête, en passant par le choix de l’unité, la compatibilité du moteur SQL et le niveau de détail attendu par le métier.