[Gvsig_desarrolladores] Consulta a todos los interesados acerca del acceso a bases de datos espaciales.

[Alvaro Zabala]

Hola Fran!
Yo a los pros y contras que has comentado, añadiría alguna
consideración más: la gestión/resolución de conflictos. Si trabajas
con los datos en local (opción B), tienes varias alternativas:
a) bloquear todos los datos que te has bajado.
a1) en principio, deberías bloquear tanto para lectura como para
escritura (si no, se daría lectura fantasma: alguien ve unos datos que
han cambiado)
b) no bloquear.

La opción de no bloquear obligaría a llevar una resolución de
conflictos, seguramente utilizando etiquetados de número de versión,
como en CVS (si haces un cambio sobre una geometría, y la vas a subir,
antes verificas qué número de versión tiene en la base de datos, si
éste es mayor que el de la que tú tenías, deberás resolver el
conflicto o guardarlo en una tabla de "conflictos"). Alternativas
basadas en sw como la que comentamos en zaragoza (tener un proceso en
cada cliente que reciba notificaciones sobre los cambios realizados
por otros clientes) no las he visto en ningún texto sobre integridad
de bbdd, y creo que no son viables porque basan la integridad en
procesos, que se pueden caer, y no en los propios datos.

En este sentido, seguramente sea mucho más sencillo de implementar el
bloqueo de los datos. En este caso, creo que sería mejor emplear la
opción A, permanentemente conectado. Así, solo bloqueas las geometrías
que vayas a editar (y sus adyacentes, para mantener las relaciones
topológicas). También hay que tener en cuenta que en los gises de hoy
en día se está perdiendo la "topología" (es decir, o se guarda
explícitamente que polígono está a la derecha o izquierda de otro),
por lo que los adyacentes se deberán obtener dinámicamente.

Yo de todos modos, lo que haría es fijarme en como lo hace ArcEditor +
ArcSDE, pues al fin y al cabo, es el e$tandar de facto en estos temas
(estándar que te puede salir por unos 60.000 euros...). Además de todo
esto, incluye conceptos como "reglas topológicas" (triggers
implementados bien con sw, bien en la base de datos para que se
cumplan determinadas relaciones).

Oracle, otro estándar "baratito", para el tema de edición desconectada
tenía un módulo que era Workspace Manager, que te daba utilidades para
la gestión de conflictos.

En cuanto a qué es lo que mas se puede demandar, hasta ahora me
encontrado con los dos casos, y depende mucho del tamaño del equipo de
cartografía de la organización.




On Apr 7, 2005 6:42 PM, Francisco José Peñarrubia <fpenarru en iver.es> wrote:
>  
> Hola a todos. 
>   
> Vereis, estamos preparando el acceso a las bases de datos espaciales de
> gvSIG (PostgreSQL, mySQL, ArcSDE, Oracle, etc), y nos ha surgido una
> cuestión que nos interesa lanzar al aire, para que aquellos interesados (y
> sobre todo, los que ya están trabajando con Bases de Datos Espaciales), nos
> den su opinión. 
>   
> Básicamente, se trata de decidir cual va a ser la forma más útil de trabajar
> con la BDS. Las opciones son 2: 
>   
> 1.- Permanentemente conectado. 
> 2.- Me conecto, bajo los datos de la zona que me interesa y trabajo en local
> de manera interna, con un botón para "refrescar" la zona cuando me interesa.
>   
> Pros y contras: 
>   
> PROS DEL PUNTO 1: 
> - Veo en todo momento cualquier cambio que ocurra en la BDS. Si hay una
> actualización de datos alfanuméricos o gráficos, cuando visualice esa zona
> veré la cartografía y los datos que vienen en ese instante de la base de
> datos. (PRO) 
> - Nos acercamos a la forma de trabajo que define geoAPI. 
>   
>   
> CONTRAS DEL PUNTO 1: 
> - Cargamos el servidor con mucho trabajo. 
> - Cargamos la red con mucho tráfico. 
> - Es una solución más costosa en tiempo (tanto de desarrollo como de manejo
> de la cartografía). 
> - Es posible que complique y/o ralentice la parte de selección y de uniones
> y enlaces con tablas. 
>   
> PROS DEL PUNTO 2: 
> - El servidor se libera de trabajo. 
> - La red se libera de tráfico. 
> - El usuario decide en todo momento cuándo desea trabajar con lo más actual.
> - Se podrían programar extensiones que permitieran realizar el equivalente a
> transacciones sobre BDS no transaccional, como por ejemplo mySQL. 
> - Mayor rapidez en la visualización y tratamiento de la información. (Hay
> que hacer notar que si se desea procesar algo en el servidor, también se
> puede hacer con esta opción, lanzando una SQL contra la base de datos). 
>   
> CONTRAS DEL PUNTO 2. 
> - Antes de ponerte en edición, necesitas "refrescar" tus datos. 
> - Necesitas espacio en disco para "bajarte" los datos y trabajar con ellos. 
>   
> Bueno, pues si me he dejado algo, nos lo podeis hacer saber. 
> Os agradecemos con antelación vuestra ayuda, y venga, que cuanto antes
> tomemos esta decisión, antes tendremos una versión con gvSIG leyendo de
> PostGIS y mySQL. 
>   
> PS: La respuesta de "las dos opciones" la podemos tener en cuenta, pero
> entonces os plantearía la pregunta de "¿Cual de las 2 antes?". 
> PS2: Si os inclinais por una u otra, nos interesa saber vuestras razones y/o
> casos reales con los que os hayais encontrado. 
>   
> Un saludo a tod en s, y gracias por colaborar. 
>   
> Francisco José Peñarrubia 
>   
> IVER T.I. S.A.
> Salamanca, 50
> 46005 Valencia
> Tel: 963163400 
>   
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
> 
> 
> 


-- 
Alvaro Zabala Ordóñez 
Miembro fundador de AGIL
Asociación para la promoción del GIS Libre
www.agiles.org

Funcionario del Cuerpo de Gestión de Sistemas e Informática de la
Administración General del Estado.
Confederación Hidrográfica del Guadalquivir. 
Teléfono: 954939523 
Plaza de España, sector II. 
SEVILLA