[Gvsig_desarrolladores] extension Piloto de redes

Lun Ago 13 09:36:27 CEST 2007

Hola Angélica.

Los problemas relacionados con la atención de emergencias seguramente 
los tendremos solucionados con esta extensión de gvSIG. Hay una serie de 
funcionalidades previstas y entre ellas está la de buscar los puntos más 
cercanos a uno dado. Es decir, si ocurre un accidente en un sitio, 
buscar los hospitales más cercanos y mostrarlos al usuario por orden de 
proximidad.

En cuanto a la velocidad, no creo que deba preocuparos si se trata solo 
del callejero de una ciudad. Las pruebas las solemos hacer con Madrid, y 
el cálculo de la distancia de un punto a TODOS los demás suele costar 
menos de 200 milisegundos. De hecho, tardamos más en pintar el resultado 
o calcular el texto a mostrar que en el cálculo en sí. Creo que la 
velocidad empezaría a ser un problema con redes del tamaño de Europa con 
carreteras, o España con carreteras + calles de las ciudades más 
importantes.

En cuanto a los criterios, lo del sentido ya lo tenemos en cuenta, lo de 
la longitud también y si puedes traducir lo de semaforización y flujo 
vehicular a un esquema de costes (en tiempo por tramo, por ejemplo), 
también está soportado.

Como ejemplo, adjunto un cálculo de área de servicio desde el parque del 
retiro a todos los puntos de la red de calles de Madrid. El cálculo lo 
ha hecho en 193 milisegundos. Para dibujarlo, ha tardado 2.2 segundos 
(en modo debug, que suele ir un poco más lento).

Saludos, y hasta otra.

Francisco José Peñarrubia
Equipo gvSIG.

Angélica María Gómez escribió:
> Muchas gracias por la rápida respuesta Fransisco
>
> Bueno, resulta que lo que se está desarrollando es un planificador de 
> rutas para la atención de emergencias. El sistema deberá buscar por 
> dirección y por ubicación directa sobre el mapa. El sistema debe ser 
> heurístico, por lo que se tienen cuatro criterios, en principio, que 
> deben trabajar juntos en la búsqueda (sentido, semaforización, flujo 
> vehicular y longitud).
> Para la implementación estabamos pensando en el algoritmo heurístico 
> del primero el mejor, ya tenemos el algoritmo de hecho, pues se había 
> trabajado en una implementación anterior de planificación de rutas 
> turísticas pero en zonas rurales y este fue implementado sobre PLT 
> Scheme, porque fue el lenguaje en el que más rápido encontraba las rutas.
> La idea ahora es una ciudad, pero tenemos dudas con respecto a la 
> definición de nodos (trayectos) de entrada, porque en este caso, no 
> necesariamente la ruta más corta es la mejor, y no queremos meter 
> todos los nodos posibles en el sistema. Mejor dicho, queremos hacer 
> que el sistema haga una especie de buffer (mas no exactamente radial) 
> en la zona que envuelve a los dos puntos (inicio y llegada) y que no 
> trate de buscar por zonas muy alejadas, porque la malla vial es grande 
> lo que puede hacer que busque en tramos alejados y la característica 
> principal del sistema debe ser la rapidez.
>
> La verdad es que además estamos empezando con GvSIG, porque hemos 
> trabajado con SIG, pero GEOMEDIA y ArcView 3.2 y ArcGIS, sólo que esta 
> vez queremos que el sistema este disponible (bueno económicamente 
> disponible).
>
> Sobre el piloto, hemos probado muy poco, algunas consultas empíricas 
> que sólo tienen como peso el sentido, dado que la base de datos para 
> pruebas se está terminando de ajustar.
>
>
> Gracias de nuevo
>
> On 8/11/07, *Francisco José Peñarrubia* <fpenarru en gmail.com 
> <mailto:fpenarru en gmail.com>> wrote:
>
>     Hola Materia Angélica.
>
>     De manera rápida:
>     El algoritmo que se usa para calcular la mejor ruta es el A* o A
>     "star"
>     en literatura anglosajona.
>     ( http://en.wikipedia.org/wiki/A*_search_algorithm)
>     También hemos implementado una versión retocada del algoritmo
>     Dijkstra,
>     que se puede usar para calcular el camino minimo o, mucho mejor, para
>     calcular matrices de distancias, áreas de influencia y unas cuantas
>     cosas más. (http://es.wikipedia.org/wiki/Algoritmo_de_Dijkstra).
>     Lo del
>     retocado es porque necesitamos soporte para costes de giro en el
>     futuro.
>
>     En cuanto a la documentación, al ser un piloto no era crítico.
>     Actualmente estamos en proceso de hacer el análisis y el diseño
>     detallado del proyecto, y sí estamos generando documentación a
>     nivel de
>     desarrolladors, aunque no está terminada todavía.
>
>     Si necesitas más información, ponte en contacto con nosotros y veremos
>     qué se puede hacer. Nos gustaría saber también qué uso exacto quereis
>     implementar, y opiniones acerca de lo que habeis visto en el piloto,
>     mejoras que se os ocurren, sugerencias, etc.
>
>     Saludos, y gracias por el interés.
>
>     Francisco José Peñarrubia.
>     Equipo gvSIG.
>     Materia Angelica escribió:
>     > Estamos trabajando en un proyecto para generar rutas en una
>     ciudad con
>     > GvSIG y PostGIS y estamos analizando diferentes métodos para la
>     > planificación de rutas. Hemos revisado un poco el piloto de
>     redes que
>     > publicaron en la página y nos gustaría saber si hay alguna
>     > documentación del método empleado para la determinación de la mejor
>     > ruta o de las clases empleadas en el pluggin.
>     >
>     > Mientras hemos revisado algunas de las clases del JTS  de
>     > vividSolutions, pero tenemos dudas respecto a la implementación.
>     >
>     >
>     > Muchas Gracias.
>     >
>     >
>     > (NOTA ACLARATORIA: Tenemos desviado el correo hacia
>     > iue.geosig en gmail.com <mailto:iue.geosig en gmail.com> <mailto:
>     iue.geosig en gmail.com <mailto:iue.geosig en gmail.com>> y habíamos escrito
>     > este mensaje desde allí)
>     >
>     > Juan Alberto Agudelo
>     > Ingeniero de Sistemas
>     > Institución Universitaria de Envigado
>     >
>     > --
>     > Angélica María Gómez
>     > Docente
>     > Institución Universitaria de Envigado
>     > Universidad de Antioquia
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > gvSIG_desarrolladores mailing list
>     > gvSIG_desarrolladores en runas.cap.gva.es
>     <mailto:gvSIG_desarrolladores en runas.cap.gva.es>
>     > http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>     >
>     _______________________________________________
>     gvSIG_desarrolladores mailing list
>     gvSIG_desarrolladores en runas.cap.gva.es
>     <mailto:gvSIG_desarrolladores en runas.cap.gva.es>
>     http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>
>
>
>
> -- 
> Angélica María Gómez
> Docente
> Institución Universitaria de Envigado
> Universidad de Antioquia
> ------------------------------------------------------------------------
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>   

------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : service_area_madrid.gif
Tipo       : image/gif
Tamaño     : 97048 bytes
Descripción: no disponible
Url        : http://runas.cap.gva.es/pipermail/gvsig_desarrolladores/attachments/20070813/6e687d45/service_area_madrid-0001.gif