Le portail francophone de la géomatique

Bonjour,
Un sujet passionnant !

Le premier élément qui m'intrigue c'est la colonne cost. Cette colonne représente le coût du trajet c'est à dire que lorsque l'on cherche le trajet le plus court il faut faire un calcul de la colonne avec sa longueur

UPDATE TABLE set cost = st_length(the_geom)

Si cette colonne n'est pas remplie cela signifie que tous les segments ont la même longueur.

Le deuxième élément qui pique les yeux c'est dans la commande de création de la topologie

SELECT pgr_createTopology('network', 0.000000001, 'geom', 'id');

La valeur 0.000000001 c'est la tolérance. Cette notion de tolérance est très importante. Je m'explique : avec une tolérance à 1 m cela signifie que deux extrémités de tronçon distantes de moins d'1m seront considérées confondues et donc lorsque on va réalisé le calcul, le tracé va pouvoir passer d'un tronçon à l'autre. Cette tolérance c'est à vous de la fixer en fonction de l'étendue de vos données et de la qualité de vos données. A l'échelle du monde un tolérance de 1 me semble convenable voir plus même, actuellement vous êtes à 1 millionième de millimètres.

Enfin qu'appelez vous un grid, c'est une grille avec un pas régulier ?
--
Nicolas GRANIER

Détrompez vous la tolérance est bien le nerf de la guerre.
La valeur 0.0000001 que vous avez renseignée va passer dans tous les algorithmes de calcul de routage autant vous dire que s'il y a des arrondis, le résultat va quelque peu dérivé.

Avec une grille de 25Km vous pourriez même mettre une tolérance de 1000 (1 Km) ca fonctionnerait. Je vous conseille de faire un test avec une tolérance à 10m déjà.

Avec la colonne cost =1, vous indiquez au module de routage qu'une arête de votre grille est aussi grande qu'une diagonale de la grille, donc vous pouvez avoir des surprises avec le résultat. Si vous n'aviez que la grille sans les diagonales cela devrait tout de même marcher.

Je reviens sur la question de la tolérance. Vous pouvez faire un test. La table "network_vertices_pgr" est la table de noeuds entre les segments. Pour que les segments sont considérés comme joint par pgrouting, il faut qu'il n'existe qu'un seul noeud entre deux segments. S'il y a deux noeuds c'est que les segments ne sont pas considérés comme jointifs.

Faite un buffer à 1cm sur les noeuds et comptez ensuite le nombre de noeuds dans les buffers. Si vous en avez plus d'un c'est que vous avez des coupures donc pas de continuité.
A+
Nicolas GRANIER

Quelle est la projection de vos données ?

oui effectivement en 4326, les unités de votre tolérance ne sont pas des mètres mais surement des degrés décimaux
D'après Google et Wikipédia 0.0001° correspond à 7.9m donc ce serait pas mal comme tolérance.

