Requete postgis => résultat incohérent

[Tioneb]

Salut,

Je fais mes tests de requête notamment pour trouver la distance entre un point A et B situé de part et d'autre d'une linestring. La voici :

Code : Tout sélectionner

@test_distance = Track.find_by_sql(
      ["SELECT
        ST_Distance(line, pta) AS dst_pdd,
        ST_Distance(line, ptb) AS dst_pda,
        ST_Length(ST_LineSubstring(
            line,
            least(ST_Line_Locate_Point(line, pda), ST_Line_Locate_Point(line, pdd)),
            greatest(ST_Line_Locate_Point(line, pda), ST_Line_Locate_Point(line, pdd)))::geography)  AS dst_line
        FROM (
          SELECT
            'SRID=4326;LINESTRING(1.457834243774414 43.597960902821576,1.462029218673706 43.59636807591895)'::geometry line,
            'SRID=4326;POINT(1.457994 43.598124)'::geometry pdd,
            'SRID=4326;POINT(1.461628 43.596128)'::geometry pda
        ) data"
      ])

J'ai découpé la requête pour mieux comprendre le résultat. Le résultat que j'obtiens est vraiment très loin de ce que j'attends

dst_line = 349.69641324941
dst_pdd = 0.000209184746207263
dst_pda = 0.000366862736795735

J'ai simulé sur google maps le même trajet (https://goo.gl/maps/M3nrmVRstUK2) et j'obtiens environ un total de 400 mètres détaillés comme suit :

dst_line = 350 m
dst_pdd = 23 m
dst_pda = 38 m

Les deux dernières valeurs semblent assez proches si l'on fait l'impasse des virgules et des zéros : On aurait 20,91 et 36,68... pourtant ST_distance est censé retourner une valeur en mètres. Même chose pour ST_length mais avec cette fois un résultat cohérent.

D'après la doc postgis ST_Line_Locate_Point retourne "as a fraction of total 2d line length" et un float, j'avoue que je ne comprends pas trop ce que ça retourne vraiment. Si quelqu'un peut m'expliquer...

Question subsidiaire , est ce que je peux utiliser des opérateurs directement dans la requête pour par exemple additionner dst_line, dst_pdd, dst_pda, si oui comment ?

[cquest]

Normal... tu travaille en données sphériques (4326=WGS84=degrés sur le globe terrestre) pour calculer dst_pdd et dst_pda

Donc les distances retournées sont des "degrés" et totalement inutilisables.

Pour le dst_line tu as basculé tes geometry en geography et donc le calcul de longueur se fait après projection plane, et retourne des metres

ST_Distance(line, pta) AS dst_pdd -> ST_Distance(line::geography, pta::geography) AS dst_pdd
ST_Distance(line, ptb) AS dst_pda -> ST_Distance(line::geography, ptb::geography) AS dst_pda

Et ça devrait être cohérent.

[Tioneb]

Ben oui... c'est tellement évident après une nuit de repos Merci.

Sinon, il y a moyen de faire l'addition des 3 résultats avec deux chiffres après la virgule directement dans la requête ou je dois le gérer coté front ?

[cquest]

SELECT round(ST_Distance(...) + ST_Distance(...) + ST_Length(...) , 2) ...

[Tioneb]

C'est ce que j'ai fais, l'addition passe bien... le round beaucoup moins. Mais finalement ce n'est pas un problème, je le gère au niveau du front en fonction du résultat

[Tioneb]

Pour avoir plus de précision dans mes calculs de distances, j'ai intégré l'altitude dans les données des linestring.

J'ai donc voulu modifier ma fonction en conséquence.... :

Code : Tout sélectionner

def distance_to(poi2, way)
  distance_sql = <<-SQL
    SELECT
      ST_3DDistance(way.path, pta.lonlat::geometry) +
      ST_3DDistance(way.path, ptb.lonlat::geometry) +
      ST_Length(ST_LineSubstring(
        way.path,
        least(ST_LineLocatePoint(way.path, pta.lonlat::geometry), ST_LineLocatePoint(way.path, ptb.lonlat::geometry)),
        greatest(ST_LineLocatePoint(way.path, pta.lonlat::geometry), ST_LineLocatePoint(way.path, ptb.lonlat::geometry)))::geography)  AS dst_line
     FROM ways way, pois pta, pois ptb
     WHERE way.id = #{way.id}
       AND pta.id = #{self.id}
       AND ptb.id = #{poi2.id}
  SQL
  Poi.find_by_sql(distance_sql).first.dst_line
end

et là patatra

Visiblement ST_LineLocatePoint ne fonctionne qu'avec les lignes 2D et ST_3DDistance attend des geography

J'ai regardé s'il y avait une fonction équivalente avec la 3D, mais j'ai rien trouvé.

Comment puis je contourner le problème ?

[cquest]

Pour avoir plus de précision dans mes calculs de distances, j'ai intégré l'altitude dans les données des linestring.

Le mieux est l'ennemi du bien

Je resterai en 2D pour les calculs de distance "à plat", puis j'ajouterai le pouillème de distance supplémentaire liée au relief.

En considérant que localement on est "à plat", si je ne me trompe pas ça donne: d_relief = sqrt(d_plat^2 + diff_alti^2)

Il faut déjà avoir de belle pente pour que ça ne soit pas négligeable, avec du 6%, ça ne fait que 1,8m de plus sur 1km !

[Tioneb]

Je pensais que l'écart pouvait être plus important.

Au final, sur une étape de 20 km, avec un dénivellé de 6% l'erreur serait donc de seulement 40 mètres ? Suis supris, vais faire quelques tests dans ce sens.

Mais si tel est le cas, vais pas trop me casser la tête