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

Vie Abr 8 08:53:21 CEST 2005

Hola Alvaro, gracias por la respuesta.

La opción de datos en local y bloquear los datos que te has bajado yo la 
usaría para el usuario que va a editar algo, pero no para el usuario que 
solo quiere visualizar, y dejaría a su criterio cuándo quiere "refrescar" y 
tener la última versión de la base de datos.

Bajo mi punto de vista, los usuarios que editan suelen ser pocos, y los que 
visualizan muchos. Y las ediciones pasan (o deberían pasar) una serie de 
controles antes de subir TODA el area de trabajo que estaban editando al 
servidor. Además, estas subidas muchas veces se avisan de diferentes formas. 
Por ejemplo, si estás trabajando con planeamiento, la modificación de un 
PGOU, o el desarrollo de un Plan Parcial conlleva que cuando se publican 
esos datos se ponen en marcha los avisos legales pertinentes.... etc. (Ya sé 
que es un versión limitada del uso de una base de datos espacial, lo ideal 
sería que no hubiera lecturas "fantasma").

Pero, como dice un cliente nuestro: "Lo mejor es enemigo de lo bueno muchas 
veces". En este caso, si bloqueamos con una simple lectura, estamos 
limitando el uso de la base de datos por unos pocos usuarios, que verían 
zonas que no se podrían bajar hasta que las actualizaciones se han 
completado, y esas actualizaciones llevan tiempo (suelen ser de zonas, como 
ya he dicho).

En cuanto a lo de mirar ArcEditor, lo haremos y preguntaremos cómo lo hacen 
en el Ayto. de Valencia, pero me suena que una cosa es lo que tiene 
ArcEditor por debajo y otra cosa es cómo lo usan en este tipo de sitios (con 
un CAD Client que se descarga una zona, se edita con tranquilidad y se sube 
al servidor. NO se edita con ArcEditor.

Y lo de la topología, me parece fundamental, y me lo apunto. Y supongo que 
Gabi también toma nota.... :-).

Pues nada más. Muchas gracias por tu opinión, porque sabes que la considero 
de mucho peso.

Y ya de paso, saludos de Óscar Gómez, que estuvimos hablando el miércoles.

Un saludo.

Francisco José Peñarrubia

IVER T.I. S.A.
Salamanca, 50
46005 Valencia
Tel: 963163400

----- Original Message ----- 
From: "Alvaro Zabala" <azabala en gmail.com>
To: "desarrolladores de gvSIG,el SIG libre y multiplataforma de la 
Generalitat Valenciana" <gvsig_desarrolladores en runas.cap.gva.es>
Sent: Friday, April 08, 2005 8:13 AM
Subject: Re: [Gvsig_desarrolladores] Consulta a todos los interesados 
acercadel acceso a bases de datos espaciales.

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

_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores en runas.cap.gva.es
http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores