|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||||
|
Membre éprouvé
![]() |
Bonjour à tous,
J'utilise PostgreSQL pour stocker des données géographiques et pgRouting pour calculer des itinéraires. Vous pouvez trouver les sources (super simple à lire) de pgRouting ici pgRouting, greffé à postgresql, utilise boost graph pour exécuter les divers algorythmes qu'il propose (Dijkstra, A* etc.). Un calcul d'itinéraire basé sur 3731571 segments, met 2 à 4 secondes à s'exécuter, tout compris, depuis le chargement des données du graphe, jusqu'à l'exécution de la recherche, en passant par la construction du graph boost. Le problème, c'est qu'à chaque fois que l'on a besoin de calculer un itinéraire, on envoie à la librairie une requête SQL permettant de "sélectionner le graph", puis le module l'exécute, construit le graph et agit dessus. Or, j'ai besoin de calcul d'itinéraire en masse, sur le même graph. Alors j'ai repris les sources, j'ai fait un service, qui au démarrage sélectionne les données et construit le graph, afin qu'une fois démarré, il n'y au plus qu'à "taper dedans". Ça commence par ceci : Code :
Code :
Ensuite vient le remplissage de graph, une série d'instructions comme ceci : Code :
La seule différence, c'est que mon serveur PostgreSQL tourne sous linux, et les plugins viennent des dépôts linux, alors que mon service, tourne sous Windows, avec boost compilé sous Windows. Pourquoi est-ce que c'est si long de mon côté, pour construire ce graph boost, et que c'est si rapide, sur le serveur ? Aurait-je loupé quelque chose dans la compilation de boost, ou un flag quelque part ? Merci pour votre aide, A bientôt
__________________
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero |
||||||
|
|
00
|
|
|
#2 |
|
Membre éprouvé
![]() |
Trouvé !
Au départ mon graph est une suite de segments de deux points. J'applique une routing qui va positionner un identifiant de "début" et "fin" de chaque segments. A ce stade, un virage sur une route unique peut contenir une dizaine de segments. J'ai donc simplifié le graph pour éliminer tous les points ne faisant que relier un segment à un autre, en mettant à jour les données calculées (distance, temps et géométrie). Au final, je me retrouve avec un graph réduit, mais les identifiants "départ/fin" sont conservés à l'original pour les segments "qui restent". Or, boost considère que les identifiants sont contiguës et qu'il n'y a pas de "trou". Ainsi, si on lui envoie un segment avec un identifiant de vertex "50.000", il considère qu'il y aura au moins 50.000 vertex dans le graph, et cherche à ré allouer la mémoire, ce qui le fait peiner lors des premiers ajouts, puis le fait crasher par la suite, dans la démesure. La solution a été de réindexer les index de début/fin des segments, devenus tronçons. Résultat, sur un PC de particulier, l'algo A* calcul 30 à 40 calcul d'itinéraire, sur la France entière, par seconde Problème résolu
__________________
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero |
|
|
00
|
Copyright © 2000-2013 - www.developpez.com