Selon le workshop de pgrouting2 (http://workshop.pgrouting.org/chapters … h-dijkstra) , vous pouvez vous faciliter la vie sans recreéer les colonne x1,y2,...

La tolérance à 0.025 me semble bien en effet.

pour le cas des tracés (résultat) qui s'arrêtent juste avant le point vert : je pense que vous sélectionner les tronçons par leur champ source ou target, il vous faut faire votre sélection des segments par l'identifiant. D'après votre requête c'est le champ id

SELECT pgr_createTopology('network', 0.000000001, 'geom',[b] 'id'[/b]);

Vérifier qu'il soit bien compléter. nommer le toujours id si vous devez le recréer afin d'éviter les problèmes.

pour les points qui ne paraissent pas connectés ( ou aucun tracé n'est réalisé) : chargez toutes vos données dans Qgis. Est-ce-que le tronçon qui jouxte le point vert porte t'il bien dans sa colonne source ou target l'id du vertice du point vert ? Il faut bien comprendre qu'une fois la topologie créée tous les algos tournent de manière attributaire, il n'y a plus de géographie (d'où l'importance de la tolérance au départ)

Sinon joignez moi un extrait de réseau (avec la topologie créée), les vertices sur ces points, un point vert qui pose problème et un exemple de votre requete de chemin de + court.

Peut importe que le segment inverse le source ou le target, cela peut avoir de l'importance quand vous travaillez sur un réseau particulier (rue à sens unique par exemple) mais dans votre cas cela n'a pas d'importance.

Avez vous essayé les selections des trajets sur les id et non les sources / target ?

Dernière modification par Nicolas Granier (Thu 09 June 2016 14:47)

Je n'aurai pas dit ca.
Dans votre requete il s'agit de calculer le plus court chemin entre le noeud de la table network_vertices ayant l'id 1128, vers le noeud ayant l'id 290.
Il n'y a pas de colonne source et target dans la table de noeud seulement dans la table de réseau topologique.

pour faire cela les algorythmes de routage vont chercher dans la table de réseau (une fois la topologie crée bien sur) les colonnes source et target  où source = id du noeud OU target = id du noeud puis cherche le + court chemin vers la destination (sur le même pricipe. Le resultat renvoyé par la requete n'est pas l'id source ou l'id target du troncon mais l'identifiant (une autre colonne) du tronçon. Les tronçons de topologie doivent avoir leur propre id.

Dernière modification par Nicolas Granier (Thu 09 June 2016 16:03)

oui c'est exact

La requête que vous passez est bonne, c'est juste que l'on ne se comprend pas.

Quand vous faite la création de la topologie, la table de vertice se crée et les champs source et target de la table de réseau se remplissent.
Un vertice est une extrémité de tronçon qui est commune avec le tronçon voisin. L'identifiant id du vertice est attribué au fur et à mesure de la création de la table vertice. Une requete spatiale est ensuite faite entre les tronçons et les vertices pour affecter les id de vertices dans les colonnes source et target de la table de tronçons. Votre table tronçon contient donc pour chaque tronçon, l'identifiant des deux id de vertices aux extrémités.

La requete de plus court chemin va d'un vertice à un autre. Vous pouvez interroger 2 vertices, recupérer leur identifiant, et lancer votre requete de routage avec ces deux valeurs. Le resultat retourné doit vous donner non pas des identifiant de vertices, mais des identifiants de troncons.

Je vais essayer de vous faire un schéma.

et voici la deuxième illustration.
Je vous ai volontairement laissé les commandes postgis de création du réseau topologique

Dans ce grand gribouillage, j'illustre le tracé du plus court chemin entre le vertice id 124991 et l'id 95760.
Noter au passage que j'ai simplifié la commande pgr_dijkstra en enlevant les x1,x2,...
Le résultat qui m'intéresse est la colonne edge qui me renvoie les identifiants de tronçons composant le parcours entre les deux vertices.
Enfin dans Qgis je fais un sélection manuelle de ces tronçons et le trajet apparait bien.

Si sur ca on est en accord et on se comprend, on pourra peut être trouvé ce qui ne marche pas chez vous.

Dernière modification par Nicolas Granier (Fri 10 June 2016 08:48)

Je pense que vous pouvez poster un sujet sur la volumétrie des données et les temps de traitements, il y a des gens sur le forum qui vous aideront à optimiser vos requêtes et même votre configuration. J'ai moi-même réduit un traitement de découpage de 6H à 8 secondes avec grâce à l'aide un membre... mais cela est un autre sujet.

Est-ce que vous avez regardé l'onglet Messages de la fenêtre résultat SQL? Vous avez un FAIL dans la fenêtre SORTIE DES DONNEES mais en principe vous avez la description de l'erreur dans l'onglet MESSAGES
C'ast vrai qu'avec seulement FAIL on n'est pas prêts de comprendre pourquoi.

Bonjour,

Je reviens vers vous étant donné que mon pgr_createtopology a encore "FAIL".
Cette fois j'ai donc regardé le message et il marque :

NOTICE:  268430000 edges processed
NOTICE:  268431000 edges processed
NOTICE:  268432000 edges processed
NOTICE:  268433000 edges processed
NOTICE:  268434000 edges processed
NOTICE:  268435000 edges processed
ATTENTION:  AbortSubTransaction while in COMMIT state
CONTEXT:  fonction PL/pgsql pgr_createtopology(text,double precision,text,text,text,text,text,boolean), ligne 206, lors du nettoyage de l'exception
NOTICE:  nombre maximum de sous-transactions validées (268435455) dépassé
NOTICE:  UPDATE public.network SET source = 67243911,target = 67253315 WHERE id =  206793583
ATTENTION:  AbortSubTransaction while in COMMIT state
CONTEXT:  fonction PL/pgsql pgr_createtopology(text,double precision,text,text,text,text,text,boolean), ligne 38, lors du nettoyage de l'exception
NOTICE:  Unexpected error nombre maximum de sous-transactions validées (268435455) dépassé

Total query runtime: 6 days, 09:8653:32408 hours
1 row retrieved.

Je suppose que le réseau est trop important, existe t-il un moyen pour tout de même créer la topologie ou bien faut il définitivement prendre un grid moins détaillé? (et donc avec moins d'élements)

Merci d'avance!

Bonjour,

J'ai repris mon grid moins détaillé, qui est bon, j'ai fait mon pgr_createtopology qui a marché.
J'ai donc lancé :

SELECT seq, id1 AS node, id2 AS edge, cost
FROM
pgr_Dijkstra('SELECT id, source, target, cost, x1, y1, x2, y2 FROM network', 1128, 290, FALSE, FALSE);

Mais j'obtiens :

NOTICE:  Deprecated function
Total query runtime: 15.2 secs
0 rows retrieved.

Je ne comprends pas mon erreur, pourriez-vous m'aider pour repérer mon erreur ici?
Je ne comprends pas pourquoi elle est "deprecated"...

Dernière modification par Nugg_00 (Wed 13 July 2016 10:47)

"(2.2.0,pgrouting-2.2.0,afc622e,master,1.59.0)"

Même si je ne fais pas intervenir x1, y1, x2, y2

SELECT seq, id1 AS node, id2 AS edge, cost
FROM
pgr_Dijkstra('SELECT id, source, target, cost FROM network', 694, 966, FALSE, FALSE);

J'obtiens encore :

NOTICE:  Deprecated function
Total query runtime: 12.5 secs
0 rows retrieved.

Ma version de pgrouting est :

"(2.2.0,pgrouting-2.2.0,afc622e,master,1.59.0)"

Dernière modification par Nugg_00 (Wed 13 July 2016 12:00)