Requêtes Postgis

[Tioneb]

Après avoir remanié plusieurs fois ma base pour optimiser le fonctionnement, je m'attaque aux requêtes Postgis. N'étant pas très fort dans ce domaine, d'autant qu'il me faut le coupler à Active record, j'avoue que je galère un peu... mais j'ai enfin mes premiers résultats qui sortent.

Je présume que l'on peut faire à peu près toutes les requêtes que l'on veut, mais j'ai quand même quelques interrogations.

Pour plus de facilités, j'ai découpé mes circuits en tronçon pour ne pas avoir non plus de geojson trop importants (suis à 15000 points sur les linestring, je ne me rend pas compte si ce n'est trop). J'ai donc une table de circuits avec une autre table des traces avec leurs variantes, que j'ai stocké en linestring (avec un boleen pour savoir si c'est le chemin principal ou pas)... ce n'est peut être pas une bonne idée ? Faudra peut etre que je modfie le shéma une nouvelle fois...mais c'est par l'expérimentation que j'apprends.

Est que l'on peut connecter des traces entres elles et faire des calculs de distance (en associant plusieurs linestring) ?

Par exemple, j'ai la voie A (voie principale) et la voie B (une variante) qui rejoint la voie A à un point P.
J'ai un poi situé sur la voie B... est ce que je peux calculer la distance vers un autre poi situé sur la voie A après le point P ?

Autre question, sachant que mes traces ne changent jamais (ou très rarement), est ce que je peux l'intégrer sur mon fond de carte pour éviter de charger le tracé geojson à chaque fois et gagner ainsi en rapidité et en requetage ?

[yvecai]

Pour ta première question, c'est du calcul d'itinéraire (routing). Pgrouting peux t'aider, je pense.
Pour la deuxième, c'est du rendu, et là c'est certainement osm2pgsql, mod_tile et mapnik qui sont les mieux documentés.

[Tioneb]

Merci Yves,

J'ai regardé pgrouting mais je penchais pour un système plus simple (de plus Heroku ne propose pas cette extension) même si effectivement, on peut l'apparenter à un routage, on est quand même sur un système ou les connections sont peu nombreuses.
Je pensais pluto utiliser ST_LineLocatePoint combiné avec ST_LineInterpolatePoint... mais peut être que je fais fausse route. (sans jeu de mots)

Pour le deuxième point, j'ai peut être mal formulé la question, mais je pensais plutôt à mapbox ou équivalent

[yvecai]

D'un point A à un point B sur la même voie, alors oui tu peux t'en sortir avec ça. Si c'est des voies différentes alors il vaut mieux passer par une solution de routage car ça devrait probablement trop complexe.

[cquest]

Si les itinéraires sont peu nombreux, tu peux te passer de pgrouting et faire ces calculs toi même, ce qui va demander du boulot pour explorer le graphe.

Ce graphe doit contenir pour chaque itinéraires allant d'un point A à B, ces extrémités (commets) et une info sur le temps ou la distance entre les deux (l'arc), mais sans besoin du détail de la géométrie.


Pour le rendu... intégrer le tracé de l'itinéraire directement à l'image est possible, mais...
- soit on récupère le fond de carte et on ajoute le tracé, puis en envoie l'image résultat.
- soit on génère tout le fond de carte en y incluant ce tracé (lourd car il faut toutes les données OSM de la zone, faire un rendu, etc)

Quel est le problème au juste ? Le tracé un peu lourd en geojson ?
postgis peut le simplifier si besoin... ST_SnapToGrid ST_Simplify

[Tioneb]

Si les itinéraires sont peu nombreux, tu peux te passer de pgrouting et faire ces calculs toi même, ce qui va demander du boulot pour explorer le graphe.

Je n'ai pas beaucoup de variantes que je peux documenter au fil de l'eau. Disons une vingtaine pour commencer, mais ça devrait pas aller au delà d'un centaine je pense. Le graphe est somme toutes assez simple.

Ce graphe doit contenir pour chaque itinéraires allant d'un point A à B, ces extrémités (commets) et une info sur le temps ou la distance entre les deux (l'arc), mais sans besoin du détail de la géométrie.

