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

Lun Abr 11 10:02:33 CEST 2005

Hola Colega!!!.

Encantado de verte por esta lista.... :-) (Si no has hablado todavía con 
Gabi sobre lo del "tejido empresarial, etc, etc", va siendo hora de que lo 
hagas, te gustará).

En cuanto al tema que nos ocupa, gracias por los comentarios, parece que la 
opción de implementar primero lo de trabajar en "modo desconectado" va 
cobrando fuerza (o al menos eso entiendo yo).

Es casi seguro que el modo "conectado" también se implemente, pero más 
tarde. Necesitamos hacer uno para mostrar en el GIS Planet, en Portugal.

De todas formas, hemos mirado qué hacen en otros sitios, y utilizan los 2 
sistemas, dependiendo del tipo de actualizaciones. Y buscando en la 
documentación de ArcGIS, hemos encontrado 5 escenarios posibles. Los apunto 
aquí para que todos sepamos de qué estamos hablando:

Versioning scenarios
The following scenarios show how an organization can implement its work flow 
process using a versioned database. These examples demonstrate several 
techniques available for performing long transactions in a multiuser 
environment. It is likely that organizations will, in some manner, use each 
of these techniques depending on the task.

Scenario 1: Simple database modifications
Task: Multiple users are concurrently editing the database, performing 
common map sheet changes such as inserting new features, updating 
attributes, and removing out-of-date facilities.

Scenario 2: Transactions spanning multiple days
Task: Update the database to incorporate new and updated facilities in the 
field, which will likely require multiple edit sessions and a couple of days 
to complete.

Scenario 3: A work flow process
Task: Create individual versions for each step or stage of the work order 
and work flow process and post the work order to the database.

Scenario 4: Restricting permissions to the database
Task: The organization's supervisor has restricted write access to the 
DEFAULT version, requiring managerial review of each user's edits prior to 
posting the changes to the database.

Scenario 5: Compressing the database
Task: The geodatabase has been edited for an extended time, and the number 
of database states and rows in each feature class's delta tables has 
significantly increased. How do we improve performance by running the 
Compress command?

ArcMap da solución a cada uno de estos escenarios, pero apoyandose mucho en 
la capacidad de ArcSDE de crear "versiones" de una base de datos espacial. 
Esta posibilidad ahora mismo creo que no la tenemos con PosgreSQL + PostGIS, 
ni con mySQL Spatial, así que si se necesita funcionar al estilo de un 
repositorio CVS, es un campo de trabajo por explorar (y por plantear a 
Conselleria o a quién esté interesado). Es lo suficientemente amplico como 
para generar otro proyecto aparte (crear una base de datos espacial al 
estilo de ArcSDE sobre un gestor open source).

Bueno, creo que ahora sí tenemos una visión más global del problema, y le 
plantearemos a Conselleria todo esto para que decida.

Saludos a la gente de por allí, míos y de Felipe Polo ;-)

Francisco José Peñarrubia

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

----- Original Message ----- 
From: "Miguel Montesinos" <mmontesinos en prodevelop.es>
To: "desarrolladores de gvSIG,el SIG libre y multiplataforma de la 
Generalitat Valenciana" <gvsig_desarrolladores en runas.cap.gva.es>
Sent: Monday, April 11, 2005 2:03 AM
Subject: RE: [Gvsig_desarrolladores] Consulta a todos los interesados 
acercadelacceso a bases de datos espaciales.

Hola a todos,

como comentas en tu mail, ambas opciones tienen ventajas. Es probable que 
como sucede en las herramientas comerciales, se acabe teniendo que 
desarrollar ambas, por lo que al final todo se reduce a una cuestión de 
prioridades.

Simplificando mucho el problema, todo lo que se puede hacer con la opción 1 
es realizable bajo la opción 2. Sin embargo, para el caso de ediciones de 
grandes volúmenes de datos (o simplemente en el caso de ediciones "al final 
del día que no pueden acabarse") la opción 2 no es asimilable a la 1.

Recordando los GIS de hace 10 ó más años, un sistema basado en 
chekout/checkin es válido para la mayoría de casos, y sólo tiene el problema 
de tener que "refrescar" y alguna orden manual.

Por otro lado, aunque es lo más común, pienso que el bloqueo de zonas del 
mapa no tiene necesariamente porqué significar que que has de bajar los 
datos a local. Puedes trabajar con una copia sobre el servidor.

Respecto a la ventaja de la opción 1 de acercarnos a geoAPI, es cierto, 
aunque mientras JTS y GeoAPI no confluyan más, y mientras GeoAPI no esté un 
poco más "implementado" creo que es mejor simplificar y andar más pegado al 
suelo ;)

En resumen, puede dar soporte a una mayor variedad de casos (aunque no 
necesariamente ser más práctica) la segunda opción.

Enhorabuena por el trabajo

Miguel Montesinos

PRODEVELOP, S.L.
Conde Salvatierra, 34 - 10
Valencia

________________________________

De: gvsig_desarrolladores-bounces en runas.cap.gva.es en nombre de Francisco 
José Peñarrubia
Enviado el: jue 07/04/2005 18:42
Para: gvsig_desarrolladores en runas.cap.gva.es
Asunto: [Gvsig_desarrolladores] Consulta a todos los interesados acerca 
delacceso a bases de datos espaciales.

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