Aide au choix d'un moteur de routage adapté

Je construis un système de planification d'itinéraire, mais je dois encore décider quel moteur de routage sous-jacent j'utiliserai. Jusqu'à présent, j'ai trouvé pgrouting et neo4j.

J'ai mon réseau de routes dans une base de données postgresql / postgis (importée à partir d'un fichier de formes). J'ai fait des requêtes pour extraire des nœuds (points d'extrémité de voies où vous devez prendre une décision dans quelle direction aller ou impasses) et pour extraire des bords (souvent constitués de plusieurs façons consécutives). Tous mes bords sont bidirectionnels.

Mon objectif principal est de calculer des itinéraires sur ce réseau en utilisant un algorithme A-star où distance = coût.

Mon sentiment me dit qu'une base de données de graphes comme neo4j est le chemin à parcourir (car elle semble être faite uniquement dans ce but), mais ils ne semblent pas prendre en charge A-star par défaut et il n'y a pas non plus de véritable sens de la géométrie . Il semble mieux adapté aux réseaux sociaux plutôt qu'aux cartes.

Le grouting répondrait-il à mes besoins?
Est-il assez rapide pour les requêtes à la volée (+ -2000 nœuds, + -4000 bords)? Normalement, ce serait quelques ms pour A-star, mais je ne suis pas sûr de cette implémentation en sql.
Le pgrouting A-star me donne-t-il une liste de nœuds et d'arêtes?
Dans la plupart des exemples que je vois à propos du pgroutage, je remarque qu'il y a généralement une liste de commandes après le calcul de l'itinéraire (comme "À X, tournez à gauche, etc."). Le groutage produit-il cela ou est-ce à partir d'un autre système?

J'espère que quelqu'un pourra me donner des informations sur le système à choisir. Neo4j, pgrouting ou tout autre système.

pgrouting routing

— mrg
source

Je pense que la plupart des algorithmes de routage ne fonctionnent pas avec un "sens de la géométrie", au lieu de cela un attribut géométrique est calculé et utilisé comme coût (c'est-à-dire la mesure de distance d'une polyligne). Je n'ai jamais utilisé Neo4j, mais il semble vraiment capable et je pourrai bientôt l'utiliser. Je viens de jeter un œil à la documentation et il semble possible d'utiliser A-Star: docs.neo4j.org/chunked/stable/graph-algo.html docs.neo4j.org/chunked/stable/… pgRouting est également capable, et J'en suis un grand fan. Il serait intéressant de comparer les performances de ces deux solutions.

— Allan Adair,

Tout d'abord, je suggérerais de regarder Urbansim un modèle open source d'utilisation des terres. En ce qui concerne votre question de routage, s'il s'agit d'une application de planification, je suggère de regarder d'abord des logiciels comme TransCAD, CUBE, PLANAR ou EMME / 2 pour les fonctionnalités et l'interface utilisateur. Ils distribuent généralement des CD de démonstration de 1 ou 2 heures de leur logiciel (logiciel que vous pouvez exécuter pendant une heure ou deux pour vous en rendre compte). Si vous souhaitez créer quelque chose pour une utilisation en ligne ou sur un ordinateur de bureau, regardez pgRouting; Cependant, par expérience, parfois, ce n'est pas aussi simple que la façon dont l'atelier / le didacticiel le décrit.

— dassouki

J'ai commencé à travailler avec une star et c'est génial! Il répond oui à mes 3 premières questions. Je me demande toujours si quelqu'un ici sait quoi que ce soit sur la génération d'itinéraires de navigation détaillés. Existe-t-il des outils qui coopèrent avec le pgrouting qui génère des directions détaillées ("Après 200m, tournez à gauche, etc.") à partir de la sortie de l'itinéraire calculé?

— mrg

Réponses:

J'explore actuellement le même problème que vous, aux fins d'un document de recherche. Avant de commencer à tester ces deux bases de données, j'avais la même présomption que vous. Cette base de données de graphes Neo4j serait la solution parfaite pour ce genre de problème. Et en partie c'est le cas, mais avec beaucoup de problèmes.

