Ayuda para elegir un motor de enrutamiento adecuado

Estoy construyendo un sistema de planificación de rutas, pero aún tengo que decidir qué motor de enrutamiento subyacente usaré. Hasta ahora he encontrado pgrouting y neo4j.

Tengo mi red de rutas en una base de datos postgresql / postgis (importada de un archivo shape). He realizado consultas para extraer nodos (puntos finales de formas en las que tiene que tomar una decisión en qué dirección ir o callejones sin salida) y extraer bordes (a menudo formados por varias formas consecutivas). Todos mis bordes son bidireccionales.

Mi objetivo principal es calcular rutas en esta red utilizando un algoritmo de estrella A donde la distancia = costo.

Mi sensación me dice que una base de datos de gráficos como neo4j es el camino a seguir (ya que parece estar hecho solo para este propósito), pero no parecen admitir la estrella A por defecto y tampoco hay un sentido real de geometría . Parece más adecuado para redes sociales en lugar de mapas.

¿Pgrouting satisfaría mis necesidades?
¿Es lo suficientemente rápido para consultas sobre la marcha (+ -2000 nodos, + -4000 aristas)? Normalmente, esto sería unos pocos ms para A-star, pero no estoy seguro acerca de esta implementación en sql.
¿Pgrouting A-star me da una lista de nodos y aristas?
En la mayoría de los ejemplos que veo sobre pgrouting, noto que generalmente hay una lista de comandos después del cálculo de la ruta (como "En X gire a la izquierda, etc."). ¿Pgrouting produce esto o es de otro sistema?

Espero que alguien pueda darme información sobre qué sistema elegir. Neo4j, pgrouting u otro sistema.

pgrouting routing

— MRG
fuente

Creo que la mayoría de los algoritmos de enrutamiento no funcionan con un "sentido de la geometría", sino que se calcula un atributo geométrico y se usa como un costo (es decir, la medida de distancia de una polilínea). Nunca he usado Neo4j, pero parece realmente capaz y puede que lo esté usando pronto. Acabo de echar un vistazo a la documentación y parece posible usar A-Star: docs.neo4j.org/chunked/stable/graph-algo.html docs.neo4j.org/chunked/stable/… pgRouting también es capaz, y Soy un gran admirador de eso. Sería interesante comparar el rendimiento de estas dos soluciones.

— Allan Adair

Primero, sugeriría mirar a urbansim un modelo de uso de la tierra de código abierto. En cuanto a su pregunta de enrutamiento, si se trata de una aplicación de planificación, sugeriría que primero busque software como TransCAD, CUBE, PLANAR o EMME / 2 para la funcionalidad y la interfaz de usuario. Por lo general, ofrecen CDs de demostración de 1 o 2 horas de su software (software que puede ejecutar durante una o dos horas para tener una idea). Si desea crear algo para uso en línea o de escritorio, mire pgRouting; sin embargo, por experiencia, a veces, no es tan fácil como lo describe el taller / tutorial.

— dassouki

Empecé a trabajar con una estrella trabajando y ¡es increíble! Responde sí en mis primeras 3 preguntas. Aún así, me pregunto si alguien aquí sabe algo sobre la generación de instrucciones detalladas de navegación. ¿Existe alguna herramienta que coopere con el pgrouting que genere direcciones detalladas ("Después de 200 m, gire a la izquierda, etc.") a partir de la salida de la ruta calculada?

— mrg

Respuestas:

Actualmente estoy explorando el mismo problema que tú, con el propósito de un trabajo de investigación. Antes de comenzar a probar estas dos bases de datos, tenía la misma presunción que tú. Esa base de datos de gráficos Neo4j sería la solución perfecta para este tipo de problema. Y en parte lo es, pero con muchos problemas.

