Le portail francophone de la géomatique

Bonjour,

Pour ce genre de parcours de graphe, l'utilisation de pgRouting peut etre utile, ou plus simplement, suivant le modele des données, la construction:
WITH RECURSIVE ...
qui permet une itération en SQL et donc de parcourir des elements connectés entre eux.

Vous auriez un exemple plus précis des données et de la notion "isoler un secteur" ?

Nicolas

Salut,

Alors il est temps de refaire une formation

Avec une connexion des vannes en debut ou fin de tronçon, il est possible de répondre à la problématique avec une construction WITH RECURSIVE:
Le principe serait alors de parcourir le graphe a partir d'un tronçon donné (ou plusieurs) et de ne s'arrêter que lorsque 2 tronçons sont concernés par une vanne:

La table des tronçons (gid, geom)
La table des vannes (gid, geom)

Pour plus de facilité dans la requête qui va suivre, on ajoute une colonne à la table tronçon qui dit si le tronçon est concerné par une vanne (qu'il y en ait une ou deux, peu importe: une vanne permet de fermer ce tronçon)

alter table tronçon add column vanne boolean;
-- mise à jour de la colonne
update troncon set vanne = false;
update troncon t set vanne = true
from vanne v
where st_dwithin(v.geom, t.geom, 0.001);

Ensuite on parcourt cette table de façon itérative, en comparant un tronçon et son tronçon connecté (utilisation de st_dwithin pour trouver un tronçon connecté: plus rapide et souvent plus robuste que st_intersects entre une ligne et un point):
si les deux possèdent une vanne, alors il faut fermer cette vanne: on arrete la récursion pour cette branche.
Si les deux tronçons n'ont pas chacun une vanne, on continue a chercher le tronçon connecté suivant.

Dans la requête suivante, je liste les infos du tronçon précédent et tronçon suivant (prev_ et next_):
pour la partie non récursive de la requête, le tronçon précédent n'existe pas: valeurs vides ou nulles.
La liste des tronçons parcourus est stockée dans un tableau: c'est une des conditions d'arrêt de l'itération: on ne recherche pas des tronçons déjà cherchés.

La deuxième condition d'arrêt de l'itération est lorsque un tronçon et son suivant ont chacun une vanne sur le tronçon.

La requête itérative liste les identifiants de tronçons concernés par des vannes à fermer.
Pour retrouver les vannes les plus proches du tronçon de départ, on trouve toutes les vannes rattachés aux tronçons élus et on calcule la distance entre ces vannes et le tronçon de départ.
On ne garde alors que les vannes les plus proches (distinct on de la requête finale):

with recursive toclose(prev_geom, next_geom, prev_gid, next_gid, prev_vanne, next_vanne, stop, tgids, depth) as (
    -- partie non recursive
    select 'LINESTRING EMPTY'::geometry, t.geom, -1, t.gid, false, t.vanne, false, ARRAY[t.gid], 1 as a
    from troncon t
    where t.gid = 30

    UNION ALL
    -- partie recursive
    select o.next_geom, t.geom, o.next_gid, t.gid, o.next_vanne, t.vanne, (o.next_vanne AND t.vanne), o.tgids || t.gid, o.depth + 1
    from troncon t, toclose o
    where 
    -- connection entre troncons
    st_dwithin(t.geom, o.next_geom, 0.001)
    -- connexion entre deux troncon sans vanne
    and not stop
    -- troncon pas parcouru
    and not (t.gid = any(tgids))
), -- les troncons concernés par les vannes a fermer
tr as ( 
    select distinct prev_gid as gid, prev_geom as geom
    from toclose
    where stop
), -- les vannes les plus proches du troncon de ref appartenant a ces troncons
vannes as (
    select v.gid as vanne_gid, tr.gid as troncon_gid, st_distance(v.geom, t.geom), v.geom
    from vanne v, tr, troncon t
    where t.gid = 30
    and st_dwithin(v.geom, tr.geom, 0.001)
    order by 1, 2
) select distinct on (1) vanne_gid, troncon_gid, geom
from vannes;

L'image montre le résultat de la requête pour le tronçon #27

Nico

Bonjour, et merci pour vos réponses!
Ça fonctionne parfaitement. Effectivement, il va falloir que je me remette à niveau! C'est le problème de peu pratiquer....
Tu es dans quelle structure aujourd'hui Nicolas? Tu fais toujours des formations?

Merci également à Vincent. Le plugin qgis de connexion à EPANET m'intéresse particulièrement. Le service AEP pour lequel je travaille est en train de s'équiper et les outils de modélisation font partie de leurs problématiques.

Merci encore.

Jeff

Bonjour, j
Je me permets de relancer le sujet. L'approche est très intéressante, moi, j'ai eu à travailler sur Qgis en utilisant les index spatiaux, même si c'est légèrement plus lent je pense que sur postgis, ca tient le coup sur 15 000 tronçons ( le cas de ma ville).
Cependant, l'approche présentée est limitée. Il ne suffit pas juste de s'arrêter quand on trouve des vannes. En effet, il faudrait tenir compte aussi de la topologie du réseau de distribution.
Imaginez un peu dans un réseau le cas des retours d'eau, on a des tronçons secondaires connectés à un principal qui desservent des zones élevées en altitude.
En cas d'incident, l'eau continuera à venir de la source mais il y aura aussi  un retour d'eau qu'il faut arrêter pour gagner sur le plan économique, surtout quand les zones sont forte altitude par rapport à la conduite touchée, il faudrait donc tenir compte de ces cas pour avoir un outil optimisé pour prendre les bonnes décisions. J'ai travaillé dessus mais ce n'est pas abouti, en effet les retours d'eau sont dans certains cas complexes à saisir.