[Gvsig_desarrolladores] Proyecto fin de carrera - gvSig Extension
- Analisis de la RED
Simone Casciaroli
simone.casciaroli en gmail.com
Mar Mar 20 18:31:17 CET 2007
Hola Francisco,
Is it possible to know in which release this function will be added?
What about the 1.0.2 release in wich you planed to introduce these
enhancement, Is it post-planed?
Bye
Simone Casciaroli
On 3/20/07, Francisco José Peñarrubia <fran.penarrubia at iver.es> wrote:
>
> Hola Miguel.
>
> Esto es lo que está planificado en cuanto a redes:
>
>
> 1. Topología de redes
>
> Es la topología sobre un tema de arcos interconectados. Se trata de
> implementar en gvSIG herramientas que resuelvan los problemas con redes. Por
> red se entiende un sistema interconectado de elementos lineales (carreteras,
> líneas telefónicas, líneas eléctricas, etc.).
>
> Las funcionalidades a desarrollar sobre gvSIG en este ámbito son:
>
> 1. Creación de la red
>
> Los SIG que trabajan con redes disponen de una herramienta que genera la
> red a partir de un tema seleccionado (lógicamente de líneas).
>
> -
>
> *Selección de tema base de la red.* Una mejora considerable sería
> poder seleccionar varios temas que compusieran la red (por ejemplo:
> imaginemos que tenemos distintos shapes con distintos niveles de la red de
> carreteras, uno con las principales, otro con las secundarias, etc. y
> queremos utilizar algunos de ellos para hacer el cálculo sin tener que
> unirlos en un único tema). Igualmente en el caso de trabajar con bases de
> datos espaciales / tablas.
> -
>
> Una vez seleccionado el tema (o los temas) debería existir la
> posibilidad de utilizar o no campos de información o restrictivos.
> -
>
> *Campos de elevación.* Muy útil cuando determinados
> elementos de la red se superponen a distintos niveles (ej. Un puente o
> túnel) por lo que no todos los ejes interconectados han de permitir el paso.
> Normalmente las cartografías suelen definir la elevación mediante dos
> campos, cota del nodo comienzo y cota del nodo final. Así, si dos nodos de
> extremos de arco tienen la misma cota, se establecerá la conectividad; si
> los valores son diferentes, no conectarán.
> -
>
> *Restricciones.* Existen cartografías que mediante un
> determinado campo definen el tipo de eje en la red, pudiendo no permitir el
> paso aunque forme parte de la red. Ejemplo: una calle peatonal en un
> callejero no permitiría el paso en una red para el paso de vehículos, pero
> sí en una para el uso de peatones. Por tanto deberían poder seleccionarse
> campos y valores restrictivos al paso.
> -
>
> *Giros / tiempos.* Debería existir la posibilidad de
> aplicar un "tiempo de retraso" en caso de producirse un giro, ya que la
> velocidad en la red podría disminuir. Esto sería general para todos los
> giros (o incluso aplicar un tiempo para los giros a derechas y otro para los
> giros a izquierdas).
> -
>
> *Giros / restricciones.* Hay cartografías que contienen
> un campo de atributos que indica cuando está permitido el giro y cuando no.
> -
>
> *Direcciones de tráfico.* Debería existir la posibilidad
> de utilizar un campo para tener en cuenta los sentidos de tráfico (en
> sentido del eje digitalizado, en sentido contrario, ambos sentidos o
> ninguno).
> -
>
> *Costes / velocidades.* Se deben poder seleccionar el
> campo que contiene la jerarquía de la red y / o las velocidades a aplicar.
> En caso de existir la jerarquía pero no la velocidad correspondiente a cada
> valor, ha de existir la posibilidad de definirla.
> -
>
> *Conexión entre redes.* Debe existir la posibilidad de conectar
> varias redes entre sí. Por ejemplo, la red de metro y la red de autobuses de
> una ciudad, de cara a calcular rutas utilizando ambos medios de transporte.
> -
>
> *Propiedades de la red.* Otra opción interesante es poder acceder en
> cualquier momento a las propiedades de la red definida, pudiendo variarlas y
> recalculando la red.
>
>
>
>
> 1. Cálculo de rutas óptimas
>
> El *objetivo* de esta función es encontrar la ruta más rápida o la más
> corta entre un punto de partida y uno de llegada.
>
> Mediante esta herramienta el usuario ha de poder seleccionar, además del
> punto inicial y el punto final, el *número de paradas* o puntos
> intermedios de la ruta, en caso de haberlos.
>
> La selección de los puntos que componen la ruta debería poder ser tanto
> gráfica como alfanumérica (campo dirección + campo número de portal, por
> ejemplo). Los puntos seleccionados deben marcarse como gráficos en pantalla,
> de modo que sea fácil su localización visual. Otra manera útil de
> seleccionar los puntos es mediante un tema existente que los contenga.
>
> En caso de que el punto seleccionado (en el caso de selección gráfica) no
> esté dentro de la red, el programa debe indicarlo y permitir un
> desplazamiento gráfico hasta que se ubique en la red.
>
> En todo caso debe existir la opción de indicar un *orden "de visita"* de
> los puntos intermedios, es decir, que la ruta siga un orden indicado por el
> usuario (punto de salida, punto intermedio 1, punto intermedio 2,…, punto
> final) o que simplemente tenga como referencia fija en el orden los puntos
> inicial y final.
>
> Debería existir la posibilidad de dar *tiempos de parada*, tanto
> especificados por el usuario como a partir de un atributo.
>
> Otra opción interesante es la posibilidad de añadir barreras, esto es,
> inutilizar para el cálculo y de manera temporal (es decir no en la red) uno
> de los ejes. Estas barreras se añadirían tanto gráficamente como por
> selección alfanumérica. Útil para no tener en cuenta un eje de la red que
> está inoperante temporalmente, por ejemplo, en una red de carreteras por un
> accidente.
>
> Debe existir la posibilidad de *guardar las rutas* como nuevos temas.
>
>
>
>
> 1. Localización de la ubicación más cercana
>
> Se trata de una variación del caso anterior. Partiendo de una serie de
> posibles puntos de partida, se debe seleccionar el más cercano al punto
> final, al tiempo que se calcula la ruta. Una utilidad de ejemplo: distintas
> estaciones de bomberos que pueden atender un incendio.
>
> El usuario deberá seleccionar el tema que compone los puntos de partida y
> señalar gráfica o alfanuméricamente el punto de llegada o incidencia.
> Podrían existir distintos puntos de incidencias, por lo que el cálculo
> debería ser de varios puntos de partida a varias incidencias.
>
> En todo caso el resultado podría ser guardado como un tema.
>
>
>
> 1. Generación de áreas de servicio basadas en tiempos de viaje
>
> Las áreas de servicio son los polígonos resultantes del cálculo de
> distancias, teniendo en cuenta tiempos de viaje, a partir de unos
> determinados puntos.
>
> Debemos seleccionar el tema de puntos a partir del cual se va a realizar
> el cálculo, o bien indicar los puntos de manera gráfica o alfanumérica. Las
> velocidades podrán indicarse a partir de un campo de atributos o de forma
> manual.
>
> Deben existir las mismas opciones que en la herramienta de "buffer / área
> de influencia" respecto a los polígonos resultantes, es decir:
>
> -
>
> Posibilidad de que los polígonos resultantes se intersecten o no.
> (ver dibujo izquierda)
> -
>
> Posibilidad de tener varios anillos concéntricos.
> -
>
> Posibilidad de que los polígonos concéntricos se recorten entre sí.
> (ver dibujo derecha)
>
> Los resultados deben poder guardarse como un nuevo tema.
>
>
>
>
> 1. Cálculo de matrices de distancias.
>
> Consiste en el cálculo de matrices de distancias a partir de un tema de
> puntos. Se trata de obtener una tabla resultante en la cual aparecen
> calculadas las distancias de cada uno de los puntos al resto.
>
>
> En el piloto (de pronta publicación) hicimos lo necesario para crear una
> red (definir automáticamente los nodos y arcos de la red partiendo de una
> capa de gvSIG), añadir las paradas y calcular ruta óptima, mostrando
> información de por dónde pasaba la ruta.
> Además, lo hemos hecho con compatibilidad para JUNG, por si alguno quiere
> ampliar.
>
> Más información en próximos telediarios :-).
>
> Gracias por tu oferta, y seguiremos en contacto.
>
> Saludos
>
>
> Miguel Alvarez Ubeda escribió:
>
>
> Hola
>
> me llamo Miguel y soy estudiante de Ingenieria tecnica informatica de
> Gestion
> de la universidad de A Coruña, en ultimo año de curso y ando realizando un
> Proyecto fin de carrera haciendo una extension para el GvSig en principio
> dedicada
> a ser una "Herramienta de análisis de redes en un sistema de información
> geográfica"
> realizada en java y usando una BD para las pruebas en postgreSQL de
> Galicia.
>
> Agradeceria mucho toda informacion de desarrolladores para crear
> extensiones en java
> me la enviasen a esta cuenta de correo y gente que este en situacion
> similar bien sea con el mismo proposito o simplemente para colaborar
> mantener el contacto.
>
> Incluso me seria muy útil que me indicaseis novedades que estais pensando
> para
> posteriores versiones que pudiera realizar, para asi no realizar el
> trabajo duplicado.
>
> Gracias por antemano.
> --
> //\/\ A U
> /************************************************************************
> Miguel Álvarez Úbeda
> ingmau00 at gmail.com
>
> ************************************************************************/
>
> --
> //\/\ A U
> /************************************************************************
> Miguel Álvarez Úbeda
> ingmau00 at gmail.com
>
> ************************************************************************/
>
> ------------------------------
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores at runas.cap.gva.eshttp://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores at runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://runas.cap.gva.es/pipermail/gvsig_desarrolladores/attachments/20070320/dfc04aca/attachment-0001.htm
Más información sobre la lista de distribución gvSIG_desarrolladores