El primer problema es que A-Star solo se implementa si está utilizando una base de datos integrada, no a través de REST API (servidor). Si desea utilizar Neo4j con REST API, solo se admite el algoritmo Dijkstra. El segundo problema son los requisitos de memoria de hardware para Neo4j. Para el enrutamiento (Dijkstra) en redes "más grandes" necesita mucha RAM. Para una red grande me refiero a algo como el tamaño de la base de datos de carreteras OSM de Alemania . He realizado mis pruebas en un servidor RAM de 6 GB (eso es todo lo que tengo actualmente) y solo las redes más pequeñas podrían enrutarse sin errores de excepción OutOfMemory. Las redes "pequeñas" en mis casos de prueba son, por ejemplo, la base de datos de carreteras OSM para Austria o Croacia. Consultas concurrentes que todavía no he probado con Neo4j.

Todos estos problemas no existen en pgRouting. La memoria no es un problema, pero las consultas concurrentes aumentan la cantidad de memoria necesaria. Por ejemplo, si tiene dos solicitudes simultáneas, se necesita el doble de memoria. Esto no fue un problema incluso para un conjunto de datos OSM de Alemania, pgRouting enrutado sin problemas todas las solicitudes concurrentes.

Rendimiento: en la mayoría de los casos, Neo4j supera a pgRouting. Pero solo si hay suficiente memoria para el conjunto de datos dado y si todos los nodos y relaciones están en la memoria (inicio en caliente). El aumento / disminución del rendimiento depende de muchos factores, pero principalmente del tamaño de la red y la distancia (saltos) entre el nodo de origen y el de destino.

El tamaño de su red es bastante pequeño, por lo que no debería tener ningún problema con la memoria. Probablemente Neo4j no sea una mala elección, pero debe adaptarse a un "pequeño" modelo de datos diferente al de las bases de datos de relaciones estándar.

Para responder a sus preguntas:

En pgRouting no tiene que preocuparse por la implementación de AStar en sql, que ya está implementada.
Sí, pgRouting puede darle una lista de nodos y bordes
No creo que pgRouting pueda brindarle dicha información sin algunas consultas personalizadas. Pero tal vez me equivoque, tal vez alguien haya hecho esto y pueda ayudarlo más sobre esta pregunta.

No sé si te ayudará directamente, pero uno de los servidores de enrutamiento más rápidos que encontré es osm2po . Funciona con el conjunto de datos OSM y es bastante rápido. Actualmente solo se ha implementado dijkstra, pero el desarrollador también anunció AStar. Espero que algo de esto te ayude. :)

— Mario Miler
fuente

Es bueno saber de alguien que realmente haya probado ambos sistemas. Mientras tanto, tengo mucha más experiencia con pgrouting. Noté que pgrouting construye el gráfico completo para cada consulta y eso lo hace bastante lento para redes grandes (tamaño de Alemania), así que no veo por qué pgrouting requeriría menos memoria que Neo4j. Mi próximo intento será obtener todo el gráfico estático en ram y enrutarlo (con neo4j, nx_spatial, etc.) para garantizar una respuesta más rápida para el enrutamiento en tiempo real.

— mrg

Sí, cuanto más grande es el gráfico, más diferencia hay entre pgrouting y neo4j. Probablemente, si coloca todo el gráfico en la memoria, sería la solución más rápida, no hay duda al respecto. Neo4j es bastante rápido cuando todo el gráfico se carga en la memoria. No sé sobre nx_spatial, no lo he probado, pero tal vez lo haga. Creo que podría superar incluso a Neo4j. Pero esta solución es buena si es aceptable para su aplicación.

— Mario Miler

@mrg no está seguro si sigue siendo un problema para usted, pero hay OSRM (C ++) y GraphHopper (Java). Ambos escalan a gráficos mundiales y, por ejemplo, GraphHopper necesita menos de 1 gb para Alemania (de donde soy autor)

— Karussell

Karussell, gracias por la información! Ya había encontrado OSRM, pero GraphHopper es nuevo para mí.

— mrg

También puede echar un vistazo a nuestro paquete RW Net 4 (www.routeware.dk). Puede hacer cálculos de ruta más cortos utilizando A * directamente desde un archivo SHP. El paquete básico de 500 € parece suficiente para sus necesidades.

— Uffe Kousgaard
fuente

Gracias por su rápida respuesta, pero mi proyecto todavía está en una fase en la que no estoy seguro de si justifica gastar dinero en este momento. También pgrouting trabajando en mis datos, así que por ahora se ha abordado ese desconocido.

— mrg