../../_images/logo_pgrouting.png ../../_images/OSGeo_project.png

Guide de démarrage rapide pgRouting

pgRouting est une extension qui ajoute le routage et d’autres fonctionnalités d’analyse de réseau aux bases de données PostGIS/PostgreSQL.

Activer pgRouting dans une base de données

Dans cet exemple, nous allons créer une base de données appelée city_routing et activer pgRouting dans la base de données.

  • Ouvrez une fenêtre System Tools ‣ QTerminal et exécutez psql: (psql est l’outil en ligne de commande fourni avec PostgreSQL)

psql

Dans l’invite de commande psql :

CREATE DATABASE city_routing;
\connect city_routing;
CREATE EXTENSION pgrouting CASCADE;

Vous pouvez vérifier votre installation en exécutant ceci :

SELECT * FROM pgr_version();
pgr_version
-------------
 3.1.0
(1 row)

Votre version doit être 3.1.0 ou supérieure

Quitter la base de données

\q

Chargement des données OSM avec osm2pgrouting

osm2pgrouting est un outil de ligne de commande pour le chargement des fichiers .osm dans la base de données avec un format compatible pgRouting.

Vérifiez la version installée

osm2pgrouting --version

La sortie montre

This is osm2pgrouting Version 2.3.6

Chargez les données du fichier osm :

bzcat data/osm/feature_city.osm.bz2 > /tmp/feature_city.osm
osm2pgrouting \
  -f /tmp/feature_city.osm \
  -h localhost \
  -U user \
  -d city_routing \
  -p 5432 \
  -W user \
  --conf=/usr/share/osm2pgrouting/mapconfig_for_cars.xml
rm /tmp/feature_city.osm

La sortie devrait être quelque chose comme:

Execution starts at: Thu Jan 21 16:25:38 2021

***************************************************
           COMMAND LINE CONFIGURATION             *
***************************************************
Filename = /tmp/feature_city.osm
Configuration file = /usr/share/osm2pgrouting/mapconfig_for_cars.xml
host = localhost
port = 5432
dbname = city_routing
username = user
schema=
prefix =
suffix =
Don't drop tables
Don't create indexes
Don't add OSM nodes
***************************************************
Testing database connection: city_routing
database connection successful: city_routing
Connecting to the database
connection success

Creating tables...
TABLE: ways_vertices_pgr created ... OK.
TABLE: ways created ... OK.
TABLE: pointsofinterest created ... OK.
TABLE: configuration created ... OK.
Opening configuration file: /usr/share/osm2pgrouting/mapconfig_for_cars.xml
    Parsing configuration

Exporting configuration ...
  - Done
Counting lines ...
  - Done
Opening data file: /tmp/feature_city.osm        total lines: 844044
    Parsing data


End Of file


    Finish Parsing data

Adding auxiliary tables to database...

Export Ways ...
    Processing 37373 ways:
[**************************|                        ] (53%) Total processed: 20000       Vertices inserted: 8126        Split ways inserted 10253
[**************************************************|] (100%) Total processed: 37373      Vertices inserted: 1423        Split ways inserted 3385

Creating indexes ...

Processing Points of Interest ...
#########################
size of streets: 37373
Execution started at: Thu Jan 21 16:25:38 2021
Execution ended at:   Thu Jan 21 16:25:42 2021
Elapsed time: 4.645 Seconds.
User CPU time: -> 2.36362 seconds
#########################

Vérifiez les données importées

Connectez-vous à la base de données city_routing

psql city_routing

La commande \d énumére toutes les tables et séquences disponibles

                  List of relations
 Schema |           Name           |   Type   | Owner
--------+--------------------------+----------+-------
 public | configuration            | table    | user
 public | configuration_id_seq     | sequence | user
 public | geography_columns        | view     | user
 public | geometry_columns         | view     | user
 public | pointsofinterest         | table    | user
 public | pointsofinterest_pid_seq | sequence | user
 public | spatial_ref_sys          | table    | user
 public | ways                     | table    | user
 public | ways_gid_seq             | sequence | user
 public | ways_vertices_pgr        | table    | user
 public | ways_vertices_pgr_id_seq | sequence | user
(11 rows)

osm2pgrouting charge les identificateurs OSM osm_id et il génère également un identificateur unique pour toutes les données: id sur les sommets, gid sur les arêtes.

SELECT id, osm_id
FROM ways_vertices_pgr
WHERE id IN(100,600);

Les résultats sont les :

 id  |  osm_id
-----+----------
 100 | 81622364
 600 | 82708785
(2 rows)

Requête interne

La plupart des fonctions pgRouting ont un paramètre qui est une instruction SQL, il est appelé requête interne

L’instruction SQL interne doit toujours avoir des noms de champ id, source, target et cost ayant reverse_cost en option.

Requête intérieure qui utilise gid comme identificateur des segments

SELECT gid as id,
       source, target,
       cost, reverse_cost
FROM ways

Requête interne qui utilise gid comme identificateur des segments et de la longueur comme cost sans le reverse_cost optionnel

SELECT gid as id,
       source, target,
       length AS cost
FROM ways

pgr_Dijkstra

Exécutez la fonction de plus court chemin de Dijkstra basée sur le temps en quelques secondes pour parcourir un segment sur un graphe non dirigé, en utilisant id comme identificateur d’un sommet

SELECT *
FROM pgr_dijkstra(
  'SELECT gid as id,
          source, target,
          cost_s AS cost, reverse_cost_s AS reverse_cost
  FROM ways',
  100, 600,
  directed => false
);

