[Gvsig_usuarios] Piloto de redes

[Jesús de Diego Alarcón]

Francisco, Álvaro

Bueno, la verdad es que no lo acabo de ver claro...Los desarrollos de la
parte de topología que señala Álvaro me temo que no solucionarán mi
problema.

El problema es que, al menos con los datos que yo manejo, por ejemplo (es un
ejemplo de redes de distribución de agua, aunque aplicable a cualquier red),
las acometidas (las tomas desde las tuberías a las parcelas, lotes,
viviendas, etc...) no cortan la tubería (no crean, ni deberían hacerlo, ..
ningún nodo), y uno de los nodos (de la acometida) debe situarse
directametne sobre la tubería...Necesito poder identificar de forma unívoca
la acometida con la tubería sobre la que se sitúa....

La validación de la cardinalidad, por ejemplo, también es importante para el
control topológico de la red (y esta debe hacerse teniendo en cuenta,
además, que no todos los nodos están en la misma capa...)

En todo caso, creo que lo mejor será probar con estos datos para ir viendo
qué puedo hacer y que no, y de lo que no... que se puede imlementar de forma
sencilla....
Sobre los desarrollos de topología, y aún teniendo delante la hora de
ruta...mm....¿algo más de precisión en las fechas ?¿Habrá piloto?

Saludos y gracias por todo

Jesús de Diego

