Calcul Longueur Postgresql St Lenght

Calcul longueur PostgreSQL ST_Length

Calculez rapidement la longueur d’un segment entre deux coordonnées et comprenez la différence entre ST_Length sur une géométrie, une géographie et une projection Web Mercator. Cet outil est conçu pour les analystes SIG, développeurs SQL, équipes data et utilisateurs PostGIS qui veulent des résultats clairs, comparables et directement exploitables.

PostgreSQL + PostGIS Géométrie et géographie Graphique interactif

Calculateur interactif

Exemple: 48.8566 pour Paris
Exemple: 2.3522
Exemple: 45.7640 pour Lyon
Exemple: 4.8357
Saisissez vos coordonnées puis cliquez sur “Calculer la longueur”.

Comparaison visuelle

Le graphique compare trois approches courantes dans PostGIS: longueur géodésique, longueur en degrés sur SRID 4326, et approximation en Web Mercator.

Guide expert: bien comprendre le calcul de longueur PostgreSQL ST_Length

Le sujet du calcul longueur PostgreSQL ST_Length paraît simple à première vue: on prend une géométrie linéaire, on applique une fonction, et l’on obtient une distance. En pratique, c’est l’un des points les plus souvent mal compris dans les bases de données spatiales. La raison est directe: dans PostgreSQL avec PostGIS, le résultat de ST_Length dépend d’abord du type de données utilisé, puis du système de coordonnées, enfin de la projection choisie. Une ligne en EPSG:4326 exprimée en degrés ne renvoie pas le même type de mesure qu’une ligne transformée en EPSG:3857 ou castée en geography.

Si vous développez un moteur de calcul d’itinéraires, un tableau de bord logistique, une analyse réseau, un système de suivi de voirie ou une application cartographique dans WordPress ou ailleurs, comprendre cette distinction est essentiel. Une mauvaise interprétation peut générer des écarts de plusieurs pourcents, parfois bien davantage, selon la latitude, la distance et la projection de travail. Ce guide vous explique comment raisonner proprement, quand utiliser chaque méthode, comment vérifier vos résultats et quelles sont les bonnes pratiques pour produire des métriques fiables.

Ce que fait réellement ST_Length

ST_Length mesure la longueur d’une géométrie de type linéaire, comme un LINESTRING ou un MULTILINESTRING. Mais le mot “longueur” n’est pas universel. Dans PostGIS, il faut distinguer deux grands cas:

  • Sur geometry, la longueur est calculée dans les unités du système de coordonnées de la géométrie. Si votre géométrie est en 4326, l’unité native est le degré.
  • Sur geography, la longueur est calculée sur l’ellipsoïde terrestre et renvoyée en mètres, ce qui est généralement plus pertinent pour des distances réelles à l’échelle du globe.

Cette différence explique pourquoi un même segment peut afficher environ 3,97 degrés comme longueur géométrique en WGS84, tout en représentant environ 392 km de distance réelle si vous utilisez le calcul géodésique. Les deux résultats peuvent être justes, mais ils ne parlent pas de la même chose.

Le piège classique consiste à exécuter ST_Length sur une geometry en SRID 4326, puis à interpréter le résultat comme des mètres ou des kilomètres. Ce n’est pas correct. En 4326, la géométrie est exprimée en degrés.

Quand utiliser geometry et quand utiliser geography

Le choix entre geometry et geography dépend de votre objectif métier. Si vous réalisez une analyse locale avec une projection métrique adaptée à votre zone, le type geometry projeté est souvent très performant et précis. Si vous travaillez avec des coordonnées GPS globales ou sur plusieurs pays, geography est souvent plus simple pour obtenir des distances fiables sans choisir de projection locale spécifique.

  1. Utilisez geometry projeté si vous travaillez sur une zone limitée avec une projection adaptée, par exemple Lambert, UTM ou une projection nationale.
  2. Utilisez geography si vos données sont en latitude/longitude et que vous voulez une distance réelle en mètres sur la surface terrestre.
  3. Évitez geometry en 4326 pour des mesures métriques directes, sauf si vous savez précisément pourquoi vous manipulez des degrés.

Exemple SQL fondamental