Le premier problème est que A-Star n'est implémenté que si vous utilisez une base de données intégrée, pas via l'API REST (serveur). Si vous souhaitez utiliser Neo4j avec l'API REST, seul l'algorithme Dijkstra est pris en charge. Le deuxième problème est la mémoire matérielle requise pour Neo4j. Pour le routage (Dijkstra) sur des réseaux "plus grands", vous avez besoin de beaucoup de RAM. Pour un grand réseau, je veux dire quelque chose comme la taille de la base de données routière OSM en Allemagne . J'ai exécuté mes tests sur un serveur RAM de 6 Go (c'est tout ce que j'ai actuellement) et seuls les petits réseaux peuvent être routés sans erreurs d'exception OutOfMemory. Les "petits" réseaux dans mes cas de test sont par exemple la base de données routière OSM pour l'Autriche ou la Croatie. Requêtes simultanées que je n'ai toujours pas testées avec Neo4j.

Tous ces problèmes n'existent pas dans pgRouting. La mémoire n'est pas un problème, mais les requêtes simultanées augmentent la quantité de mémoire nécessaire. Par exemple, si vous avez deux demandes simultanées, une double quantité de mémoire est nécessaire. Ce n'était pas un problème, même pour un ensemble de données OSM en Allemagne, pgRouting acheminé sans problème toutes les demandes simultanées.

Performances: dans la plupart des cas, Neo4j surpasse pgRouting. Mais uniquement s'il y a suffisamment de mémoire pour l'ensemble de données donné et si tous les nœuds et relations sont en mémoire (démarrage à chaud). L'augmentation / diminution des performances dépend de nombreux facteurs, mais principalement de la taille du réseau et de la distance (sauts) entre le nœud source et le nœud cible.

La taille de votre réseau est assez petite, vous ne devriez donc pas avoir de problèmes de mémoire. Neo4j n'est probablement pas un mauvais choix, mais vous devez vous adapter à un "petit" modèle de données différent de celui des bases de données de relations standard.

Pour répondre à vos questions:

Dans pgRouting, vous n'avez pas à vous soucier de l'implémentation d'AStar dans sql, qui est déjà implémentée.
Oui, pgRouting peut vous donner une liste de nœuds et d'arêtes
Je ne pense pas que pgRouting puisse vous fournir de telles informations sans un travail personnalisé autour des requêtes. Mais peut-être que je me trompe, peut-être que quelqu'un a fait cela et peut vous aider davantage sur cette question.

Je ne sais pas si cela vous aidera directement, mais l'un des serveurs de routage les plus rapides que j'ai trouvé est osm2po . Il fonctionne avec l'ensemble de données OSM et est assez rapide. Seul dijkstra est actuellement implémenté, mais le développeur a également annoncé AStar. J'espère que cela vous aidera. :)

— Mario Miler
source

Il est bon d'entendre quelqu'un qui a effectivement testé les deux systèmes. En attendant, j'ai beaucoup plus d'expérience avec le groutage. J'ai remarqué que le pgrouting construit le graphique entier pour chaque requête et cela le rend plutôt lent pour les grands réseaux (taille Allemagne), donc je ne vois pas pourquoi le pgrouting nécessiterait moins de mémoire que Neo4j. Mon prochain essai consistera à obtenir le graphique entier statique dans ram et route sur cela (avec neo4j, nx_spatial, etc.) pour assurer une réponse plus rapide pour le routage en temps réel.

— mrg

Oui, plus le graphique est grand, plus il y a de différence entre pgrouting et neo4j. Probablement, si vous mettez un graphique entier en mémoire, ce serait la solution la plus rapide, cela ne fait aucun doute. Neo4j est assez rapide lorsque tous les graphiques sont chargés en mémoire. Je ne connais pas nx_spatial, je ne l'ai pas testé, mais je le ferai peut-être. Je pense qu'il pourrait même surpasser Neo4j. Mais cette solution est bonne si elle est acceptable pour votre application.

— Mario Miler

@mrg ne sait pas si c'est toujours un problème pour vous mais il y a OSRM (C ++) et GraphHopper (Java). Les deux sont adaptés aux graphiques mondiaux et, par exemple, GraphHopper a besoin de moins de 1 Go pour l'Allemagne (dont je suis l'auteur)

— Karussell

Karussell, merci pour l'info! J'avais déjà trouvé OSRM, mais GraphHopper est nouveau pour moi.

— mrg

Vous pouvez également consulter notre package RW Net 4 (www.routeware.dk). Il peut effectuer ces calculs de chemin le plus court en utilisant A * directement à partir d'un fichier SHP. Le forfait Basic à 500 € semble suffisant pour vos besoins.

— Uffe Kousgaard
source

Merci pour votre réponse rapide, mais mon projet est encore dans une phase dont je ne sais pas s'il mérite de dépenser de l'argent en ce moment. De plus, j'ai commencé à travailler sur mes données, donc pour l'instant cet inconnu a été abordé.

— mrg