#1 Tue 14 February 2012 09:28
- lafeelilie
- Juste Inscrit !
- Lieu: Nantes
- Date d'inscription: 11 May 2011
- Messages: 5
- Site web
Pgrouting temps de calcul
Bonjour à tous,
Alors je tente de mettre en place un applicatif web permettant d'effectuer du calcul d'itinéraire à la mode 3Liz http://demo.3liz.fr/montpellier.
J'utilise les données openstreetmap, le client openlayers, et le SGBD postgresql/postgis/pgrouting.
Dans ma version démo j'avais restreint les données à la Loire Atlantique et j'avais des temps de réponse corrects.
J'ai voulu augmenter mon réseau routier au niveau france entière et là catastrophe, la requête est trop lourde pour postgresql ... Il n'arrive pas à calculer. Alors je suis un peu étonnée car les applicatifs de routing que j'ai pu trouver en ligne et utilisant pgrouting ont des temps de réponse plus que respectables... (ex: http://openrouteservice.org/)
Savez vous quelles sont les techniques d'optimisation de pgrouting pour pouvoir calculer des temps de trajets dans des délais raisonnables.
Merci d'avance!
Hors ligne
#2 Tue 14 February 2012 12:28
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
Bonjour à tous,
Alors je tente de mettre en place un applicatif web permettant d'effectuer du calcul d'itinéraire à la mode 3Liz http://demo.3liz.fr/montpellier.
J'utilise les données openstreetmap, le client openlayers, et le SGBD postgresql/postgis/pgrouting.
Dans ma version démo j'avais restreint les données à la Loire Atlantique et j'avais des temps de réponse corrects.
J'ai voulu augmenter mon réseau routier au niveau france entière et là catastrophe, la requête est trop lourde pour postgresql ... Il n'arrive pas à calculer. Alors je suis un peu étonnée car les applicatifs de routing que j'ai pu trouver en ligne et utilisant pgrouting ont des temps de réponse plus que respectables... (ex: http://openrouteservice.org/)
Savez vous quelles sont les techniques d'optimisation de pgrouting pour pouvoir calculer des temps de trajets dans des délais raisonnables.
Merci d'avance!
Bonjour,
IL y a hélas beaucoup de paramètres qui entrent en jeu pour optimiser pg/pgrouting.
Quelle est la configuration du serveur Postgresql ? os, versions de PG + Postgis, disques durs, ram.
Par défaut, la configuration de postgresql est assez minimaliste en terme de ressource mémoire affectée a PG.
Il faut la modifier pour utiliser au mieux les ressources du serveur.
Les données du routing peuvent être mises sur un disque dur très rapide également (style SSD et/ou montage RAID).
La table contenant les données est bien indexée sur les champs utilisés par le routing ?
Un vacuum analyse a été lancé sur cette table apres les insertions/mises a jour ?
Nicolas
Dernière modification par Nicolas Ribot (Tue 14 February 2012 12:40)
Hors ligne
#3 Tue 14 February 2012 17:24
- icadedt
- Participant assidu
- Lieu: ici et là
- Date d'inscription: 21 Jul 2006
- Messages: 478
Re: Pgrouting temps de calcul
Bonjour à tous,
Alors je tente de mettre en place un applicatif web permettant d'effectuer du calcul d'itinéraire à la mode 3Liz http://demo.3liz.fr/montpellier.
J'utilise les données openstreetmap, le client openlayers, et le SGBD postgresql/postgis/pgrouting.
Dans ma version démo j'avais restreint les données à la Loire Atlantique et j'avais des temps de réponse corrects.
J'ai voulu augmenter mon réseau routier au niveau france entière et là catastrophe, la requête est trop lourde pour postgresql ... Il n'arrive pas à calculer. Alors je suis un peu étonnée car les applicatifs de routing que j'ai pu trouver en ligne et utilisant pgrouting ont des temps de réponse plus que respectables... (ex: http://openrouteservice.org/)
Savez vous quelles sont les techniques d'optimisation de pgrouting pour pouvoir calculer des temps de trajets dans des délais raisonnables.
Merci d'avance!
j'aimerais savoir comment vous avez fait pour avoir les temps de parcours sur les troncons de route
Hors ligne
#4 Mon 19 March 2012 13:13
- guibsou
- Participant occasionnel
- Date d'inscription: 1 Aug 2006
- Messages: 28
Re: Pgrouting temps de calcul
Bonjour,
je voudrais rebondir sur ce sujet car je rencontre actuellement un probleme similaire sur des temps de reponses de la fonction shortest_path().
J'ai compilé l'ensemble des dernieres sources pour le routing sur une debian squeeze 64bits virtualisée avec openVZ à 4Go de RAM sur un serveur dédié Intel i5 à 3.1GHz (4 coeurs)
postgresql 9.1
postgis 1.5.3 (avec geos 3.3.2 et proj 4.8)
pgrouting 1.05 (avec libboost en paquet, cgal 3.9, gaul-devel 0.1849)
j'ai intégré les données OSM de la france à l'aide de l'outils osm2po.
et j'ai indexé les champs pris en compte lors de la requete shortest_path() (source, target, cost, reverse_cost et la clé primaire) + vacuum full analyze
je me retrouve avec une table comportant un graphe de 3 800 000 enregistrements
lors de l'execution de mes requetes , je me retrouve avec un temps de reponses avoisinant les 4 secondes.
le temps est le meme que se soit entre deux rues voisines ou entre deux rues dans des villes totalement opposées en france.
J'ai tenté des modifications dans postgres :
shared_memory
maintenance_work_mem
checkpoint_segments
stopper autovacuum
j'ai aussi tenté d'augmenter de modifier le kernel.shmmax dans les parametres du systeme
mais rien de ces changements ne changent mes temps de reponses.
Est-ce une limite CPU qui m'empeche de gagner en performance ?
Y a t'il un parametrage particulier que je n'aurai pas activé ?
Existe t-il une possibilité d'optimiser l'algorythme dans les sources de la librairie de routing ?
Le processus declenché par le routing ne semble pas être multithread (malgré une version 64bits de l'OS). le probleme de lenteur pourrait-il venir de là ?
bref, si vous pouvez m'eclairer à ce sujet.
cordialement,
Hors ligne
#5 Mon 19 March 2012 15:45
Re: Pgrouting temps de calcul
En lisant http://workshop.pgrouting.org/chapters/ … _path.html je remarque :
- Il y a trois fonction de calculs, selon l’algorithme utilisé. Toujours utile ce genre de chose. On devrait faire ça pour toutes les fonctions d'un logiciel, trois croix pour fermer une fenêtre
- Pour chaque fonction il y a la possibilité de définir le rectangle d'encombrement.
qu'on peut définir pour chaque fonction
À lire http://gis.stackexchange.com/questions/ … -for-speed je remarque :
- Des actions simples et habituelles comme l'index ne sert pas vraiment.
- Les mesures d'optimisation ne sont pas immédiates.
- On découvre le problème depuis peu.
- pgRouting n'est pas fait pour être utilisé, malgré ses trois algorithmes différents.
J'avoue n'avoir jamais pratiqué ce genre de chose, mais la recherche d'itinéraire me semble être un problème assez classique en informatique. Je suis sidéré de voir la roue réinventé dans ce genre de projets. D'un autre côté, ça reste une implémentation libre, qui a le mérite d'exister. Mais doit-on découvrir ces problèmes de performance lors de la mise en charge de la BDD ?
Dernière modification par Jeirhome (Mon 19 March 2012 18:43)
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#6 Mon 19 March 2012 16:27
Re: Pgrouting temps de calcul
Jérôme,
À lire http://gis.stackexchange.com/questions/ … -for-speed on remarque :
[..]
- On découvre le problème depuis peu.
- pgRouting n'est pas fait pour être utilisé, malgré ses trois algorithmes différents.
C'est une interprétation qui n'est que la tienne ! Peux tu, au moins, me citer le message du lien que tu données qui te permet d'affirmer que "pgRouting découvre depuis peu les problèmes de performances et qu'il n'est pas fait pour être utilisé malgré blablabal"
Merci,
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#7 Mon 19 March 2012 16:33
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
Bonjour,
je voudrais rebondir sur ce sujet car je rencontre actuellement un probleme similaire sur des temps de reponses de la fonction shortest_path().
J'ai compilé l'ensemble des dernieres sources pour le routing sur une debian squeeze 64bits virtualisée avec openVZ à 4Go de RAM sur un serveur dédié Intel i5 à 3.1GHz (4 coeurs)
postgresql 9.1
postgis 1.5.3 (avec geos 3.3.2 et proj 4.8)
pgrouting 1.05 (avec libboost en paquet, cgal 3.9, gaul-devel 0.1849)
j'ai intégré les données OSM de la france à l'aide de l'outils osm2po.
et j'ai indexé les champs pris en compte lors de la requete shortest_path() (source, target, cost, reverse_cost et la clé primaire) + vacuum full analyze
je me retrouve avec une table comportant un graphe de 3 800 000 enregistrements
lors de l'execution de mes requetes , je me retrouve avec un temps de reponses avoisinant les 4 secondes.
le temps est le meme que se soit entre deux rues voisines ou entre deux rues dans des villes totalement opposées en france.
J'ai tenté des modifications dans postgres :
shared_memory
maintenance_work_mem
checkpoint_segments
stopper autovacuum
j'ai aussi tenté d'augmenter de modifier le kernel.shmmax dans les parametres du systeme
mais rien de ces changements ne changent mes temps de reponses.
Est-ce une limite CPU qui m'empeche de gagner en performance ?
Y a t'il un parametrage particulier que je n'aurai pas activé ?
Existe t-il une possibilité d'optimiser l'algorythme dans les sources de la librairie de routing ?
Le processus declenché par le routing ne semble pas être multithread (malgré une version 64bits de l'OS). le probleme de lenteur pourrait-il venir de là ?
bref, si vous pouvez m'eclairer à ce sujet.
cordialement,
Bonjour,
Je commence par la fin
Postgresql n'est pas multithread. Une connexion = un thread. Si plusieurs connexions sont ouvertes, alors plusieurs threads tournent.
Donc effectivement les differents coeurs du CPU ne sont pas utilisés pour le calcul d'une route.
Concernant les parametres du fichier de conf, c'est assez delicat de savoir quel parametre toucher et quelle valeur lui mettre.
Clairement, vous devez faire en sorte que shared_memory soit assez grand pour faire tenir le graphe en memoire, pour eviter les entrees/sorties, qui sont tres lentes comparées au travail en memoire:
Pour cela, vous devriez avoir un coeur a 100% de CPU pendant le routing. Moins, ca veut dire que le systeme attend des données. (enfin je crois )
Ensuite, si les requetes de routing font un classement des resultats (distinct, order by, UNION, etc.), alors il faut augmenter le parametres WORK_MEM, qui est la memoire utilisée pour ces classements.
Ce parametre peut etre changé en live avant une requete, pour tester.
Il se peut aussi que le routing soit plus rapide si la table contenant les données est deja présente en mémoire.
Nicolas
Hors ligne
#8 Mon 19 March 2012 16:48
Re: Pgrouting temps de calcul
En lisant http://workshop.pgrouting.org/chapters/ … _path.html on remarque :
- Il y a trois fonction de calculs, selon l’algorithme utilisé. Toujours utile ce genre de chose. On devrait faire ça pour toutes les fonctions d'un logiciel, trois croix pour fermer une fenêtre
- Pour chaque fonction il y a la possibilité de définir le rectangle d'encombrement.
qu'on peut définir pour chaque fonction
À lire http://gis.stackexchange.com/questions/ … -for-speed on remarque :
- Des actions simples et habituelles comme l'index ne sert pas vraiment.
- Les mesures d'optimisation ne sont pas immédiates.
- On découvre le problème depuis peu.
- pgRouting n'est pas fait pour être utilisé, malgré ses trois algorithmes différents.
J'avoue n'avoir jamais pratiqué ce genre de chose, mais la recherche d'itinéraire me semble être un problème assez classique en informatique. Je suis sidéré de voir la roue réinventé dans ce genre de projets. D'un autre côté, ça reste une implémentation libre, qui a le mérite d'exister. Mais doit-on découvrir ces problèmes de performance lors de la mise en charge de la BDD ?
La recherche d'itinéraire n'est pas «un problème classique». Au mieux ce sont «des problèmes classiques». Il s'agit par nature d'un problème NP-complet, c'est à dire qui possède une explosion combinatoire (exponentielle) des résultats selon la taille du réseau. Tant qu'on ne saura pas si P=NP on aura des soucis pour résoudre ce genre de problème.
La recherche d'itinéraire peut avoir de très nombreuses variantes. Quelques paramètres parmi d'autres :
- taille du réseau
- couts fixes ou dynamiques ?
- réseau orienté ou non ?
- restrictions de circulation ?
- géographie disponible ou non ?
- multimodal ou réseau simple ?
- feuille de route ?
- solution exacte ou approchée ?
- une seule solution ou plusieurs ?
- optimisation suivant un seul ou des critères ?
- ....
On peut aussi chercher le problème du voyageur de commerce, des isochrones, de l'optimisation de flotte, etc etc. Il y a plusieurs algorithmes dans PgRouting, non pas pour créer intentionnellement de la confusion, mais pour répondre à différents sous-types de problèmes avec des caractéristiques différentes.
Donc non on ne réinvente certainement pas la roue à chaque fois. Ce domaine est en recherche permanente (voir les travaux du fraunhofer, de bing, osmr, de l'iffstar, etc), et il n'y a pas un seul problème ni une seule solution générique pour chaque problème.
PgRouting a l'avantage d'être directement connecté à la base de donnée. Il est «fait pour être utilisé» (sic !), et fonctionne sur des bases conséquentes, avec les bonnes optimisations.
Ceci étant dit, PgRouting souffre d'erreurs de conceptions. Pour pouvoir améliorer ses performances il faut connaitre son fonctionnement. C'est globalement le suivant à chaque appel :
- appel d'une fonction de haut niveau de PgRouting (shortest_path par exemple)
- On lui passe en paramètre une requête SQL, qui renvoie un réseau topologique
- PgRouting exécute cette requête, récupère le réseau (et les coûts)
- Il convertit les résultats de la requête en un format utilisable dans les algorithmes de graphe de Boost
- Il lance l'algo de boost correspondant
- Il récupère les résultats de boost
- Il crée une sortie au format PostgreSQL
- Il renvoie cette sortie
Ce qu'on peut voir là dedans, c'est qu'il y a à chaque appel un chargement du graphe résultant de la requête SQL paramétre, en mémoire dans Boost, à partir de la base de donnée. C'est là que doit se faire l'optimisation, sinon on va charger systématiquement la base entière.
Pour optimiser, il faut passer le graphe le plus petit possible. C'est à dire restreindre le graphe par une préestimation du trajet. Cela peut se faire de diverses manières :
- par une bounding box (peu efficace dans le cas de trajets longs et en «diagonale»)
- par une ellipse autour du trajet en ligne droite (ce qui est fait en général, assez efficace)
- par un calcul préalable sur un sous-réseau
Comme on fait des requêtes géographiques ici, l'indexation est nécessaire et performante.
La dernière possibilité est en général celle qui amène à des bonnes performances : on ne fait pas un seul appel de routing, mais plusieurs, sur des réseaux à différentes échelles. On fait un premier itinéraire plus global sur des nationales par exemple, et on fait les itinéraires du point de départ vers les accès aux nationales dans un second temps. Pareil pour les autoroutes. On peut faire la même chose sur N niveaux.
La vraie solution consisterait à avoir un réseau complet en mémoire sur lequel toutes les requêtes s'exécutent. C'est ce que fait graphserver par exemple. Mais dans ce cas c'est découplé de la base de données, ce qui a des inconvénients aussi.
A noter au passage que PostgreSQL est multi-processus, mais pour une requête on n'a qu'un seul processus de lancé. On sera donc plus efficace sur beaucoup de petites requêtes simultanées que sur peu de grosses requêtes de routing.
En résumé, c'est pas simple !
Le premier travail à faire est d'identifier le goulot d'étranglement. Est ce que le problème vient dans la taille du réseau passé à PgRouting, ou bien de la performance des algorithmes ?
En général c'est la première solution, et dans ce cas la stratégie est d'abord dépendante des contraintes fonctionnelles, ensuite on teste les différentes stratégies ci-dessus qui correspondent, et enfin c'est de l'optimisation de base de données, mais pas de façon aléatoire.
On touche aux paramètres de configuration une fois qu'on sait à peu près comment on doit les changer, et ça passe par l'analyse des requêtes : EXPLAIN sur le SQL, vérification des indexes, optimisation des requêtes (jointures, filtres, filtres spatiaux, etc). Puis optimisations matérielles : SSD, RAM, Partitionnement, etc.
J'espère que ça rétablit un peu de clarté dans vos démarches. Bon courage !
Hors ligne
#9 Mon 19 March 2012 18:09
- guibsou
- Participant occasionnel
- Date d'inscription: 1 Aug 2006
- Messages: 28
Re: Pgrouting temps de calcul
Bonjour Messieurs,
Merci pour vos reponses pertinentes et votre rapidité !
Je vais donc tenter vos solutions et voir les differences sur :
le stockage en ram de la base
la limitation du graphe contenu dans une ellipse englobant les 2 points
le "splitage" du graphe en plusieurs "sous-graphe" avec calcul au prealable
Apres reflexion, je suis d'accord pour penser que la derniere solution soit la meilleure, mais est, sans aucun doute, la plus lourde à mettre en oeuvre.
bonne soirée.
cordialement,
Hors ligne
#10 Mon 19 March 2012 19:01
Re: Pgrouting temps de calcul
PgRouting a l'avantage d'être directement connecté à la base de donnée. Il est «fait pour être utilisé» (sic !), et fonctionne sur des bases conséquentes, avec les bonnes optimisations.
Ceci étant dit, PgRouting souffre d'erreurs de conceptions. Pour pouvoir améliorer ses performances il faut connaitre son fonctionnement
Merci vincent pour cette précision, tu me rassures dans mon constat. Et encore merci, cette fois pour ces pistes sérieuses sur l'optimisation du serveur d'itinéraire.
la limitation du graphe contenu dans une ellipse englobant les 2 points
A priori une ellipse englobante doit être assez difficile à configurer :
- Le meilleur itinéraire de banlieue à banlieue va souvent passer par le périphérique de l'agglomération, et donc l'itinéraire sera très fortement élargie (et même dans des cas où le rectangle englobant est très étroit (départ / destination dans axe nord / sud ou est / ouest) ça risque d'être tendu).
- À proximité d'une extrémité, on peut s'éloigner de la destination afin de rejoindre la voie la plus rapide.
- Le réseau d'autoroute s'approche des agglomérations du pays, quitte à faire quelques zigzags.
Ça risque d'être triste si pour des raisons d'optimisations le trajet nous invite à rallonger notre voyage
Précautions à prendre !!!
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#11 Mon 19 March 2012 19:51
Re: Pgrouting temps de calcul
Bonsoir,
Ça risque d'être triste si pour des raisons d'optimisations le trajet nous invite à rallonger notre voyage
Ca dépend de ce que l'on entend par optimisation : distance, temps, coût, trajet, ... ?
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#12 Mon 19 March 2012 20:11
Re: Pgrouting temps de calcul
vincentp a écrit:Ceci étant dit, PgRouting souffre d'erreurs de conceptions. Pour pouvoir améliorer ses performances il faut connaitre son fonctionnement
Merci vincent pour cette précision, tu me rassures dans mon constat.
Heu l'idée c'était plutôt de dire que c'était une bonne solution qui fonctionnait, faut juste savoir de quoi on parle. Dans ce domaine il n'y a pas de solution boite dès qu'on dépasse certains volumes et un cadre fonctionnel très contraint.
la limitation du graphe contenu dans une ellipse englobant les 2 points
A priori une ellipse englobante doit être assez difficile à configurer :
- Le meilleur itinéraire de banlieue à banlieue va souvent passer par le périphérique de l'agglomération, et donc l'itinéraire sera très fortement élargie (et même dans des cas où le rectangle englobant est très étroit (départ / destination dans axe nord / sud ou est / ouest) ça risque d'être tendu).
- À proximité d'une extrémité, on peut s'éloigner de la destination afin de rejoindre la voie la plus rapide.
- Le réseau d'autoroute s'approche des agglomérations du pays, quitte à faire quelques zigzags.
L'ellipse peut être aussi modifiée, en fonction de la densité de voirie par exemple aussi. Mais c'est pour ces cas là notamment que l'approche multi-échelle est plus efficace.
Hors ligne
#13 Mon 19 March 2012 20:11
Re: Pgrouting temps de calcul
Ça dépend juste du sujet. Ici le sujet est "Pgrouting temps de calcul". L'optimisation envisagée est donc... le "temps de calcul".
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#14 Mon 19 March 2012 20:34
Re: Pgrouting temps de calcul
Heu l'idée c'était plutôt de dire que c'était une bonne solution qui fonctionnait, faut juste savoir de quoi on parle. Dans ce domaine il n'y a pas de solution boite dès qu'on dépasse certains volumes et un cadre fonctionnel très contraint.
Exactement ce que je dis, car là nous sommes moins dans une situation RTFM (va voir la doc), que dans une situation RTFSC (va voir comment c'est fait).
Malheureusement même si PgRouting est le sujet ici, ce n'est pas le seul à offrir un fonctionnement idéal dans des cadres de démonstration, avec de petites quantités de données, et à se dégrader dès qu'on essaye de généraliser peu à peu son utilisation. Même si avoir une solution prêt à l'emploi n'est pas aisée, connaitre les limites d'un logiciel pourrait être sympathique.
Mais on dépasse un peu le cadre du sujet...
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#15 Mon 19 March 2012 21:22
Re: Pgrouting temps de calcul
Exactement ce que je dis, car là nous sommes moins dans une situation RTFM (va voir la doc), que dans une situation RTFSC (va voir comment c'est fait).
Si c'est ce que vous dites, c'est parfait alors.
Hors ligne
#16 Tue 20 March 2012 09:57
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
Heu l'idée c'était plutôt de dire que c'était une bonne solution qui fonctionnait, faut juste savoir de quoi on parle. Dans ce domaine il n'y a pas de solution boite dès qu'on dépasse certains volumes et un cadre fonctionnel très contraint.
Exactement ce que je dis, car là nous sommes moins dans une situation RTFM (va voir la doc), que dans une situation RTFSC (va voir comment c'est fait).
Malheureusement même si PgRouting est le sujet ici, ce n'est pas le seul à offrir un fonctionnement idéal dans des cadres de démonstration, avec de petites quantités de données, et à se dégrader dès qu'on essaye de généraliser peu à peu son utilisation. Même si avoir une solution prêt à l'emploi n'est pas aisée, connaitre les limites d'un logiciel pourrait être sympathique.
Mais on dépasse un peu le cadre du sujet...
Une petite precision concernant le fonctionnement de pgRouting en mode demo ou prod.
Du temps de sa sortie, Orkney, la boite japonaise qui a travaillé avec C2C sur pgRouting, faisait ses tests sur la voirie de Tokyo, une des plus denses du monde (13 millions d'arcs).
Le temps acceptable pour eux, et atteint si je me souviens bien, etait un routing en moins de 1s.
Nicolas
Hors ligne
#17 Tue 20 March 2012 13:49
Re: Pgrouting temps de calcul
qui a travaillé avec C2C sur pgRouting
Utilisation bête et méchante de l'API de pgRouting comme ici ? Ou bien C2C a sur exploiter tout son savoir faire pour l'optimisation de l'utilisation de pgRouting et de son environnement (POSTGis, postgresql, système d'exploitation, matériel...) afin de s'adapter à la contrainte de réalisation d'un itinéraire quelconque sur 13 millions d'arcs en moins d'1 seconde ?
J'imagine facilement que ce n'est pas forcément "download and use", sinon Tokyo trouverait quelqu'un de plus proche que C2C. La prestation de C2C était acceptable, pas seulement PgRouting.
J'imagine facilement que c'est le boulot de l'administrateur / le prestataire du système de gestion de la base de donnée de réaliser ce genre d’optimisation.
PgRouting n'est qu'une brique logicielle, à utiliser avec savoir faire, comme toute brique logicielle. Sommes-nous bien d'accord sur cette façon d'exprimer l'excellence de PgRouting ? Ou bien est-on en train de déclarer que PgRouting sur une configuration lambda, par défaut, va avoir ce genre de performance "utilisable" ?
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#18 Tue 20 March 2012 14:37
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
qui a travaillé avec C2C sur pgRouting
Utilisation bête et méchante de l'API de pgRouting comme ici ? Ou bien C2C a sur exploiter tout son savoir faire pour l'optimisation de l'utilisation de pgRouting et de son environnement (POSTGis, postgresql, système d'exploitation, matériel...) afin de s'adapter à la contrainte de réalisation d'un itinéraire quelconque sur 13 millions d'arcs en moins d'1 seconde ?
J'imagine facilement que ce n'est pas forcément "download and use", sinon Tokyo trouverait quelqu'un de plus proche que C2C. La prestation de C2C était acceptable, pas seulement PgRouting.
J'imagine facilement que c'est le boulot de l'administrateur / le prestataire du système de gestion de la base de donnée de réaliser ce genre d’optimisation.
PgRouting n'est qu'une brique logicielle, à utiliser avec savoir faire, comme toute brique logicielle. Sommes-nous bien d'accord sur cette façon d'exprimer l'excellence de PgRouting ? Ou bien est-on en train de déclarer que PgRouting sur une configuration lambda, par défaut, va avoir ce genre de performance "utilisable" ?
En fait, Orkney a repris le code de C2C initié par Sylvain Pasche et a continué les dev.
Oui bien sur: avec toutes les optimisations qui vont bien, sur une machine serveur "moyenne" (me rappelle plus les specs de l'epoque, style assez de ram pour que le graphe tienne en memoire), les temps etaient < 1s.
On est d'accord que dans le monde des BD, et particulierement dans le monde postgresql, qui arrive avec une conf ultra minimaliste, la performance d'une requete ou d'un module s'entend APRES avoir configuré le systeme comme il faut, ce qui est difficile et au coeur du métier de DBA.
Nico
Hors ligne
#19 Tue 20 March 2012 14:38
Re: Pgrouting temps de calcul
Sommes-nous bien d'accord sur cette façon d'exprimer l'excellence de PgRouting ?
Non, mais je pense qu'on peut s'en tenir là : DNFTT.
Hors ligne
#20 Tue 20 March 2012 14:40
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
qui a travaillé avec C2C sur pgRouting
Utilisation bête et méchante de l'API de pgRouting comme ici ? Ou bien C2C a sur exploiter tout son savoir faire pour l'optimisation de l'utilisation de pgRouting et de son environnement (POSTGis, postgresql, système d'exploitation, matériel...) afin de s'adapter à la contrainte de réalisation d'un itinéraire quelconque sur 13 millions d'arcs en moins d'1 seconde ?
J'imagine facilement que ce n'est pas forcément "download and use", sinon Tokyo trouverait quelqu'un de plus proche que C2C. La prestation de C2C était acceptable, pas seulement PgRouting.
J'imagine facilement que c'est le boulot de l'administrateur / le prestataire du système de gestion de la base de donnée de réaliser ce genre d’optimisation.
PgRouting n'est qu'une brique logicielle, à utiliser avec savoir faire, comme toute brique logicielle. Sommes-nous bien d'accord sur cette façon d'exprimer l'excellence de PgRouting ? Ou bien est-on en train de déclarer que PgRouting sur une configuration lambda, par défaut, va avoir ce genre de performance "utilisable" ?
En fait, Orkney a repris le code de C2C initié par Sylvain Pasche et a continué les dev.
Oui bien sur: avec toutes les optimisations qui vont bien, sur une machine serveur "moyenne" (me rappelle plus les specs de l'epoque, style assez de ram pour que le graphe tienne en memoire), les temps etaient < 1s.
On est d'accord que dans le monde des BD, et particulierement dans le monde postgresql, qui arrive avec une conf ultra minimaliste, la performance d'une requete ou d'un module s'entend APRES avoir configuré le systeme comme il faut, ce qui est difficile et au coeur du métier de DBA.
Donc, non: pas utilisation bete et mechante de l'API, mais la chaine:
• que sont mes données
• quel est mon matériel
• que veux-je faire
=> je tune tout comme il faut.
Nico
Dernière modification par Nicolas Ribot (Tue 20 March 2012 14:41)
Hors ligne
#21 Tue 20 March 2012 15:15
Re: Pgrouting temps de calcul
On est d'accord que dans le monde des BD, et particulierement dans le monde postgresql...
J'ai pu sembler un peu trop catégorique pour certains à cause de sous-entendu implicite, qui est loin d'être une évidence pour la plupart. Si c'était quelque chose de connu par tous, aurait-on ce genre d'offre de stage dont la date de prise de poste est hier ?
Formation
- Géomatique/cartographie/SIG
- Niveau bac +4, +5 (Master SIG)
Compétences
- Autonome, rigoureux, méthodique
- Maîtrise des concepts sémiologiques
- Maîtrise des SIG (QGis et SIG opensource)
- Maîtrise des SGBD (Postgresql, Postgis)
- Maîtrise des langages informatiques (html, php, javascript, SQL)
- Connaissance du monde opensource (linux)
Rémunération
Rémunération en vigueur, 436.05 euros net pour 35h + prise en charge des frais de déplacement
Date de début et durée du stage
Début souhaité du stage 19 mars 2012
Et après, quand certains s'échinent à travailler durement comme le demande notre métier, ils ne sont pas rémunérés en conséquence, car toute ce travail est naturel, puisqu'on sait se servir d'un ordinateur... Je suis en faveur d'une valorisation du travail à faire, pas vouloir faire croire que tout se fait les doigts dans le nez, comme s'il suffisait de trouver les bons logiciels.
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#22 Tue 20 March 2012 15:47
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
On est d'accord que dans le monde des BD, et particulierement dans le monde postgresql...
J'ai pu sembler un peu trop catégorique pour certains à cause de sous-entendu implicite, qui est loin d'être une évidence pour la plupart. Si c'était quelque chose de connu par tous, aurait-on ce genre d'offre de stage dont la date de prise de poste est hier ?Formation
- Géomatique/cartographie/SIG
- Niveau bac +4, +5 (Master SIG)
Compétences
- Autonome, rigoureux, méthodique
- Maîtrise des concepts sémiologiques
- Maîtrise des SIG (QGis et SIG opensource)
- Maîtrise des SGBD (Postgresql, Postgis)
- Maîtrise des langages informatiques (html, php, javascript, SQL)
- Connaissance du monde opensource (linux)
Rémunération
Rémunération en vigueur, 436.05 euros net pour 35h + prise en charge des frais de déplacement
Date de début et durée du stage
Début souhaité du stage 19 mars 2012
Et après, quand certains s'échinent à travailler durement comme le demande notre métier, ils ne sont pas rémunérés en conséquence, car toute ce travail est naturel, puisqu'on sait se servir d'un ordinateur... Je suis en faveur d'une valorisation du travail à faire, pas vouloir faire croire que tout se fait les doigts dans le nez, comme s'il suffisait de trouver les bons logiciels.
+1 !
(435€ un stage, scandaleux)
Hors ligne
#23 Tue 20 March 2012 20:06
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Re: Pgrouting temps de calcul
Bonjour à tous,
Je suis (du verbe suivre) vos échanges depuis hier, et si les sous entendus implicites ont pu impliquer certaines incompréhensions (mais c'est récurrent, sous entendu implicite psychologique) je constate avec bonheur que comme à l’accoutumée le débat né de la contradiction vol haut sur GéoBD. (petite liste mais dense).
Comme il dérive quelque peu sur un sujet lui aussi récurrent je me permets une petite remarque :
(435€ un stage, scandaleux)
Non Nicolas (dont j'apprécie les contributions régulières (et pas que sur ce forum francophone) et efficaces) ce n'est pas la rémunération du stage, qui est le minimum légal, qui est scandaleuse, mais les mots soulignés en gras par Jeirhome: Autonome et Maîtrise.
J'accueille mon 5 ou 6 éme stagiaire depuis 2 ans (en plus du montant légal il a les tickets restau) mais je ne lui demande pas d'être autonome, c'est à moi de le guider vers sa future autonomie (et chez moi ce mot a des sens), je ne lui demande pas de maîtriser, c'est son stage et la valeur de mon (de notre, je suis pas tout seul) encadrement qui le conduiront à devenir un padawan de sa matière. Avec les années il acquerra la maîtrise de son domaine qui n'est pas le master (vive la francophonie) ou plus (je lui souhaite) qu'il obtient en bout de cursus.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#24 Tue 20 March 2012 22:34
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1538
Re: Pgrouting temps de calcul
Bonjour à tous,
Je suis (du verbe suivre) vos échanges depuis hier, et si les sous entendus implicites ont pu impliquer certaines incompréhensions (mais c'est récurrent, sous entendu implicite psychologique) je constate avec bonheur que comme à l’accoutumée le débat né de la contradiction vol haut sur GéoBD. (petite liste mais dense).
Comme il dérive quelque peu sur un sujet lui aussi récurrent je me permets une petite remarque :(435€ un stage, scandaleux)
Non Nicolas (dont j'apprécie les contributions régulières (et pas que sur ce forum francophone) et efficaces) ce n'est pas la rémunération du stage, qui est le minimum légal, qui est scandaleuse, mais les mots soulignés en gras par Jeirhome: Autonome et Maîtrise.
J'accueille mon 5 ou 6 éme stagiaire depuis 2 ans (en plus du montant légal il a les tickets restau) mais je ne lui demande pas d'être autonome, c'est à moi de le guider vers sa future autonomie (et chez moi ce mot a des sens), je ne lui demande pas de maîtriser, c'est son stage et la valeur de mon (de notre, je suis pas tout seul) encadrement qui le conduiront à devenir un padawan de sa matière. Avec les années il acquerra la maîtrise de son domaine qui n'est pas le master (vive la francophonie) ou plus (je lui souhaite) qu'il obtient en bout de cursus.
Oui Christophe, j'ai fait un petit raccourci. Ce qui n'est vraiment pas terrible, et helas une pratique courante dans les boites privées, c'est de sortir une demande de stage, ou vu les prerequis techniques demandés, on subodore un travail demandé qui sera de la production, vendue a des clients a des taux horaires d'ingénieurs.
Bref, je me concentre sur postgis
Nico
Hors ligne
#25 Wed 21 March 2012 00:17
- Pierre
- DesCartesPourUnMondeMeilleur
- Date d'inscription: 22 Sep 2005
- Messages: 1643
Re: Pgrouting temps de calcul
Aloha
A la lecture du post de vincentp (j'ai beaucoup appris au passage), je me fais cette réflexion.
Peut-être est-ce une question idiote, ne connaissant que peu de l'administration d'une Bd Postgre, mais guibsou ne dit pas avoir jouer sur la "qualité" d'indexation de sa base. N'y a-t'il pas une possibilité à étudier ?
Dans le monde Oracle nous avions résolu des problèmes de performance dans nos parcours de réseau et de rendu cartographique en jouant sur ce paramètre.
Cordialement,
art X I. Déclaration des Droits de l’Homme et du Citoyen 1789
La libre communication des pensées et des opinions est un des droits les plus précieux de l’Homme : tout Citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l’abus de cette liberté, dans les cas déterminés par la Loi.
Hors ligne
#26 Wed 21 March 2012 09:33
- matieu_dumo
- Participant actif
- Lieu: Questembert
- Date d'inscription: 15 Mar 2006
- Messages: 135
- Site web
Re: Pgrouting temps de calcul
Bonjour,
Je suis (également du verbe suivre) ces échanges depuis hier. Je suis (du verbe être cette fois-ci) à l'origine de cette offre de stage.
En ce qui concerne la rémunération, je suis parfaitement d'accord avec le fait que ce soit scandaleux mais c'est effectivement le minimum légal. Le bureau d'études où je travaille est une petite structure (12 personnes) et nous sommes assez éloignés des grosses structures qui ont recours à des stagiaires dans le cadre de productions commerciales. Il s'agît là du 2e stage en 6 ans.
Concernant les mots en gras, je suis au fait que le stagiaire qui intégrera notre entreprise ne disposera pas de toutes ces compétences. Ces termes volontairement forts ont été employés afin d'exercer un filtre à la fois en termes de compétences et de motivation du candidat.
Il ne s'agît en aucun cas de développer de A à Z une solution sans aucun accompagnement, mais d'améliorer une application webmapping existante sur une thématique précise par le biais d'un environnement déjà en place (Postgis, Mapserver). En tant que géomaticien dans une PME, je me ferai d'ailleurs un plaisir d'accompagner le stagiaire dans sa réflexion et le développement entrepris. Et contrairement à ce que j'ai lu précédemment, ce n'est pas destiné à la commercialisation, mais fait partie d'un programme de développement interne à l'entreprise.
Concernant la date de début de stage, formulation maladroite. Je dois avouer que ce travail n'était pas destiné à l'origine à un stagiaire, nous ne sommes pas habitués à recourir à des stagiaires (peut-être devrions le faire plus souvent), mais étant particulièrement chargé en ce moment, il nous est apparu comme étant une solution envisageable.
Toutes mes excuses si cette annonce a choqué certains d'entre vous.
Bref, je me concentre également sur postgis
Hors ligne
#27 Wed 21 March 2012 10:32
Re: Pgrouting temps de calcul
Toutes mes excuses si cette annonce a choqué certains d'entre vous.
J'ai fait cette citation de l'offre de stage, et j'ai bien pris soin de ne pas afficher d'identité, le but n'était pas de stigmatiser un maitre de stage peu scrupuleux au premier abord. Comme l'a dit ChristopheV, le sujet du stage ou de l'emploi surqualifié au vu de la formation et de l'expérience demandées et de la rémunération, c'est un thème récurrent, et pas forcément que sur GeoRezo d'ailleurs, je ne voulais pas soulever un marronnier.
Le problème est que dans ce sujet, on a montré que comme dans de nombreuses autres disciplines de la géomatique et d'ailleurs, un bon travail, n'est pas forcément qu'un travail qui produit un résultat. Si le résultat est à côté de la plaque, il peut être tout aussi mauvais que pas de résultat du tout. On a montré ici qu'il y a des questions à se poser, dans un certain ordre, cela fait partie du "coeur de métier de DBA".
Dans ce cas, un accompagnement, c'est bien plus que répondre aux questions, c'est d'abord poser les bonnes questions, celles que se pose le gestionnaire compétent de base de données.
Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !
Hors ligne
#28 Wed 21 March 2012 11:06
- matieu_dumo
- Participant actif
- Lieu: Questembert
- Date d'inscription: 15 Mar 2006
- Messages: 135
- Site web
Re: Pgrouting temps de calcul
pris soin de ne pas afficher d'identité, le but n'était pas de stigmatiser un maitre de stage peu scrupuleux au premier abord
Pas de problème, je ne me sens pas stigmatisé et encore moins scrupuleux
qu'un travail qui produit un résultat. Si le résultat est à côté de la plaque, il peut être tout aussi mauvais que pas de résultat du tout
On est d'accord.
un accompagnement, c'est bien plus que répondre aux questions, c'est d'abord poser les bonnes questions
Encore une fois, on est d'accord.
Hors ligne
#29 Mon 02 April 2012 19:52
- guibsou
- Participant occasionnel
- Date d'inscription: 1 Aug 2006
- Messages: 28
Re: Pgrouting temps de calcul
j'annule mon dernier message
Dernière modification par guibsou (Mon 02 April 2012 20:38)
Hors ligne