Voici trois approches fréquentes pour un même segment. Elles sont très instructives car elles montrent que la valeur retournée dépend du contexte spatial:

SELECT ST_Length( ST_MakeLine( ST_SetSRID(ST_Point(2.3522, 48.8566), 4326), ST_SetSRID(ST_Point(4.8357, 45.7640), 4326) ) ) AS length_in_degrees; SELECT ST_Length( ST_MakeLine( ST_SetSRID(ST_Point(2.3522, 48.8566), 4326), ST_SetSRID(ST_Point(4.8357, 45.7640), 4326) )::geography ) AS length_in_meters; SELECT ST_Length( ST_Transform( ST_MakeLine( ST_SetSRID(ST_Point(2.3522, 48.8566), 4326), ST_SetSRID(ST_Point(4.8357, 45.7640), 4326) ), 3857 ) ) AS length_approx_mercator_meters;

Dans le premier cas, le résultat correspond à une longueur euclidienne en degrés. Dans le second, PostGIS mesure la distance géodésique sur le sphéroïde terrestre. Dans le troisième, la ligne est d’abord projetée en Web Mercator, ce qui donne une approximation en mètres utile pour de nombreux usages cartographiques, mais pas idéale pour la précision géodésique.

Tableau comparatif des approches les plus courantes

Méthode Type / SRID Unité retournée Niveau de précision Cas d’usage recommandé
ST_Length(geometry) EPSG:4326 Degrés Faible pour la distance réelle Contrôles topologiques, traitements angulaires, diagnostics techniques
ST_Length(geometry) Projection métrique locale, UTM, Lambert Mètres Élevé sur la zone adaptée Ingénierie, voirie, réseaux, analyses locales
ST_Length(geography) WGS84 géographique Mètres Très élevé pour les distances globales GPS, logistique multi-régions, calculs terrestres réalistes
ST_Length(ST_Transform(…, 3857)) EPSG:3857 Mètres approximatifs Moyen à variable selon latitude Cartographie web, dashboards, comparaisons visuelles rapides

Pourquoi Web Mercator peut introduire des écarts

EPSG:3857, appelé Web Mercator, est omniprésent dans les applications web. Il est très pratique pour afficher des tuiles cartographiques et manipuler une carte interactive, mais il n’a pas été conçu comme projection universelle de mesure précise. Les déformations augmentent quand on s’éloigne de l’équateur. Cela signifie qu’une longueur mesurée directement en 3857 peut devenir moins représentative de la distance réelle, surtout à haute latitude.

Pour un tableau de bord web, cette approximation peut suffire. Pour un calcul de facturation kilométrique, une distance de conformité réglementaire, une analyse environnementale ou un calcul d’emprise d’infrastructure, il est préférable d’utiliser geography ou une projection locale conçue pour la zone d’étude.

Statistiques réelles: longueur d’un degré de longitude selon la latitude

Les chiffres ci-dessous montrent pourquoi il est dangereux d’interpréter des degrés comme des mètres. La longueur d’un degré de longitude varie fortement selon la latitude terrestre, alors qu’un degré de latitude reste proche de 111 km avec de légères variations.

Latitude Longueur approximative de 1 degré de longitude Longueur approximative de 1 degré de latitude Observation pratique
111,32 km 110,57 km À l’équateur, longitude et latitude sont de grandeur proche
30° 96,49 km 110,85 km La longitude commence à se contracter nettement
45° 78,85 km 111,13 km Cas typique de l’Europe tempérée
60° 55,80 km 111,41 km Écart très important entre les deux axes
80° 19,39 km 111,66 km Interpréter un degré comme une distance uniforme devient absurde

Ces valeurs sont cohérentes avec les modèles géodésiques couramment utilisés et illustrent une réalité importante: une distance angulaire ne peut pas être traduite directement en distance métrique uniforme sans contexte géographique. C’est pour cette raison que ST_Length(geometry en 4326) ne doit pas être utilisé comme substitut de kilométrage.

