¿Crear polígonos de tiempo de conducción con herramientas de código abierto?

¿Alguien está usando herramientas y / o datos de código abierto para generar polígonos de tiempo de conducción que se irradian desde una ubicación determinada? Por ejemplo, he utilizado productos ESRI como Network Analyst y Business Analyst para generar límites de polígonos que representan la distancia máxima que se puede recorrer a lo largo de una red de carreteras desde un punto determinado dentro de un período de tiempo definido por el usuario (digamos 5, 10 y / o 15 minutos). ¿Existen alternativas similares de código abierto o basadas en la web?

Vi esta publicación, pero realmente no ofrece opciones alternativas: ¿Puedes hacer un polígono de región de viaje con la API de Google Maps?

Tenía particular curiosidad por saber si alguien está (o puede) usar OpenStreetMap para hacer análisis de tiempo de conducción.

Además, ¿hay alguna implementación de las utilidades de pgRouting que pueda usarse para generar polígonos? http://pgrouting.postlbs.org/

GRASS v.net.iso te dará un resultado como este:

Es posible que no desee ejecutar un algoritmo de casco convexo en esta salida. Imagine los caminos azules: un casco convexo a su alrededor contendría muchas partes a las que no se puede acceder en el tiempo representado por "azul".

En cambio, es posible que desee buscar formas alfa (pregunta relacionada: ¿Qué son la definición, los algoritmos y las soluciones prácticas para el casco cóncavo? )

Puede crear isócronas de tiempo de conducción utilizando pgRouting y QGIS ( como se describe aquí ). No utilicé OSM en este caso, pero, por supuesto, podría construir su red enrutable basada en OSM (consulte la herramienta osm2pgrouting ).

( resolución completa )

Para una solución PostGIS pura, puede usar la función de forma alfa pgRouting . Aquí hay una comparación de las formas alfa implementadas en pgRouting y el enfoque que presenté en la actualización anterior:

Las áreas coloreadas representan los resultados de la función de forma alfa, las líneas negras son los resultados del enfoque de interpolación descrito anteriormente. Las áreas de captación son menos detalladas utilizando las formas alfa de pgRouting. Además, parece que no hay forma de variar el valor de alfa para crear representaciones más detalladas.

GRASS 'v.net.iso se puede utilizar para crear la' red 'de tiempo de conducción que puede pasar a un comando' casco convexo 'para obtener un polígono. Quizás no sea ideal, ¡pero funcionaría!

Bueno, potencialmente podría usar v.net.iso de GRASS GIS. Sin embargo, no crea polígonos (AFAIK), sino que divide las líneas por clases de costo de la fuente.

En cuanto al cálculo de los tiempos de manejo desde OSM, puede importar los datos a GRASS con v.in.osm , y usar v.net.iso para calcular las zonas de costos. Si desea tiempos de viaje y no tiene límites de velocidad en la carretera, podría calcular el límite de velocidad en función de alguna función de la clase de carretera.

Puede usar GraphHopper para esa tarea, que también admite diferentes modos como caminar o andar en bicicleta y usa OpenStreetMap por defecto. Necesitará un poco de codificación Java que explore la red de carreteras desde el punto de partida, similar a cómo funcionan los algoritmos de Dijkstra, pero luego puede obtener algo como lo siguiente incluso en tiempo real (<0.5s):

El código recopilará los puntos que debe convertir a un polígono con, por ejemplo, las herramientas JTS . La velocidad depende en gran medida de este último paso. Sin esto, sería posible por debajo de 0.5s incluso para grandes distancias.

Otra forma sería con OpenTripPlanner .

osrm-isochrone es una pequeña biblioteca node.js para generar tiempos de conducción.

Es posible que desee consultar la API de JavaScript Route360 ° abierta , que funciona tanto con el folleto como con los mapas de Google. Devuelve polígonos de tiempo de viaje para los siguientes modos de viaje: caminar, bicicleta, automóvil, tránsito.

Es gratis y de código abierto y la cobertura es bastante buena. Puede encontrar muchos tutoriales diferentes sobre cómo usarlo en el sitio web.

Aunque no responde directamente a su pregunta, debe echar un vistazo a la API de Mapnificent .

Mapnificent proporciona mapas dinámicos de tiempo de viaje en transporte público para muchas ciudades de los EE. UU. Y algunas en todo el mundo. Puede usar la API de Mapnificent para aumentar su aplicación de Google Maps con superposiciones de tiempo de viaje en transporte público.

Echa un vistazo a Londres aquí .

También me topé con la extensión de red de gvSIG , pero la documentación de configuración que he encontrado hasta ahora es bastante pobre. Tengo muchas esperanzas, solo necesito averiguar los detalles para calcular el costo.

Estaba usando los datos de TIGER del Censo de EE. UU. Para la red de carreteras y en realidad generé algunos polígonos, pero simplemente no pude conseguir que las unidades de costo realmente tuvieran sentido. Si alguien ha implementado con éxito esta herramienta, me encantaría saberlo.

También encontré Quantum Navigator para QGIS, pero no encontré ninguna actualización reciente.

El resultado con el enfoque de casco cóncavo es excelente y me he inspirado mucho en las imágenes de arriba. Pero noté que los resultados pueden incluir algunas áreas que son inaccesibles por carretera (como el río, por ejemplo). No hay duda de que esto no es un problema en términos de búsqueda de características relevantes (centroides de población, número de hogares) por distancia o tiempo desde el origen. Pero también solo funciona en cada extremo de cada enlace. Una vez más, no es un problema en la gran mayoría de los casos (dado que los enlaces de carretera más largos tienen control de acceso, normalmente no puede salir de ellos hasta llegar al siguiente cruce / intersección).

Sin embargo, por todo eso, he estado trabajando en un enfoque diferente basado en los ENLACES devueltos por PgRouting / (o un algoritmo "Dijkstra" sin procesar) ordenado por tiempo desde el nodo de origen. Es relativamente simple y clasifica los enlaces por banda de tiempo y también divide los enlaces que cruzan los límites de tiempo. Luego, los enlaces con la misma categorización (por ejemplo, 0-2 minutos, 2-4 minutos) se almacenan en búfer por 250 metros.

En el WhereCampPDX de este año, varios representantes de OpenStreetMap declararon que el uso de datos OSM para el enrutamiento es bastante común en Europa. Sin embargo, es más raro en los EE. UU. Porque el mapa generalmente no es lo suficientemente bueno. Puede consultar un servicio de enrutamiento basado en OSM en:

http://openrouteservice.org/