Les résultats sont les :

 seq | path_seq | node | edge  |      cost          |       agg_cost
-----+----------+------+-------+--------------------+--------------------
   1 |        1 |  100 |  6199 |  8.994104012024671 |                  0
   2 |        2 | 4360 |   152 | 2.8524015038110697 |  8.994104012024671
   3 |        3 |  101 |   511 | 2.4123361340227754 |  11.84650551583574
   4 |        4 |  322 |   707 |   3.63955931676029 | 14.258841649858514
   5 |        5 |  448 |   705 | 2.9567136964053367 | 17.898400966618805
   6 |        6 |  445 |   662 |  4.185190538775397 | 20.855114663024143
   7 |        7 |  415 |   663 | 1.2667248968947813 |  25.04030520179954
   8 |        8 |  442 |   699 |  6.371427985640729 |  26.30703009869432
   9 |        9 |  593 |   913 | 2.5897354220718807 |  32.67845808433505
  10 |       10 |  438 |   693 | 5.5261229396496585 |  35.26819350640693
  11 |       11 | 1573 |  2421 |  7.003475952839719 |  40.79431644605659
  12 |       12 |  619 | 10389 | 3.8659203494409344 |  47.79779239889631
  13 |       13 |  600 |    -1 |                  0 |  51.66371274833725
(13 rows)

Une requête qui utilise l’identificateur OSM devient :

SELECT *
FROM pgr_dijkstra(
  'SELECT gid as id,
          source_osm AS source, target_osm AS target,
          cost_s AS cost, reverse_cost_s AS reverse_cost
  FROM ways',
  81622364, 82708785,
  directed => false
);

Étant donné que la requête utilise les champs source_osm et target_osm, la requête les alias pour avoir les noms requis source et target.

La sortie est la suivante:

 seq | path_seq |    node    | edge  |        cost        |      agg_cost
-----+----------+------------+-------+--------------------+--------------------
   1 |        1 |   81622364 |  6199 |  8.994104012024671 |                  0
   2 |        2 | 1177972556 |   152 | 2.8524015038110697 |  8.994104012024671
   3 |        3 |   81622365 |   511 | 2.4123361340227754 |  11.84650551583574
   4 |        4 |   81917858 |   707 |   3.63955931676029 | 14.258841649858514
   5 |        5 |   82582021 |   705 | 2.9567136964053367 | 17.898400966618805
   6 |        6 |   82581909 |   662 |  4.185190538775397 | 20.855114663024143
   7 |        7 |   82571671 |   663 | 1.2667248968947813 |  25.04030520179954
   8 |        8 |   82581612 |   699 |  6.371427985640729 |  26.30703009869432
   9 |        9 |   82708510 |   913 | 2.5897354220718807 |  32.67845808433505
  10 |       10 |   82580320 |   693 | 5.5261229396496585 |  35.26819350640693
  11 |       11 |   97825917 |  2421 |  7.003475952839719 |  40.79431644605659
  12 |       12 |   82714784 | 10389 | 3.8659203494409344 |  47.79779239889631
  13 |       13 |   82708785 |    -1 |                  0 |  51.66371274833725
(13 rows)

Les coûts sont les mêmes que dans la première requête

Une requête pour obtenir la géométrie du chemin

Les résultats de pgr_dijkstra doivent être joints avec la table ways.

SELECT seq, edge, rpad(b.the_geom::text,60,' ') AS "the_geom (truncated)"
FROM pgr_dijkstra(
  'SELECT gid as id,
          source, target,
          cost_s AS cost, reverse_cost_s AS reverse_cost
  FROM ways',
  100, 600,
  directed => false
) AS a
JOIN ways AS b ON (a.edge = b.gid) ORDER BY seq;

Les résultats, à des fins visuelles, sont tronqués ici les géométries sont beaucoup plus longues qu’affiché

 seq | edge  |                     the_geom (truncated)
-----+-------+--------------------------------------------------------------
   1 |  6199 | 0102000020E6100000050000009F3825C56C3C4DC0D8367B56884A41C011
   2 |   152 | 0102000020E610000003000000B586F7C19E3C4DC016A0127C784A41C034
   3 |   511 | 0102000020E610000002000000EFF7D566AD3C4DC09C267D6B714A41C04A
   4 |   707 | 0102000020E6100000060000004A247612B63C4DC0FA1F05F4674A41C052
   5 |   705 | 0102000020E610000003000000964E35C4C23C4DC0D81E076F594A41C095
   6 |   662 | 0102000020E610000002000000504FC4C7CC3C4DC00858AB764D4A41C01F
   7 |   663 | 0102000020E610000002000000408C6BD7DF3C4DC013ACBBC3374A41C01F
   8 |   699 | 0102000020E61000000300000082FD7C00F73C4DC0E44FAFEF1E4A41C017
   9 |   913 | 0102000020E610000002000000650D28E5FF3C4DC03D02C985144A41C082
  10 |   693 | 0102000020E610000002000000C761D5C5123D4DC060E05E3EFE4941C065
  11 |  2421 | 0102000020E610000003000000675F1ED72B3D4DC0A45F11B2E24941C05F
  12 | 10389 | 0102000020E6100000020000006CA9CD49393D4DC08E548440D34941C067
(12 rows)

Avec la commande \q, quittez le shell PostgreSQL.

Ensuite ?