Bonnes pratiques pour un calcul fiable

  • Stockez clairement le SRID de toutes vos colonnes spatiales.
  • Vérifiez le type de colonne: geometry ou geography.
  • Si vous travaillez en GPS natif, privilégiez ::geography pour la distance réelle en mètres.
  • Si vous avez un périmètre local, choisissez une projection métrique adaptée avant d’utiliser ST_Length.
  • Évitez de mesurer directement en EPSG:3857 pour des décisions critiques de précision.
  • Documentez dans votre code et votre documentation métier l’unité de sortie attendue.

Exemple concret de workflow professionnel

Imaginons une entreprise de maintenance ferroviaire qui stocke ses tracés en WGS84 parce qu’ils proviennent d’équipements GPS et de services web. L’équipe veut calculer la longueur de chaque tronçon pour planifier les interventions. Le mauvais réflexe serait d’appliquer ST_Length directement sur la géométrie 4326 et de considérer la sortie comme des kilomètres. Le bon workflow est le suivant:

  1. Créer ou vérifier la ligne en WGS84.
  2. Si le réseau est national ou international, caster la ligne en geography.
  3. Appliquer ST_Length pour obtenir des mètres réels.
  4. Convertir ensuite en kilomètres pour l’affichage métier.
  5. Si des analyses locales plus fines sont nécessaires, transformer vers une projection locale de haute qualité et comparer les résultats.

Cette démarche garantit une cohérence entre la donnée source, le moteur de calcul et les besoins opérationnels. Elle réduit aussi les erreurs d’interprétation dans les tableaux de bord, exports CSV, rapports PDF et API métiers.

Différence entre une distance “droite” et une longueur de polyligne

Un autre point important concerne la forme de l’objet. ST_Length renvoie la longueur de la géométrie telle qu’elle est stockée. Pour un simple segment entre deux points, le calcul correspond à la distance entre ces extrémités. Pour une polyligne composée de plusieurs sommets, la longueur est la somme des segments successifs. Si votre route suit des virages, sa longueur sera naturellement supérieure à la distance “à vol d’oiseau”.

Cela signifie que la qualité du résultat dépend aussi de la qualité de la géométrie. Une ligne trop simplifiée peut sous-estimer la longueur réelle d’une infrastructure sinueuse. Une ligne trop bruitée peut, à l’inverse, surévaluer la longueur à cause d’oscillations GPS ou de segments parasites.

Ressources institutionnelles utiles

Pour approfondir les bases géodésiques et les systèmes de coordonnées, consultez des sources fiables et durables. Voici trois références sérieuses:

  • USGS.gov pour les fondamentaux cartographiques, la géographie et les données terrestres.
  • NOAA.gov pour les notions géodésiques, les référentiels et les observations de la Terre.
  • Penn State .edu pour des contenus universitaires sur les projections, SIG et systèmes de coordonnées.

Questions fréquentes

ST_Length retourne-t-il toujours des mètres ? Non. Sur geography, oui, en général en mètres. Sur geometry, le résultat est exprimé dans l’unité du système de coordonnées de la géométrie.

Puis-je utiliser EPSG:3857 pour tous les calculs ? Vous pouvez, mais ce n’est pas conseillé pour les mesures de précision, surtout à moyenne ou haute latitude.

Quelle est la méthode la plus simple pour des coordonnées GPS ? Convertir ou caster en geography, puis utiliser ST_Length.

Pourquoi mon résultat semble faux ? Dans la majorité des cas, l’erreur provient d’un SRID mal défini, d’une confusion geometry/geography ou d’une lecture incorrecte de l’unité de sortie.

Conclusion

Le calcul longueur PostgreSQL ST_Length n’est fiable que si l’on maîtrise le contexte géospatial complet. La fonction est excellente, mais elle ne peut pas corriger à votre place un mauvais choix d’unité ou de projection. Retenez la règle essentielle: geometry mesure dans l’unité de la projection, geography mesure en mètres sur la Terre. Si vous gardez cette logique, vous éviterez la plupart des erreurs les plus coûteuses dans les applications PostGIS.

Utilisez le calculateur ci-dessus pour comparer rapidement les résultats selon plusieurs approches. C’est une manière très concrète de voir comment les écarts apparaissent, pourquoi ils existent, et quelle méthode doit être utilisée dans votre cas métier.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top