Donc si je comprends bien, quand tu parles des points A et B tu parles des extrémités de chaque tronçon ? Ou bien de toutes les relations possibles entre tous les pois ?

Quel est le problème au juste ? Le tracé un peu lourd en geojson ?
postgis peut le simplifier si besoin... ST_SnapToGrid ST_Simplify

En fait, j'en ai l'impression (environ 4 Kb), mais comme je n'ai aucune idée à partir de quand un geojson devient trop lourd...

[cquest]

A-B, oui, je parle des extrémités des tronçons, c'est à dire les sommets du graphe, là où il faut prendre une décision pour continuer son chemin.

Pour le poids des geojson... distinguer deux limites:
- la taille globale (pour le transfert)
- le nombre d'objets (pour l'affichage)

Pour la taille:
- arrondir les coordonnées à 6 décimales permet souvent de gagner pas mal dans bien des cas... et on reste à 10cm de précision !
- inutile de faire du "pretty" geojson lisible par un humain, pas besoin d'indentation, de retours à la ligne
avec ça on gagne souvent dans les 50%

Pour le nombre d'objets:
- sur des objets linéaires ou surfaciques, ST_Simplify/ST_Snaptogrid va éliminer les détails de leur forme, on gagnera aussi du coup en taille
- sur les objets linéaires... pas grand chose à faire sauf du clustering (les regrouper par proximité)

Quelques centaines d'objets s'affichent rapidement avec leaflet/openlayers.
Quelques milliers peuvent être affichés en cluster, géré par le client (leaflet/openlayer)
Au delà, c'est côté serveur qu'il faut faire les cluster pour limiter le volume de données transmis et le traitement pas le client

Inutile de résoudre des problèmes qui n'existent pas encore... mais les anticiper c'est pas mal

[Tioneb]

A-B, oui, je parle des extrémités des tronçons, c'est à dire les sommets du graphe, là où il faut prendre une décision pour continuer son chemin.

Ok super, par contre je ne vois pas du tout comment tu peux gérer la chose. Une doc, un tuto auquel je pourrais me référer ?

Je présume que l'idéal c'est de stocker ces infos sous forme POINT() avec l'entrée et la sortie.... mais après j'ai vraiment aucune idée de ce que je dois faire...

Inutile de résoudre des problèmes qui n'existent pas encore... mais les anticiper c'est pas mal

J'aime bien anticiper les problèmes, ca me permet d'organiser mon code en conséquence et de ne pas à avoir à tout refaire, une fois que les problèmes surgissent

[cquest]

Le graphe n'a plus rien de géographique... c'est une logique totalement différente et il y a plein de choses à lire sur ce sujet en particulier sur les algo de recherche d'itinéraires.

C'est quelque chose que j'ai peu exploré, je n'ai pas de lien à conseiller.

pgRouting sert à gérer ça et peut gérer des graphes importants.

Sur un petit graphe, on doit pouvoir s'en sortir avec des requêtes postgres récursives, exemple: https://vibhorkumar.blog/2011/01/14/dir ... ery-of-pg/

[Tioneb]

Super intéressant comme lien J'apprends plein de choses... merci

Sauf que dans le cas présent, je ne cherche pas à établir le chemin le plus court... juste à proposer les différentes options.
De plus les randonneurs font environ 20/25 km... 40 pour les plus sportifs... je n'ai donc pas besoin d'avoir la liaison entre A et Z (situé bcp trop loin)

J'ai par exemple un graph qui ressemble à ça :

A vers B 20 km
ou
A vers B 10 km

Je n'ai pas des routes multiples à l'infini. Dans 95 % des cas, la variante retourne vers le circuit principal. Et pour les 5 % restant, je pense les gérer comme des chemins indépendants

Dans ce cas, est ce que la solution la plus simple, ne consisterait pas a rattacher un poi à un tronçon ?

Par exemple A vers B... j'ai deux tronçons.
Le poi est situé sur le tronçon A'

Je merge les différents tronçons en fonction des points d'entrée et de sortie et je calcule les distance ?

La question, c'est est ce que postgis permet de retrouver le POI en fonction des linestring mergées ?