Le portail francophone de la géomatique

Il semblerait que j'ai trouvé une solution et les resultats se rapprochent fortement des estimations de google. Ils sont legerement plus haut car google doit surement prendre en compte les arrets aux stop, les feux tricolores, les peages, etc.
En appliquant un coefficient abaissant legerement la vitesse, les resultats deviennent similaires.

voici comment j'ai procédé si ça peut aider quelqu'un :

je me suis basé sur la table osm_2po_4pgr extraite par osm2po car osm2pgsql avait un bug (fichier de plus de 2Go ne passait pas , meme en forçant le noyau de ma distrib (openvz debian ) avec un noyau bigmem simulant le 64Bits.
cette table à comme attribut le kilometrage du tronçon et sa vitesse (km et kmh)

j'ai rajouté deux champs à cette table :

cost_min double precision
reverse_cost_min double precision DEFAULT 1000000 (cette valeur correspond à la valeur attribuée à reverse_cost pour les sens unique)

j'ai ensuite executé les requetes suivantes :

update osm_2po_4pgr set cost_min = km * 60 / kmh
update osm_2po_4pgr set reverse_cost_min = km * 60 / kmh where reverse_cost <> 1000000

et maintenant j'utilise la fonction driving_distance de cette maniere pour afficher les isochrones à 10 min de temps de trajet de voiture pour le tronçon ayant l'ID 55755:

SELECT  b.id FROM (SELECT * FROM driving_distance('
                 SELECT id AS id, source, target,
                 cost_min as cost, reverse_cost_min as reverse_cost FROM osm_2po_4pgr',
                 55755, 10, false,true))
                AS a, osm_2po_4pgr AS b
                WHERE b.source = a.vertex_id

Je me suis peut-etre compliqué la tache et il existe peut-etre une solution beaucoup plus simple ou une fonction toute faite pour ça. si c'est le cas je suis preneur.

Guibsou