El día 11/02/08, Francisco José Peñarrubia <fpenarru en gmail.com> escribió:
>
>  Hola.
>
> La parte de topología no se pudo presentar en las jornadas,  pero
> indudablemente es una de las partes más interesantes e importantes del
> pliego, junto con simbología avanzada. La parte de redes está relacionada
> con topología y simbología avanzada, aunque procuramos no molestarnos
> demasiado (ya sabes, desacoplamiento entre modulos).
>
> De lo que apuntas sobre si soportará segmentación dinámica, modelizar con
> puntos y líneas, cardinalidad.... No sé exactamente a qué te refieres.
> Necesitaríamos una descripción más detallada, con casos de uso, o si lo
> prefieres, con alguna sugrencia del tipo "Añadir este método a GvNode, o
> implementar este algoritmo, o permitir hacer subclases de un arco".
>
> De las cosas que planteas, o de lo que se necesitaría hacer para hacer una
> aplicación de gestión de redes de agua usando los objetos que ya tenemos, yo
> tengo mi idea. Y la verdad, no veo demasiados inconvenientes en implementar
> ese tipo de cosas sobre lo que hay, o al menos una vez que esté implementado
> lo de los TurnCosts y el recorrido inverso.
> En su día ya trabajé con un conversor de redes de Epanet a ArcView +
> Network Analist, y en Iver se han hecho aplicaciones de gestión de redes de
> agua utilizando ArcMap + la extensión de redes. Las funcionalidades
> implementadas en esos proyectos se podrían pasar a gvSIG (eso sí, con tiempo
> y una caña, porque la mayoría del trabajo, no nos engañémos, siempre tiene
> que ver con el trabajo de edición y adaptación al cliente). La librería de
> rutas de abajo se encarga de recorrer la red, y se usa solo en determinados
> cálculos. El resto de funcionalidades se montan en otro nivel de
> abstracción.
>
> Por otro lado, y previendo el que nos quedaramos cortos en algún área, en
> el piloto de redes incluso se incluye un ejemplo de conversión de nuestro
> modelo a la librería JUNG, que tiene ya unos cuantos años de experiencia, y
> algoritmos implementados que se utilizan en otras áreas (no solo algoritmos
> para rutas). Así que si lo prefieres, puedes emplear esa librería. (En su
> día no se usó por cuestiones de consumo de memoria y velocidad. Notarás que
> nuestra librería es considerablemente más eficiente en esos aspectos).
>
> Nada más, suerte con tu proyecto de aguas, y lo dicho, si tienes alguna
> sugerencia de incluir algo como lo que dijiste de GvNode.getCardinality(getInCardinality = arcos de entrada al nodo y getOutCardinality = arcos de
> salida del nodo), bienvenida sea.
>
> Saludos.
>
> Fran.
> Equipo gvSIG.
>
> Jesús de Diego Alarcón escribió:
>
> Gracias Fran por la respuesta.
>
> En realidad, desconocía que hubiese desarrollos orientados a la gestión de
> topología.
> ¿Tienes más información?¿Hay algo en la Web? (antes de escribir cosulté
> las ponencias de las últimas jornadas, pero juraría que no vi nada...)
>
> En todo caso, las funcionalidades que te comento no son específicas del
> tratamiento de redes de agua:
>
> - la posibilidad de modelizar la red con diferentes capas , tanto de
> líneas como de puntos.
> - segmentación dinámica de líneas (de tal manera que puedo poner un objeto
> en medio de una línea sin generar un nodo y el objeto, además, puede tener
> comportamiento: abierto/cerrado).
> - la posibilidad de definir o validar la cardinalidad topológica de los
> objetos que conforman la red...
>
> Se trata de funcionalidades bastante genéricas... y por eso me asalta la
> duda:
> Si se pueden implementar estas funcionalidades desde los nuevos
> desarrollos de gestión topológia, ¿van a funcionar igualmente los algoritmos
> que habéis desarrollado para esta parte
> (caminos optimos, por ejemplo....) sobre estas nuevas redes?
>
> Saludos y gracias por todo
>
>
> Jesús de Diego
>
>
>
>
>
>
>
>
> El día 7/02/08, Francisco José Peñarrubia <fpenarru en gmail.com> escribió:
> >
> > Hola.
> >
> > En el piloto de redes está la funcionalidad que había que hacer para el
> > pliego. Ten en cuenta que luego hay cambios, y es probable de algunas de las
> > cosas que planteas tengan solución.
> > De hecho, de lo que has dicho, yo diría que muchas cosas ya se pueden
> > hacer.
> >
> > De todas formas, la idea con lo de redes es tener una base sobre la que
> > construir cosas. Es decir, tendremos una librería con las funcionalidades
> > que pueda tener Network Analyst, o la librería NetEngine. Sobre esos
> > modelos, la gente ha hecho sus aplicaciones para redes de aguas, eléctricas,
> > gas o cable. Así que las posiblidades sí que estarán.
> >
> > En cuanto a funcionalidades de mayor nivel (quiero decir, a nivel de
> > usuario), nosotros implementaremos las habituales que vienen en los GIS
> > genéricos y alguna que otra más. El resto de aplicaciones, entiendo que son
> > eso, aplicaciones a desarrollar por consultorías, como si fuese alguien que
> > compra AV+Network Analyst y sobre eso programa sus propias extensiones.
> >
> > De lo que apuntas (y que no está hecho todavía, pero estamos en ello),
> > se va a resolver el problema de buscar las válvulas que hay que cerrar para
> > aislar una zona. Eso tiene que ver con un recorrido inverso por la red, que
> > no está hecho, pero que estará cuando se libere la versión definitiva.
> >
> > En cuanto a las cosas de cardinalidad topológica, edición de la red,
> > etc. creo que tienen que ver más con lo que se está desarrollando en
> > paralelo de topología, que están implementando reglas topológicas de ese
> > tipo.
> >
> > En mi opinión,  de las cosas que más se pueden echar en falta (y que no
> > es simple de hacer) en el piloto de redes es el trabajar con TurnCosts.
> > Todavía no hemos pasado a java esa parte, así que no puedo decir que eso ya
> > está. Con eso se podría modelar perfectamente lo de las válvulas que dejan
> > pasar agua en un sentido o no, desviarla por otra tubería, etc.
> >
> > Otras cosas, como calcular la cardinalidad de los nodos de la red, son
> > más sencillas de hacer, aunque claro, siempre podemos incluir una función
> > dentro de GvNode al estilo de getCardinality(). Es más, lo tomo como una
> > sugerencia, y pondremos algo así. Y un getIncidentArcs también nos vendrá
> > bien, para el recorrido inverso.
> >
> > Bueno, nada más. Lamento que te haya decepcionado el piloto, espero que
> > la versión definitiva cumpla mejor las expectativas.
> >
> > Saludos.
> >
> > Fran.
> > Equipo gvSIG.
> >
> > Jesús de Diego Alarcón escribió:
> >
> > Saludos
> >
> > He estado probando el piloto de redes con la idea de usar esta extensión
> > para la gestión de redes, en mi caso, de distribución de agua.
> >
> > Sin embargo, por lo que estoy viendo, parece que la extensión está más
> > bien pensada para la gestión de rutas (un tipo de red) que para la gestión
> > genérica de redes...
> >
> > Echo en falta la posibilidad de poder generar topología de red con
> > información en varias capas: tuberías y acometidas, por ejemplo, tienen
> > modelos de datos diferentes y es difícil acoplarlas en la misma capa....
> > Enlazando con esto, también veo que no hay herramientas que permitan
> > gestionar/editar las relaciones que existan entre estos elemetos: una
> > acometida se debe situar sobre la tubería, pero no debe partirla (generar un
> > nuevo nodo...)
> > Tampoco veo ninguna posibilidad de gestionar diferentes capas de nodos,
> > ni tipologías dentro de los nodos, ni tampoco la cardinalida "topológica" de
> > estas tipologías (del tipo: la válvula del tipo A debe conectar 3 tuberías y
> > la del tipo B sólo 2).
> > Tampoco existe la posibilidad de gestionar elementos puntuales sobre la
> > red que controlen el flujo por la misma (válvulas que se abren  y se
> > cierran, por ejemplo) y en cuanto al análisis... pues hecho también en falta
> > un algorítmo de cálculo de sectores (o, dado un punto, ver cual es el número
> > mínimo de válvulas que es necesario cerrar para aislarlo del resto de la
> > red... vamos ).
> >
> > He mirado también en la documentación de las pasadas Jornadas de gvSIG y
> > veo que los desarrollos previstos tampoco van en esta línea.
> > ¿Es eso así? ¿Están previstos en un futuro próximo estos desarrollos?
> >
> > La verdad es que me ha decepcionado un poco sobre todo porque el mundo
> > de las redes es un poco más complejo que la gestión de rutas...
> >
> > --
> > Jesús de Diego Alarcón
> > jesdial en gmail.com
> >
> > ------------------------------
> >
> > _______________________________________________
> > gvSIG_usuarios mailing list
> > gvSIG_usuarios en runas.cap.gva.es
> >
> > Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección:
> >
> > http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
> >
> >
> >
> >
> > _______________________________________________
> > gvSIG_usuarios mailing list
> > gvSIG_usuarios en runas.cap.gva.es
> >
> > Para ver histórico de mensajes, editar sus preferencias de usuario o
> > darse de baja en esta lista, acuda a la siguiente dirección:
> >
> > http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
> >
> >
>
>
> --
> Jesús de Diego Alarcón
> jesdial en gmail.com
>
> ------------------------------
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
>
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección:
>
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
>
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
>
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>


-- 
Jesús de Diego Alarcón
jesdial en gmail.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://runas.cap.gva.es/pipermail/gvsig_usuarios/attachments/20080212/50e7fbc8/attachment.htm