Le portail francophone de la géomatique

En creusant je me suis rendu compte que ce n'etait pas pgrouting qui me faisait perdre du temps entre postgres 9.1 et 9.5.
Comme certains jeux de donnees etaient volumineux, le code avait ete optimise pour travailler par zone.
Le graphe etait construit sur l'ensemble du jeu de donnees mais ensuite il y avait une selection par intersection spatiale avec une couche de polygones pour ne travailler que par zone.
C'est cette requete d'intersection spatiale qui en passant de postgres 9.1 a 9.5 prenait plus de temps.

La requete spatiale etait du type

select mon_routing.edge_id,mon_routing.id,mon_routing.source,mon_routing.target,mon_routing.cost,mon_routing.iti,mon_routing.the_geom 
from mon_routing , mes_zones
where ST_Buffer(mes_zones.the_geom, 1000) && mon_routing.the_geom 
  and ST_Intersects(mon_routing.the_geom,ST_Buffer(mes_zones.the_geom, 1000)) IS TRUE 
  and mes_zones.zone_id = '1'

J'ai reecrit la requete de la facon suivante:

select mon_routing.edge_id,mon_routing.id,mon_routing.source,mon_routing.target,mon_routing.cost,mon_routing.iti,mon_routing.the_geom 
from mon_routing , mes_zones
where mes_zones.zone_id = '1'
  and st_dwithin(mes_zones.geom, mon_routing.geom, 1000)

Et j'ai gagne un temps phenomenal en 9.5 et aussi en 9.1
Par contre je ne sais pas pourquoi la requete d'origine prenait plus de temps en 9.5 qu'en 9.1
(Il faudrait peut-etre modifier le titre du sujet)

Concernant l'algorithme le plus adapte pour mon jeu de donnees, mes donnees sont assez simple.
Il s'agit d'un reseau FTTH. En general, il n'y a qu'un seul itineraire possible par couple [origine, destination].

Dernière modification par guil31 (Mon 26 August 2019 17:17)