[Gvsig_usuarios] Piloto de redes

Mie Feb 13 12:19:07 CET 2008

OK

Gracias Álvaro

Jesús de Diego

El día 13/02/08, Alvaro Anguix <alvaro.anguix en iver.es> escribió:
>
>  Hola,
>
> Los pilotos son parte de la documentación que se entrega en las
> licitaciones. El piloto de la parte de redes, topología, etc. ya se publicó.
> Luego, como extensiones, se publican desarrollos menores (en cuanto a que
> no pertenecen a los grandes bloques de desarrollo), como pueda ser la
> reciente publicada de ArcSDE.
> Tanto las funcionalidades de los pilotos como las de las extensiones
> suelen aparecer integradas en la siguiente versión de gvSIG que se publica,
> en algunos casos -principalmente en el caso de los pilotos- mejoradas o
> modificadas para su integración.
> Lo más normal es que las funciones de topología vayan apareciendo en
> siguientes versiones de gvSIG, conforme avance el desarrollo de las mismas,
> conjuntamente con otros desarrollos que se están llevando en paralelo
> (redes, simbología avanzada, teledetección,...).
>
> Saludos,
> Alvaro Anguix
>
> Jesús de Diego Alarcón escribió:
>
> 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
>
> ------------------------------
>
> _______________________________________________
> 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
>
>
>
> --
>
> Este mensaje y sus archivos son confidenciales. No está permitida su
> reproducción o distribución sin la autorización expresa de "IVER Tecnologías
> de la Información". Si usted no es el destinatario previsto, queda
> desautorizado cualquier uso, acceso o copia de este mensaje. Si ha recibido
> este mensaje por error, por favor bórrelo e infórmenos por esta misma vía.
>
> _______________________________________________
> 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/20080213/85fade37/attachment-0001.htm