Post on 30-Jul-2020
Diseño técnico Integración con GIS-K
Biodiversidad
Versión 1.0 28/03/2008
Elaborado Aprobado
Pedro Correa / Amaya Mateos
UTE SITESA-GFI Norte
Pedro Isasi
DMAOT – Gobierno Vasco
Índice
1. Introducción...................................................................................................................5 1.1. Objetivo..........................................................................................................................5 1.2. Referencias....................................................................................................................5 1.3. Control de versiones......................................................................................................5
2. Arquitectura...................................................................................................................6
3. Diseño de la aplicación – vista estática ......................................................................7 3.1. Estructura general de la aplicación................................................................................7 3.2. Paquete s57bViewer......................................................................................................8 3.3. Paquete s57bBiodiversidadComun................................................................................9 3.3.1. Paquete s57b.biodiversidadcomun.model ..............................................................10 3.3.2. Paquete s57b.biodiversidadcomun.dao..................................................................11
3.4. Paquete s57bBiodiversidadBiz ....................................................................................12 3.4.1. Paquete s57b.biodiversidadcomunbiz.biz...............................................................13
3.5. Paquete s57b.parametrizacion ....................................................................................14 3.5.1. Paquete s57b. parametrizacion.Integration ............................................................14 3.5.2. Paquete s57b.parametrizacion.deploy....................................................................16
4. Integración BIO – GIS .................................................................................................17 4.1. Devolver Lista de Capas..............................................................................................18 4.1.1. Llamada ..................................................................................................................18 4.1.2. Respuesta...............................................................................................................18 4.1.3. Tratamiento GIS......................................................................................................18 4.1.4. Exposición en interfaz.............................................................................................18
4.2. Devolver Lista de Cruces.............................................................................................19 4.2.1. Llamada ..................................................................................................................19 4.2.2. Respuesta...............................................................................................................19 4.2.3. Tratamiento GIS......................................................................................................20 4.2.4. Exposición en interfaz.............................................................................................20
4.3. Ejecución y devolución de un Cruce de la aplicación ..................................................21 4.3.1. Llamada ..................................................................................................................21
Biodiversidad V:1.0 28/03/2008
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 2 de 49
4.3.2. Respuesta...............................................................................................................22 4.3.3. Tratamiento GIS......................................................................................................25 4.3.4. Exposición en interfaz.............................................................................................25
4.4. Obtención de los datos de los objetos del Cruce Localización de la aplicación ..........25 4.4.1. Llamada ..................................................................................................................25 4.4.2. Respuesta...............................................................................................................26 4.4.3. Tratamiento GIS......................................................................................................26 4.4.4. Exposición en interfaz.............................................................................................26
4.5. Devolver Lista de Búsquedas de la aplicación ............................................................27 4.5.1. Llamada ..................................................................................................................27 4.5.2. Respuesta...............................................................................................................27 4.5.3. Tratamiento GIS......................................................................................................27 4.5.4. Exposición en interfaz.............................................................................................27
4.6. Ejecución de una Búsqueda Cartográfica de la aplicación..........................................28 4.6.1. Llamada pasando extensión ...................................................................................28 4.6.2. Llamada pasando coordenadas..............................................................................28 4.6.3. Respuesta...............................................................................................................29 4.6.4. Tratamiento GIS......................................................................................................29 4.6.5. Exposición en interfaz.............................................................................................29
4.7. Ejecución de una Búsqueda Personalizada de la aplicación.......................................30 4.7.1. Llamada ..................................................................................................................30 4.7.2. Respuesta...............................................................................................................30 4.7.3. Tratamiento GIS......................................................................................................30 4.7.4. Exposición en interfaz.............................................................................................31
4.8. Ejecución de zonificación para una capa de la aplicación...........................................31 4.8.1. Llamada ..................................................................................................................31 4.8.2. Respuesta...............................................................................................................31 4.8.3. Tratamiento GIS......................................................................................................31 4.8.4. Exposición en interfaz.............................................................................................32
4.9. Conversión de Coordenadas .......................................................................................32 4.9.1. Llamada ..................................................................................................................32 4.9.2. Respuesta...............................................................................................................32
Biodiversidad V:1.0 28/03/2008
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 3 de 49
Biodiversidad V:1.0 28/03/2008
4.10. Visualización en el visor.............................................................................................33 4.11. Devolver extensión de objeto/capa............................................................................33 4.11.1. Llamada ................................................................................................................33 4.11.2. Respuesta.............................................................................................................34 4.11.3. Exposición en interfaz...........................................................................................34
4.12. Notas Aclaratorias .....................................................................................................34 4.12.1. Vistas a usar y su tratamiento...............................................................................34 4.12.2. Problema en el agrupamiento por identificador único...........................................36 4.12.3. Propuesta de parametrización para tipos de capas, cruces, cálculos y geometrías..........................................................................................................................................36
5. Volumen de datos y tiempos......................................................................................40 5.1. Marco de pruebas........................................................................................................40 5.2. Resultados de las pruebas ..........................................................................................41 5.2.1. Resultados de las pruebas con el BasicGeoprocessor ..........................................42 5.2.2. Resultados en las pruebas de cruces “feature a feature” .......................................44 5.2.3. Extrapolación al volumen real de datos ..................................................................46
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 4 de 49
Biodiversidad V:1.0 28/03/2008
1. Introducción 1.1. Objetivo
El objetivo de este documento es realizar el diseño técnico de la integración del
sistema de Biodiversidad con el GIS-K que la UTE SITESA-GFI Norte está
desarrollando para el DMAOT. Pretende dar una visión técnica de la aplicación dando
toda la información posible tanto sobre la vista estática (qué partes componen la
aplicación) como de la vista dinámica (cómo ejecuta las funcionalidades).
El presente documento está dirigido a personas con conocimientos técnicos de
informática, tanto a los responsables del proyecto dentro del DMAOT, como a los
responsables y desarrolladores del mismo dentro de la UTE SITESA-GFI Norte. A los
primeros para su validación y a los segundos como documento que dirige el desarrollo
y sirve de referencia para la implantación, depuración y mantenimiento del software
desarrollado.
1.2. Referencias
• Pliego “Sistema de Información de la Biodiversidad de la CAPV”
• Oferta “DISEÑO, CONSTRUCCIÓN Y PUESTA EN MARCHA DEL
SISTEMA DE INFORMACIÓN DE BIODIVERSIDAD DE LA CAPV”
• Diseño técnico del SCTA.
1.3. Control de versiones
Revisión Fecha Autor Motivo 1.0 28/03/2008 PCD Generación del documento.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 5 de 49
Biodiversidad V:1.0 28/03/2008
2. Arquitectura La Arquitectura será coherente con la que tiene actualmente el GISK. A continuación
se recoge el diagrama general de dicha arquitectura.
Cap
a de
Mod
elo
( VO
)
Cap
a de
Arq
uite
ctur
a ( H
elp)
Capa de Presentación o View
FrameWork Struts
Capa de Despliegue
Capa de Negocio
..... XLNet... BD AGS
Capa de Acceso a Datos o integración
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 6 de 49
Biodiversidad V:1.0 28/03/2008
3. Diseño de la aplicación – vista estática 3.1. Estructura general de la aplicación
La estructura general apenas ha sufrido cambios desde la anterior versión de la
aplicación, salvo algunas excepciones como:
• Se crea el Módulo de BiodiversidadComun
• Se crea el Módulo de BiodiversidadBiz
• Se crean los Módulo BiodiversidadEJB y BiodiversidadInterface para dar
acceso a otras aplicaciones a la nueva funcionalidad.
• Se crea el Módulo de Parametrización.
• Se amplía la funcionalidad del Módulo Visor.
Figura 1. Diagrama general de paquetes
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 7 de 49
Biodiversidad V:1.0 28/03/2008
3.2. Paquete s57bViewer
No cambia la estructura del paquete del visor. Sólo se aumentará su funcionalidad.
Para más información consultar el diseño técnico del SCTA.
pkg v iewer
integration
biz
commonconfig
constants
deploy
exception
model
ags
(from integration)
bd
(from integration)
dao
(from integration)
xlnet
(from integration)
Figura 2. Paquete s57bViewer
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 8 de 49
Biodiversidad V:1.0 28/03/2008
3.3. Paquete s57bBiodiversidadComun
El paquete s57bBioDiversidadComún contiene tanto el modelo de objetos de
biodiversidad necesario para realizar los cruces y las búsquedas como las clases
necesarias para el acceso a tablas de Oracle. No depende de los ArcObjects, por lo
que se podrá usar como en el .jar que se expondrá como interfaz “batch” de la
aplicación.
Figura 3. Paquete s57b.workflow
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 9 de 49
Biodiversidad V:1.0 28/03/2008
A continuación se describen los principales paquetes.
3.3.1. Paquete s57b.biodiversidadcomun.model El paquete s57b.biodiversidad.model contiene los paquetes con los objetos que
componen los distintos contenidos para los flujos de los módulos de parametrización,
y biodiversidad.
class s57bBiodiv ersidadComun.s57b.biodiversidad.model
S57BBusqueda
- buffer: boolean- infoCapa: S57BInfoCapa
+ getInfoCapa() : S57BInfoCapa+ isBuffer() : boolean+ S57BBusqueda()+ setBuffer(boolean) : void+ setInfoCapa(S57BInfoCapa) : void
S57BCapa
- columnaAgrupacion: String- columnaIdUnico: String- descripcion: String = ""- idGeometria: int- interna: boolean- nombreTablaAlfanumerica: String- simbologia: S57bSimbologia
+ equals(Object) : boolean+ getColumnaAgrupacion() : String+ getColumnaIdUnico() : String+ getDescripcion() : String+ getIdGeometria() : int+ getNombreTablaAlfanumerica() : String+ getSimbologia() : S57bSimbologia+ isInterna() : boolean+ S57BCapa()+ setColumnaAgrupacion(String) : void+ setColumnaIdUnico(String) : void+ setDescripcion(String) : void+ setIdGeometria(int) : void+ setInterna(boolean) : void+ setNombreTablaAlfanumerica(String) : void+ setSimbologia(S57bSimbologia) : void
S57BCruce
- batch: boolean- listaInfoCapas: List
+ addInfoCapa(S57BInfoCapa) : boolean+ getInfoCapa(S57BCapa) : S57BInfoCapa+ getInfoCapa(int) : S57BInfoCapa+ isBatch() : boolean+ S57BCruce(long)+ setBatch(boolean) : void+ size() : int
S57BEntidad
- apl icacion: String- descripcion: String = ""- pkidentificador: long
+ getAplicacion() : String+ getDescripcion() : String+ getPkidentificador() : long+ S57BEntidad()+ setAplicacion(String) : void+ setDescripcion(String) : void+ setPkidentificador(long) : void
S57bGeometria
S57BInfoCapa
- capa: S57BCapa- listaColumnas: List
+ equals(Object) : boolean+ getCapa() : S57BCapa+ getColumna(int) : String+ getIndexColumna(String) : int+ S57BInfoCapa(S57BCapa, List)+ size() : int
Serializable«interface»
S57BModelVO
S57BObjetoCapa
- capa: S57BCapa- valorObjeto: String
+ equals(Object) : boolean+ getCapa() : S57BCapa+ getValorObjeto() : String+ S57BObjetoCapa(S57BCapa, String)
S57BResultadoCruce
- crucePadre: S57BCruce- medida: double- objetosCapa: List
+ containsObjeto(S57BObjetoCapa) : boolean+ getCrucePadre() : S57BCruce+ getMedida() : double+ getObjeto(int) : S57BObjetoCapa+ getObjetosCapaSize() : int+ S57BResultadoCruce(long, S57BCruce, List)+ setMedida(double) : void
S57BResultadoInfoCapa
- infoCapaPadre: S57BInfoCapa- l istaValores: List- objetoPadre: S57BObjetoCapa
+ equals(Object) : boolean+ getInfoCapaPadre() : S57BInfoCapa+ getListaValoresSize() : int+ getObjetoPadre() : S57BObjetoCapa+ getValor(String) : Object+ S57BResultadoInfoCapa(S57BObjetoCapa, S57BInfoCapa)+ setValor(String, Object) : Object
S57BResultadosCruce
- cruce: S57BCruce- listaResultadosInfoCapa: List- resultadosCruce: List
+ addResultadoCruce(S57BResultadoCruce) : void+ addResultadosInfoCapa(S57BResultadoInfoCapa) : void+ containsResultadoCruce(S57BResultadoCruce) : boolean+ containsResultadoInfoCapa(S57BResultadosInfoCapa) : boolean+ getCruce() : S57BCruce+ getResultadoCruce(int) : S57BResultadoCruce+ getResultadoCruce(List) : S57BResultadoCruce+ getResultadosCruceSize() : int+ getResultadosInfoCapa(int) : S57BResultadosInfoCapa+ getResultadosInfoCapaSize() : int+ S57BResultadosCruce(S57BCruce)
S57BResultadosInfoCapa
- infoCapa: S57BInfoCapa- resultadosInfoCapa: List
+ addResultadoInfoCapa(S57BResultadoInfoCapa) : void+ containsResultadoInfoCapa(S57BResultadoInfoCapa) : boolean+ getInfoCapa() : S57BInfoCapa+ getResultadoInfoCapa(int) : S57BResultadoInfoCapa+ getResultadoInfoCapa(S57BObjetoCapa) : S57BResultadoInfoCapa+ getResultadosInfoCapaSize() : int+ S57BResultadosInfoCapa(S57BInfoCapa)
S57bSimbologia
+ S57bSimbologia()
-crucePadre
-simbologia
-capa
-infoCapa
-infoCapaPadre
-objetoPadre
-cruce
-infoCapa
-capa
Figura 4. Paquete s57b.biodiversidadcomun.model
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 10 de 49
Biodiversidad V:1.0 28/03/2008
3.3.2. Paquete s57b.biodiversidadcomun.dao El paquete s57b.biodiversidad.dao contiene los paquetes con el acceso datos (tablas
de oracle, ficheros, XMLs, etc.) necesario para rellenar los objetos del paquete
s57b.biodiversidadcomun.model.
Figura 5. Paquete s57b.biodiversidadcomun.dao
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 11 de 49
Biodiversidad V:1.0 28/03/2008
3.4. Paquete s57bBiodiversidadBiz
El paquete s57bBioDiversidadBiz contiene la lógica de negocio necesaria para
realizar los cruces y las búsquedas. El destino de esos cálculos puede ser bien el
visor, tablas de oracle, o archivos de intercambio con otras aplicaciones.
Figura 6. Paquete s57b.biodiversidadbiz
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 12 de 49
Biodiversidad V:1.0 28/03/2008
3.4.1. Paquete s57b.biodiversidadcomunbiz.biz El paquete s57b.biodiversidadcomunbiz.biz contiene clases de lógica de negocio para
las entidades del modelo.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 13 de 49
Biodiversidad V:1.0 28/03/2008
Figura 7. Paquete s57b.biodiversidadcomunbiz.biz
3.5. Paquete s57b.parametrizacion
El paquete de parametrización contiene los paquetes con las clases necesarias para
el funcionamiento del Módulo de Parametrización.
El estilo de las páginas del módulo de parametrización se puede consultar en el
documento: PI_IntegracionGISK_BIO_10.ppt
pkg adminscta
biz
common
deploy
help
integrationmodel
ags
(from integration)
bbdd
(from integration)
dao
(from integration)
xlnet
(from integration)
Figura 8. Paquete s57b.parametrización
A continuación se describen los principales paquetes:
3.5.1. Paquete s57b. parametrizacion.Integration El paquete s57b.parametrizacion.Integration contiene los paquetes con las clases
necesarias para la interacción con los sistemas Xlnets, Gestor de BBDD y ArcGIS
Server desde el Módulo de Parametrización.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 14 de 49
Biodiversidad V:1.0 28/03/2008
pkg adminscta.integration
ags
+ S57BMapServerObjectAGS
bbdd
+ S57BManagerBBDD
dao
S57BCapasSDEDAO S57BConnexionSDEDAO S57BDepartamentoDAO+ S57BFacadeDAO+ S57BIniciativaDAO+ S57BMapSerializeDAO S57BObjectDAO S57BPerfilDAO+ S57BSecuenciaDAO+ def
xlnet
+ S57BXlNetManager+ def
Figura 9. Paquete s57b.adminscta.Integration
Clase S57BMapServerObjectAGS
La clase S57BViewerBiz se encarga de recuperar datos del ArcGIS Server.
Atributos Nombre Tipo Visibilidad Función
config S57BConfig Private Almacena las propiedades y
configuraciones leídas de un
fichero creado para tal fin.
Métodos Nombre Devuelve Visibilidad Función
getAGSState(
S57BConfigurationObjectServer,
s57bConexionAGS)
S57BMapSerializado Public Recupera datos del ArcGIS
Server
getSOC( s57bConexionAGS) IServerObjectManager Private Recupera la conexión del
ArcGIS Server para un usuario
Manager
getSOM( s57bConexionAGS) IServerObjectAdmin Private Recupera la conexión del
ArcGIS Server para un usuario
Admin
listAGS( s57bConexionAGS) List Public Recupera un objeto List con
los objetos configuración para
la conexión s57bConexionAGS
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 15 de 49
Biodiversidad V:1.0 28/03/2008
Clase S57BXlNetManager
La clase S57BXlNetManager se encarga de establecer la conexión con el API de
XLNET.
Atributos Nombre Tipo Visibilidad Función
n38API N38API Friendly Almacena el API para la
conexión con Xlnets.
request HttpServletRequest Friendly Almacena un request hecho
desde la Web
Métodos Nombre Devuelve Visibilidad Función
getItemConfiguracion()
Document Public Método encargado de obtener
el xml que recoge los
parámetros del usuario
validado
getItemSeguridad(String)
Document Public Método encargado de
recuperar el xml de seguridad
de la aplicación en función
del usuario validado
getItemSesion()
Document Public Método encargado de obtener
el xml que recoge los
parámetros del usuario
validado.
init() Void Public Inicializa la conexión con el
API de XLNET
3.5.2. Paquete s57b.parametrizacion.deploy El paquete s57b.parametrizacion.deploy contiene las clases Actions y Form de Struts.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 16 de 49
Biodiversidad V:1.0 28/03/2008
4. Integración BIO – GIS En este apartado, se describe como se realiza la integración entre los diferentes
Sistemas (Biodiversidad – GIS).
Para ello se ha decidido usar EJBs como interfaces de integración por su sencillez,
rapidez y no limitación de tamaño en la devolución de la petición.
Se va a definir cada uno de los diferentes EJBs que van a existir, indicando la llamada
a realizar desde cualquier aplicación (en este caso Biodiversidad) y la respuesta que
ofrece GIS.
Para los procesos batch, debido a la arquitectura sostenida por EJIE, va a ser
imposible implementarlo mediante llamadas EJB, por lo que se usarán unas librerías
.JAR específicas para realizar esas operaciones.
Los parámetros escritos en cursiva son opcionales. Se deben pasar como null en caso
de no necesitarse.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 17 de 49
Biodiversidad V:1.0 28/03/2008
4.1. Devolver Lista de Capas
Se devuelve un XML con la información de las capas dadas de alta para la aplicación.
4.1.1. Llamada getListaCapas ((string)codXLNET,(date) fechaUltimaActualizacion).
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
fechaUltimaActualizacion es la fecha por la cual se quiere buscar las
actualizaciones que se han hecho de cálculos de geometría, igual o
posterior a ella. OPCIONAL
4.1.2. Respuesta Devuelve un HashMap con los siguientes datos de las capas:
• IdCapa (integer)
• Descripción (string)
• Nombre tabla alfanumérica (string)
• Geometría (integer)
• Fecha última actualización (date)
• Tipo capa (integer)
4.1.3. Tratamiento GIS Se devuelve la información para todas las capas que cumplan la condición.
4.1.4. Exposición en interfaz Se podrá realizar esta consulta tanto desde el EJB como desde las librerías jar.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 18 de 49
Biodiversidad V:1.0 28/03/2008
4.2. Devolver Lista de Cruces
Se encarga de devolver un listado de los cruces para una determinada capa dada de
alta en la aplicación que los llama (en este caso Biodiversidad).
4.2.1. Llamada getListaCruces ((string)codXLNET, (integer)idCapa, lista[(integer)idCapa],
(integer)idTipoCruce, (boolean)buffer, (boolean)batch,
(date)fechaUltimaActualizacion).
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo
devuelva los datos a los cuales esa aplicación tiene acceso.
OBLIGATORIO
idCapa es el identificativo de la capa de la cual se quiere obtener los
cruces en los que interviene. OBLIGATORIO
Lista[idCapa] es una lista con los identificativos de las capas que junto
con la capa anterior (idCapa) forman algún cruce. OPCIONAL
idTipoCruce es el tipo de cruce que el Sistema GIS debe devolver.
OPCIONAL
buffer si es true, se devuelven sólo los cruces con parámetro buffer > 0,
si es false, los que tienen buffer=0. OPCIONAL
batch si es true, se devuelven sólo los cruces batch, si es false, los
online. OPCIONAL
fechaUltimaActualizacion es la fecha por la cual se quiere buscar las
actualizaciones que se han hecho de cruces, igual o posterior a ella
OPCIONAL
4.2.2. Respuesta Devuelve una lista de HashMap con los siguientes datos de los cruces:
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 19 de 49
Biodiversidad V:1.0 28/03/2008
• IdCruce(integer)
• Tipo (integer)
• Batch (boolean)
• Buffer (double)
• Fecha última actualización (date)
• Descripción (string)
• ListaCapas
La lista de capas será otro Hashmap con los siguientes datos de capas:
• idCapa (integer)
• agrupado (boolean)
• ListaColumnas (ArrayList) -> será una lista de Hashmap, cada
uno con la siguiente información:
Nombre (string)
Descripción (string)
4.2.3. Tratamiento GIS Para que el Sistema GIS identifique los cruces lee la información del módulo de
parametrización.
4.2.4. Exposición en interfaz Se podrá realizar esta consulta tanto desde el EJB como desde las librerías jar.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 20 de 49
Biodiversidad V:1.0 28/03/2008
4.3. Ejecución y devolución de un Cruce de la aplicación
Se encarga de realizar un determinado cruce perteneciente a la aplicación que lo
llama (en este caso Biodiversidad).
Esta llamada sirve para recoger los datos de todo tipo de cruces parametrizables:
Cruces entre capas bio
Cruces entre capas bio y capas de datos
Cruces entre capas bio y capas de localización
Multicruces
Cruces con buffer/sin buffer
Cruces sin agrupar
Cruces batch/on-line
…
4.3.1. Llamada execCruce ((string)codXLNET, (integer)idCruce, (integer)idCapaOrigen,
(string)idObjeto)
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
idCruce es el identificativo del cruce del cual se quiere obtener el
resultado. OBLIGATORIO
idCapaOrigen-idObjeto sirve para determinar el par capa-objeto sobre el
que se quiere obtener el resultado. En caso de pasarse null, se
devolverá el resultado del cruce completo. OPCIONAL
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 21 de 49
Biodiversidad V:1.0 28/03/2008
4.3.2. Respuesta Devuelve un xml con los resultados del cruce, que son el identificativo del
cruce, y los resultados obtenidos (área, identificativo capa origen, identificativo
objeto origen, parámetro(s) objeto origen, identificativo capa destino,
identificativo objeto destino (si la capa destino fuera interna de la aplicación),
parámetro(s) objeto destino).
Será transparente a la aplicación cliente el hecho de que los cruces sean de
capas multipart o single siempre que en el cruce esté marcado a trae el flan
“agrupado” sobre cada capa.
En caso de que alguna de las capas no tenga geometría polígono, sino línea o
punto, las intersecciones serán también líneas o puntos, por lo que el área
intersecada será siempre 0.
A continuación se exponen los diferentes casos que se van a dar.
Antes, se exponen unas tablas para poder ver reflejado mejor el fichero xml
que se devuelve en cada uno de los casos.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 22 de 49
Biodiversidad V:1.0 28/03/2008
Cruce entre dos capas BioBio: execCruceBioBio.xml
Este xml devuelve para el cruce con identificativo “1”, los diferentes resultados
(en este caso 3) con el área implicada y a que objetos (su identificativo, su id
único) de cada capa pertenecen. Para el caso de que se quisiera una
información más amplia a nivel de objeto, en el módulo de parametrización de
cruces, se da la posibilidad de mostrar en el xml otra información relativa al
objeto que no sea su identificativo. En este caso para este cruce en relación a
la capa 1 no se ha seleccionado esa opción (por eso no aparece reflejada en el
xml), pero para la capa 2 sí, quedando reflejada, después de los resultados.
Esta información se muestra a nivel de capa, y dentro de cada capa, a nivel de
objeto, y dentro de cada objeto, a nivel de columna de información. Queda por
comprobar (por temas de rendimiento) de si esta última información va a ser
dada ordenada alfanuméricamente, o según se va procesando.
Cruce de Capa BIO con capa de datos (Parque Naturales-Litológico): execCruceBIODatos.xml
Este xml devuelve para el cruce con identificativo “2”, los diferentes resultados
(en este caso 4) con el área implicada y a que objetos (su identificativo, su id
único) de cada capa pertenecen, si la capa es bio; o sino, devuelve un idDato
(que para el sistema BIO le sirve para recoger la información de campos
reflejada a posteriori, por lo que el Sistema BIO no necesita ese dato salvo par
recoger esa información, no es un identificativo único para él, por eso se pone
idDato no idObjeto; pero al sistema GIS le viene bien ya que le sirve para
identificar qué objeto(OID) está implicado). Para el caso de que se quisiera una
información más amplia a nivel de objeto, en el módulo de parametrización de
cruces, se da la posibilidad de mostrar en el xml otra información relativa al
objeto que no sea su identificativo. En este caso para este cruce, se ha
seleccionado esta opción para las dos capas implicadas. Para la capa 1 esta
información se muestra a nivel de capa, y dentro de cada capa, a nivel de
objeto, y dentro de cada objeto, a nivel de columna de información. Queda por
comprobar (por temas de rendimiento) de si esta última información va a ser
dada ordenada alfanuméricamente, o según se va procesando. Para la capa 5
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 23 de 49
Biodiversidad V:1.0 28/03/2008
(la de datos) esta información se muestra a nivel de capa, y dentro de cada
capa, a nivel de dato, y dentro de cada dato, a nivel de columna de
información. Queda por comprobar (por temas de rendimiento) de si esta última
información va a ser dada ordenada alfanuméricamente, o según se va
procesando.
Cruce de Capa BIO con capa de localización: el formato es el mismo que el
de los cruces bio con datos.
Cruce con buffer: execCruceBuffer.xml
El formato es el mismo que el de un cruce normal bio-bio ó bio-datos, con las
siguientes diferencias:
Aparecerán como “resultadoCruce”, no sólo aquellos objetos que se
cruzan realmente, sino también aquellos separados por una distancia
menor que la marcada por el buffer
No se calcularán las áreas de los cruces.
Cruce con información de capa no agrupada: execCruceNoAgrupada.xml
El formato es el mismo que el de un cruce normal, salvo que en vez de hacerse
una agrupación por objeto, se hará por OID de la base de datos.
Permite extraer información diferente a nivel de registro de la base de datos,
por ejemplo, en el caso de una capa de puntos, permitiría obtener las
coordenadas de cada punto del objeto.
Multicruce: execMulticruce.xml
Se expone este xml, para visualizar y explicar cómo un multicruce va a quedar
reflejado (ya que se trata similar al cruce, con la diferencia de que van a estar
implicadas más de dos capas por cruce: dos o más bio y una de municipios).
Este xml devuelve para el cruce con identificativo “1”, los diferentes resultados
(en este caso 3) con el área implicada y a que objetos (su identificativo, su id
único) de cada capa pertenecen, si la capa es bio; o sino, devuelve un idDato
(código del municipio) para el municipio (que para el sistema BIO le sirve para
recoger la información de campos reflejada a posteriori, por lo que el Sistema
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 24 de 49
Biodiversidad V:1.0 28/03/2008
BIO no necesita ese dato salvo par recoger esa información, no es un
identificativo único para él, por eso se pone idDato no idObjeto; pero al sistema
GIS le viene bien ya que le sirve para identificar qué municipio está implicado).
Para saber más datos del municipio se da la posibilidad de mostrar en el xml
otra información relativa al municipio que no sea su identificativo. Esta
información se muestra a nivel de capa, y dentro de cada capa, a nivel de dato
(municipio), y dentro de cada dato, a nivel de columna de información. Queda
por comprobar (por temas de rendimiento) de si esta última información va a
ser dada ordenada alfanuméricamente, o según se va procesando.
4.3.3. Tratamiento GIS Para que el Sistema GIS identifique los cruces lee la información del módulo de
parametrización.
4.3.4. Exposición en interfaz Se podrá realizar esta consulta tanto desde el EJB como desde las librerías jar.
Sin embargo, desde las librerías jar, sólo se tendrá acceso a los datos de los
cruces batch.
4.4. Obtención de los datos de los objetos del Cruce Localización de la aplicación
Se encarga de devolver los datos “GIS” del objeto pasado como parámetro
(coordenadas, área, perímetro…). Se devuelven los datos que por el tipo de
geometría estén establecidos en el módulo de parametrización. Es decir, por cada tipo
de geometría, se devuelve una información diferente (ya que, por ejemplo, un punto
no va a tener nunca un área ni un perímetro, pero un polígono sí).
4.4.1. Llamada execGeometria ((string)codXLNET, (integer)idCapa, (string)idObjeto)
Donde:
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 25 de 49
Biodiversidad V:1.0 28/03/2008
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
idCapa es para determinar cual es la capa de la cual se desea obtener la
geometría.
idObjeto es el identificativo del objeto sobre el que se quiere obtener esa
información geométrica. En caso de pasarse null, se devolverán las
geometrías de toda la capa. OPCIONAL
4.4.2. Respuesta execGeometria.xml.
Devuelve un xml con la información “geográfica” del objeto. El formato es
similar al de la devolución de datos de capa en cruces agrupados.
execGeometriaPuntos.xml.
En este caso la información se obtiene por puntos, no por objeto. El formato es
similar al de la devolución de datos de capa en cruces no agrupados.
4.4.3. Tratamiento GIS Para que el Sistema GIS identifique qué datos devolver, comprueba en el
módulo de parametrización el tipo de geometría de la capa a la cual pertenece
el objeto a obtener su información. Si el tipo de geometría es 0, no se realizará
ningún cálculo.
4.4.4. Exposición en interfaz Se podrá realizar esta consulta tanto desde el EJB como desde las librerías jar.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 26 de 49
Biodiversidad V:1.0 28/03/2008
4.5. Devolver Lista de Búsquedas de la aplicación
Se encarga de devolver un listado de las búsquedas para una determinada capa de la
aplicación que los llama (en este caso Biodiversidad).
4.5.1. Llamada getListaBusquedas ((string)codXLNET, lista[(integer)idCapa],).
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
Lista[idCapa] es una lista con los identificativos de las capas delas
búsquedas que se obtendrán como retorno. OBLIGATORIO
4.5.2. Respuesta Devuelve una lista de Hashmap, cada uno con los siguientes datos de
búsquedas:
• idBusqueda (integer)
• idCapa (integer)
• ListaColumnas (ArrayList) -> será una lista de Hashmap, cada
uno con la siguiente información:
Nombre (string)
Descripción (string)
4.5.3. Tratamiento GIS Para que el Sistema GIS identifique las búsquedas lee la información del
módulo de parametrización.
4.5.4. Exposición en interfaz Se podrá realizar esta consulta tanto desde el EJB como desde las librerías jar.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 27 de 49
Biodiversidad V:1.0 28/03/2008
4.6. Ejecución de una Búsqueda Cartográfica de la aplicación
Se encarga de realizar una determinada búsqueda perteneciente a la aplicación que
lo llama (en este caso Biodiversidad).
Esta llamada es tanto para ejecutar búsquedas pasando la extensión (es la selección
que se realiza en el minivisor) como búsquedas pasando unas coordenadas. Difieren
sólo en la introducción del elemento localizador (extensión, coordenadas).
El minivisor estará en el mismo sistema de coordenadas que las capas, por lo que no
hace falta pasarlo como argumento.
4.6.1. Llamada pasando extensión execBusquedaC ((string)codXLNET, Lista[(integer)idBusqueda],
(double)minX, (double)minY, (double)maxX, (double)maxY)
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
Lista[idBusqueda] es una lista de identificativos de búsqueda de los
cuales se quiere obtener el resultado. OBLIGATORIO.
minX, minY, maxX, maxY son las coordenadas que componen la
extensión que sirven para delimitar la búsqueda en esa zona.
OBLIGATORIO
4.6.2. Llamada pasando coordenadas execBusquedaC ((string)codXLNET, Lista[(integer)idBusqueda],
(double)coordX, (double)coordY)
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 28 de 49
Biodiversidad V:1.0 28/03/2008
Lista[idBusqueda] es una lista de identificativos de búsqueda de los
cuales se quiere obtener el resultado. OBLIGATORIO
coordX, coordY son las coordenadas que componen el punto que sirve
para delimitar la búsqueda. OBLIGATORIO
4.6.3. Respuesta execBusquedaC1.xml
execBusquedaC2.xml
El formato del XML será similar al de las devoluciones de datos de capa en los
cruces. Depende de si la capa es propia de la aplicación o externa.
4.6.4. Tratamiento GIS Para que el Sistema GIS identifique las búsquedas lee la información del
módulo de parametrización.
4.6.5. Exposición en interfaz Se podrá realizar esta consulta sólo desde el EJB.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 29 de 49
Biodiversidad V:1.0 28/03/2008
4.7. Ejecución de una Búsqueda Personalizada de la aplicación
Se encarga de realizar una determinada búsqueda perteneciente a la aplicación que
lo llama (en este caso Biodiversidad). Esta llamada es para ejecutar búsquedas
pasando la ruta de un shape externo que se ha subido al servidor.
4.7.1. Llamada execBusquedaP ((string)codXLNET, Lista[(integer)idBusqueda],
(string)rutaShape, (integer)buffer)
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
Lista[idBusqueda] es una lista de identificativos de búsqueda de los
cuales se quiere obtener el resultado. OBLIGATORIO
rutaShape es la ruta donde se encuentra ubicado el shape (previamente
subido al servidor) para poder trabajar con él. OBLIGATORIO
buffer es la distancia que se desea usar para encontrar los objetos y
datos de las capas de búsqueda a partir de la capa pasada como
argumento
4.7.2. Respuesta execBusquedaC1.xml.
execBusquedaC2.xml.
El formato del XML será similar al de las devoluciones de datos de capa en los
cruces. Depende de si la capa es propia de la aplicación o externa.
4.7.3. Tratamiento GIS Para que el Sistema GIS identifique las búsquedas lee la información del
módulo de parametrización.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 30 de 49
Biodiversidad V:1.0 28/03/2008
4.7.4. Exposición en interfaz Se podrá realizar esta consulta sólo desde el EJB.
4.8. Ejecución de zonificación para una capa de la aplicación
Se encarga de devolver un listado con los datos de zonificación que contiene un
objeto de una capa de la aplicación.
4.8.1. Llamada execZonificacion ((string)codXLNET, (integer)idCapa, (string)idObjeto).
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona xlNET. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
idCapa es para determinar cual es la capa de la cual el Sistema GIS
debe referirse para obtener el resultado. Ya que será siempre en
relación a un objeto de esta capa. OBLIGATORIO
idObjeto es un identificativo del objeto (perteneciente a la capa) del cual
se quieren obtener los resultados de la zonificación. OPCIONAL
4.8.2. Respuesta execZonificacion.xml
Devuelve un xml con los datos de la zonificación de un determinado objeto de
la capa perteneciente a la aplicación.
4.8.3. Tratamiento GIS Para que el Sistema GIS identifique las zonificaciones lee la información del
módulo de parametrización, ya que las zonificaciones son capas que tienen el
campo columna_agrupacion con un identificativo, que es el identificativo de la
zonificación.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 31 de 49
Biodiversidad V:1.0 28/03/2008
4.8.4. Exposición en interfaz Se podrá realizar esta consulta sólo desde el EJB.
4.9. Conversión de Coordenadas
Se encarga de devolver un listado con las coordenadas pasadas como entrada en los
6 sistemas de referencia que se contemplan.
4.9.1. Llamada execConverCoord ((double)coordX, (double)coordY, (integer)idSistRef).
Donde:
coordX, coordY son las coordenadas que se pasan para convertir a los 6
sistemas de referencia (Geográficas ED50, Geográficas ETRS89,
UTM30 ED50, UTM30 ETRS89, .Decimales ED50, Decimales ETRS89).
idSistRef es el sistema de referencia al cual pertenecen las coordenadas
pasadas como parámetro de entrada.
4.9.2. Respuesta execConverCoord.xml
Devuelve un xml con los datos de la conversión.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 32 de 49
Biodiversidad V:1.0 28/03/2008
4.10. Visualización en el visor
Se realizará mediante la llamada a una URL desde el cliente. En SCTA ya están
implementadas algunas funcionalidades sobre el visor a través de URL. Simplemente
se sobrecargará la llamada existente para proporcionar la siguiente funcionalidad:
Que se puedan visualizar capas dadas de alta en el módulo de
parametrización del GIS al margen los servicios de mapas en que se
encuentren.
Que se puedan visualizar capas correspondientes a cruces al margen de
los servicios de mapas en que se encuentren.
Opcionalmente se podrá hacer zoom a algún objeto de alguna de esas
capas.
Para más detalle, ver el documento: DOC_SCTA_acceso_visor_URL_20.doc
4.11. Devolver extensión de objeto/capa
Se encarga de devolver la extensión de una capa u objeto concreto. Lleva el formato
necesario para realizar una petición URL de acceso al visor.
4.11.1. Llamada getExtensionObjetos ((string)codXLNET, Lista[(integer)idBusqueda],
Lista[(integer)idObjeto])
Donde:
codXLNET es el código de la aplicación que llama al GIS, que
proporciona Xlnet. Es necesario para que el Sistema GIS sólo devuelva
los datos a los cuales esa aplicación tiene acceso. OBLIGATORIO
Las lista de capas es para determinar cual es la lista de capas sobre la
cuál se desea obtener la extensión de la lista de objetos. OBLIGATORIO
La lista de objetos debe corresponderse en orden con la lista de capas, y
es la lista de identificativos de objetos de los cuales se quiere obtener la
extensión. OBLIGATORIO
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 33 de 49
Biodiversidad V:1.0 28/03/2008
Nota: si en algún caso se desea obtener la extensión de una capa Y
basta con pasar como NULL el objeto correspondiente en la posición Y
de la lista.
4.11.2. Respuesta Devuelve un string que se podrá añadir directamente a la llamada al visor por
URL:
&COORDS=539982.0625290053|4764260.499993012|540136.9375099508|47
64550.999997376&TSRV=23030
En el caso de que se pasen varios objetos se devolverá la extensión que
comprenda a todos.
Para más información, se puede ver el documento de visualización del visor:
DOC_SCTA_acceso_visor_URL_20.doc
4.11.3. Exposición en interfaz Se podrá realizar esta consulta sólo desde el EJB.
4.12. Notas Aclaratorias
4.12.1. Vistas a usar y su tratamiento Van a existir dos tipos de vistas:
Unas para determinar cualquier subsistema que esté basado en cuadrículas,
para no cargar al sistema de un montón de capas, y usar solamente las
cuadrículas de las cuales se basan esos subsistemas (que son únicas para
todos). Es por ejemplo, para el caso de las especies con información a nivel de
cuadrícula, tener un montón de capas físicas, puede representar un gran
problema de rendimiento para el GIS el tener que cargarlas y/ó usarlas para
geoprocesamientos. Por ello se ha pensado (aún está por determinar si esta
posibilidad facilita el rendimiento) en juntar en dos únicas vistas (una vista que
contenga todas las especies de 10x10 y otra que contenga todas las especies
de 1x1), y que a la hora de usarlas, se haga un filtro por el objeto u objetos en
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 34 de 49
Biodiversidad V:1.0 28/03/2008
cuestión a devolver. Estas vistas serán la unión de las dos capas físicas de
cuadrículas (10x10 y 1x1) con una base de datos de Biodiversidad (para la cual
BIO tiene que dar acceso al GIS) por el campo cuadrícula (teniendo en cuenta
que hay que distinguir a cual de las dos cuadrículas pertenece ese valor). De
esta unión se obtendría el objeto por el cual se filtrará la información. Estas
vistas espaciales se van a tratar igual que si de capas normales se trataran, por
lo tanto, cuando el sistema BIO tenga que pasar al Sistema GIS, el
identificativo de capa o el identificativo para capa activa, debe tratarla como
una capa más, ya que así estará dada de alta en el módulo de parametrización
en el apartado de capas.
Van a existir otras vistas que nacen como solución a ciertas capas, como
EUNIS y VEGETACION, donde el código va a ser a través de dos campos (es
decir, ambos códigos pueden ser únicos y referirse al mismo registro). El
desglose de la capa original queda reflejado en la vista también con la
coloración de los registros formados y modificados.
Este registro:
Se desglosaría en estos dos:
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 35 de 49
Biodiversidad V:1.0 28/03/2008
4.12.2. Problema en el agrupamiento por identificador único Puede darse el caso (y se ha visto) que al intentar registros (objetos) por un
identificador único (para devolver al Sistema BIO el objeto bio) la información por un
determinado campo no coincida.
Tal como muestra el ejemplo:
Se tiene que el identificador único es el campo EU, pero hay un campo el E110_4_A
que tiene un valor diferente por cada registro (aún siendo el valor del identificador el
mismo). Por lo tanto, esto hay que tenerlo en cuenta, porque al intentar agrupar y
querer saber la información del campo E110_4_A, Oracle devolverá un error de que
no se puede agrupar.
4.12.3. Propuesta de parametrización para tipos de capas, cruces, cálculos y geometrías
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 36 de 49
Biodiversidad V:1.0 28/03/2008
Tipos de Capas
Se propone la siguiente parametrización para los tipos de capas de la aplicación BIO:
Id_Tipo Descripcion Interna
0 Interna TRUE
1 Datos FALSE
2 Municipios FALSE
3 Áreas Funcionales FALSE
4 Unidades
Hidrológicas
FALSE
5 Medio Marino FALSE
6 Territorios Historicos FALSE
Esta parametrización sólo aporta valor a la aplicación cliente (en este caso
Biodiversidad) para el reconocimiento de capas. No cambia en nada la funcionalidad
del GIS.
Tipos de Cruces
Se propone la siguiente parametrización para los tipos de cruces de la aplicación BIO:
Id_Tipo Descripcion
0 Objetos
1 Datos
2 Municipios
3 Areas Funcionales
4 Medio Marino
5 Unidades Hidrológicas
6 Multicruce
Esta parametrización sólo aporta valor a la aplicación cliente (en este caso
Biodiversidad) para el reconocimiento de capas. No cambia en nada la funcionalidad
del GIS.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 37 de 49
Biodiversidad V:1.0 28/03/2008
Tipos de Geometrias
Se propone la siguiente parametrización para los tipos de geometrias de la aplicación
BIO:
Id_Tipo Descripcion Comentarios
0 Sin geometría Evidentemente, la capa tiene geometría, pero no
se efectuará ningún cálculo sobre ella.
1 Puntos
2 Líneas
3 Polígonos
Tipos de Cálculos
Se propone la siguiente parametrización para los tipos de geometrías de la aplicación
BIO:
Id_Tipo Descripcion Geometría aplicable Comentarios
0 Área total 3 Suma las áreas de los
polígonos de cada objeto.
(Cálculo agrupado por objeto).
1 Perímetro 3 Suma los perímetros de los
polígonos de cada objeto.
(Cálculo agrupado por objeto).
2 Coordenada X del
Centroide del
polígono más grande
3 (Cálculo agrupado por objeto).
3 Coordenada Y del
Centroide del
polígono más grande
3 (Cálculo agrupado por objeto).
4 X 1 Obtiene la coordenada X del
cada punto de cada objeto.
(Cálculo sin agrupar por objeto).
5 Y 1 Obtiene la coordenada X del
cada punto de cada objeto.
(Cálculo sin agrupar por objeto).
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 38 de 49
Biodiversidad V:1.0 28/03/2008
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 39 de 49
Biodiversidad V:1.0 28/03/2008
5. Volumen de datos y tiempos Dado el potencial riesgo que supone el gran volumen de datos a gestionar en la
integración del sistema de Biodiversidad con el GISK se han realizado algunas
pruebas para validar el diseño propuesto.
5.1. Marco de pruebas
En este apartado se describen los casos analizados y el modo en el que se han
realizado las pruebas.
Las alternativas planteadas desde el principio para el procesamiento de las
búsquedas y los cruces fueron tres:
(1) Publicar un servicio de geoprocesamiento como los de ArcMap y consumirlo
desde ArcGis Server
(2) Utilizar directamente los ArcObjects de geoprocesamiento para realizar las
búsquedas, los buffers y los cruces
(3) Utilizar el BasicGeoprocessor de la librería Carto
(4) Implementar los cruces y las búsquedas feature a feature sin utilizar
ninguna herramienta de geoprocesamiento.
Por limitaciones del entorno se descartaron casi desde el principio las alternativas (1)
y (2), ya que requerían migrar SCTA a la versión 9.2 de ArcGIS Server y de ArcSDE.
La mayor parte de las pruebas se generaron a partir de la opción (3), que parecía la
más rápida a priori. Posteriormente se volvieron a lanzar algunas de estas pruebas
utilizando la opción (4).
El juego de datos de pruebas utilizado ha sido:
TIPO CRUCE CAPA A CRUZAR CAPA DE CRUCE
CT_LICS_100000 CT_ZEPAS_100000
CT_LICS_100000 CT_PARNATURAL_25000
CTLugares vs
Lugares
_ARBOLSINGULAR_25000 CT_LICS_100000
CT_ZEPAS_100000 CT_PARNATURAL_25000
Lugares vs CT_LICS_100000 CT_FLORA_AMENZADA_1KM
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 40 de 49
Biodiversidad V:1.0 28/03/2008
CT_LICS_100000 CT_DISTRIB_PREFERENTE
CT_LICS_100000 CT_AREAS_DIST_ESPECIAL
CT_LICS_100000 CT_PTS_SNSBLES_DSTRSIONADOS
Especies
CT_ZEPAS_100000 CT_FLORA_AMENZADA_1KM
CTLugares vs
Habitats
_LICS_100000 CT_VEGETACION_POTENCIAL_10000
CT_LICS_100000 CT_HAB_INT_COMUNITARIO_25000
CTHabitats vs
Habitats
_HAB_INT_COMUNITARIO_25000 CT_VEGETACION_POTENCIAL_10000
CT_HAB_INT_COMUNITARIO_25000 CT_VEGETACION_25000
CEspecies vs
Habitats
T_FLORA_AMENZADA_1KM CT_HAB_INT_COMUNITARIO_25000
CT_DISTRIB_PREFERENTE CT_HAB_INT_COMUNITARIO_25000
CEspecies vs
Especies
T_DISTRIB_PREFERENTE CT_FLORA_AMENZADA_1KM
CT_DISTRIB_PREFERENTE CT_PTS_SNSBLES_DSTRSIONADOS
CT_LICS_100000 CB_MUNICIPIOS_5000
CT_ZEPAS_100000 CB_MUNICIPIOS_5000
CT_ARBOLSINGULAR_25000 CB_MUNICIPIOS_5000
CT_PARNATURAL_25000 CB_MUNICIPIOS_5000
CT_HAB_INT_COMUNITARIO_25000 CB_MUNICIPIOS_5000
CT_VEGETACION_POTENCIAL_10000 CB_MUNICIPIOS_5000
CT_FLBIO vs
Municipios
ORA_AMENZADA_1KM CB_MUNICIPIOS_5000
CT_DISTRIB_PREFERENTE CB_MUNICIPIOS_5000
CT_LICS_100000 CT_LITOLOGICO_25000
CT_ZEPAS_100000 CT_LITOLOGICO_25000
CT_ARBOLSINGULAR_25000 CT_LITOLOGICO_25000
CT_PARNATURAL_25000 CT_LITOLOGICO_25000
CT_HAB_INT_COMUNITARIO_25000 CT_LITOLOGICO_25000
CT_VEGETACION_POTENCIAL_10000 CT_LITOLOGICO_25000
CBIO vs NO
BIO
T_FLORA_AMENZADA_1KM CT_LITOLOGICO_25000
CT_DISTRIB_PREFERENTE CT_LITOLOGICO_25000
5.2. Resultados de las pruebas
Los tiempos se han medido en el siguiente entorno hardware:
• Servidor de aplicaciones: portátil DELL 1GHz, 2GB RAM
• ArcGIS Server: PC DELL 3GHz, 2GB RAM
• Oracle + ArcSDE: DELL Optiplex GX620, Xeon 2,66GHz (servidor compartido)
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 41 de 49
Biodiversidad V:1.0 28/03/2008
A continuación se reflejan y comentan los tiempos obtenidos en las diferentes
pruebas.
5.2.1. Resultados de las pruebas con el BasicGeoprocessor Utilizando el BasicGeoprocessor se obtienen los siguientes resultados (por defecto
tiempos en segundos, a menos que se indique otra unidad):
Los resultados de las pruebas se resumen a continuación:
• En el entorno de pruebas, se lanza un nuevo hilo de ejecución de reintento
cuando a los 5 minutos no se ha obtenido respuesta del servidor. El hilo
viejo queda en background otros 5 minutos y si no se obtiene respuesta se
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 42 de 49
Biodiversidad V:1.0 28/03/2008
destruye. Esto ha impedido poder realizar cruces cuyo tiempo de duración
sea superior a 10 minutos.
• En la primera hoja están los resultados de los 33 cruces. Se indican el
tiempo empleado, el volumen del shape generado y los registros obtenidos.
• En los casos en los que no he podido generar el shape por tardar el proceso
más de 10 minutos, he realizado el proceso en ArcCatalog como
aproximación.
• Los árboles singulares no se han conseguido cruzar por ser una capa de
puntos. Con ArcCatalog ha sido casi inmediato.
• En algunos casos he probado a hacer el mismo cruce con ArcGIS Server y
con ArcCatalog, dando lugar a resultados diferentes. El ejemplo más claro
es el del cruce 23, que con ArcCatalog genera 1469 registros y con ArcGIS
Server genera 8192 tardando casi 10 veces más y ocupando un mayor
volumen de información. He puesto los dos shapes dentro del mismo mapa
no notándose diferencias a simple vista, sin embargo, mirando los datos, se
pueden observar un par de diferencias importantes
(1) En ArcGIS Server aparecen los resultados duplicados. La segunda
copia parece claramente un bug del ArcObject, ya que los datos
alfanuméricos no tienen sentido.
(2) Si en un municipio hay 2 zonas de hayedos, en ArcCatalog se
genera un único polígono multiparte, mientras que con ArcGIS server
se generan dos polígonos.
• Se ha hecho un dissolve previo en la capa de parques naturales para ver si
se mejoraba el rendimiento. En algunos casos se ha mejorado en un 50%,
en otras se ha duplicado el número de registros del shape de salida sin
razón aparente (parece un bug claramente ya que los registros son iguales
pero con algunos campos cambiados de sitio).
Por otro lado, el BasicGeoprocessor proviene de las versiones 8.x de ArcGIS, y en la
versión 9.1. de ArcGIS Server aún no ha sido sustituido por el nuevo framework de
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 43 de 49
Biodiversidad V:1.0 28/03/2008
geoprocesamiento (sí ha sido sustituido en ArcMap). Sí ha sido sustituido en todas las
versiones posteriores, por lo que podríamos considerarlo “obsoleto”.
5.2.2. Resultados en las pruebas de cruces “feature a feature”
Prueba 1
El primer ejemplo de prueba ha sido el cruce 21 Parques Naturales vs Municipios.
El algoritmo de cruce es el siguiente:
(1) Se recorren los features de una capa
(2) Se establece cada uno de ellos como filtro espacial de la siguiente capa.
(3) Para cada uno que se corta (para saber si se corta o no, no tarda
demasiado), se calcula la intersección (aquí sí tarda, pero tardaría de todas,
todas).
(4) Posteriormente se calcula el área de la intersección cuando esta es no
vacía.
Se han encontrado puntos a favor y en contra de esta opción respecto al
BasicGeoprocessor.
En contra:
• El tiempo total ha sido de 41 segundos, contra los 19,3 del
BasicGeoprocessor.
A favor:
• No hace falta crear featureclass; ya no se dejan ficheros inútiles en el
servidor
• Sólo salen 262 intersecciones, contra las 2444 que daba el
BasicGeoprocessor.
• No salen registros repetidos
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 44 de 49
Biodiversidad V:1.0 28/03/2008
• El tiempo medio de intersección de un elemento contra toda una capa es de
menos de un segundo (41 segundos/ 66 parques naturales = 0.62sg/objeto),
lo que hace posible los cruces on-line elemento contra capa.
• Aunque el tiempo de geoprocesamiento es menor en el caso del
BasicGeoprocessor, luego habría que añadir otro tiempo de post-
procesamiento indefinido (eliminación de registros repetidos, sumas de
áreas repartidas entre dos elementos al fallar el multipart, etc.)
• El post-geoprocesamiento incrementaría notablemente el tiempo de
desarrollo y pruebas.
Prueba 2
Se repitió la prueba anterior modificando el algoritmo de cruce sustituyendo el punto
(2) por:
(2’) Se establece el envelope de cada uno de ellos como filtro espacial de la
siguiente capa
Eso devuelve objetos que en realidad no se tocan, pero a veces es más rápido tener
una lista de los objetos que "podrían tocar" y calcular la operación espacial
(intersección en este caso) que esperar a tener la lista "exacta" de los que se tocan.
ArcSDE calcula los que están dentro de un envelope muy rápido (sólo tiene que hacer
comparaciones con mayor y menor que) pero tarda en aplicar un filtro espacial con
una feature porque ahí debe calcular raíces cuadradas y operaciones aritméticas que
le permitan saber si un punto está contenido en tu polígono o no.
Se repitió el mismo cruce 21 con los siguientes resultados:
• No se llegaron a calcular todas las intersecciones por el límite de los 10
minutos.
• Para poder tomar referencias se calculó el tiempo de intersección del
parque número 5 con la capa entera de LICS. El resultado fueron 17
segundos por 6 segundos del método implementado en la prueba 1.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 45 de 49
Biodiversidad V:1.0 28/03/2008
• Los parques son polígonos multiparte. Eso puede hacer que en algunos
casos su envelope sea, realmente, un área bastante mayor que la del
propio polígono.
Prueba 3
Se repitió el algoritmo de la prueba 1 para un cruce mucho más costoso, como el de la
capa de parques naturales contra la de litológico (que tiene más de 24000 registros).
Comparando los resultados de este algoritmo con los de la herramienta de
ArcCatalog, se observa que esta última añade al final unos features que completan
pequeños huecos dejados al calcular la intersección (rectángulos de 16 cm * 0.2mm).
El caso es que la suma de las áreas de las intersecciones calculadas desde el
sistema no coincide exactamente con la del feature intersecado, aunque se llevan
muy poco (en proporción es la diferencia es <1/1000).
5.2.3. Extrapolación al volumen real de datos A partir de las pruebas comentadas en los dos apartados anteriores y teniendo en
cuenta la cantidad de registros de las capas y la cantidad de cruces que hay que
hacer, se puede concluir lo siguiente:
#1.- Catálogo de capas
Según el catálogo de capas considerado en el análisis se dispone de:
* 62 capas
- 31 capas bio
+ 22 de lugares
+ 5 de hábitats
+ 4 de especies
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 46 de 49
Biodiversidad V:1.0 28/03/2008
- 31 son no-bio
+ 1 capa municipios
+ 30 capas no municipios
#2.- Pruebas de concepto y de rendimiento
En las pruebas con el BasicGeoprocessor se hicieron 31 cruces. De ellos:
• Se obtuvieron resultados "buenos" en 20 de esos cruces.
• El número medio de registros en las capas que han intervenido en los
cruces es de 2198,35.
• El tiempo medio por cruce fue de 98,47 segundos.
• La dispersión de la muestra en cuanto al número de registros se refiere fue
bastante alta (desde 11 hasta 26000 registros).
• También fue alta la dispersión de tiempos (desde 0,9 segundos hasta casi
10 minutos).
• Las tablas de resultados no fueron demasiado buenas. Por ejemplo, había
registros repetidos, no se respetaba el multipart.
• Hubo algunos cruces de los que no se pudo conocer el tiempo por
limitaciones del entorno de pruebas a procesamientos menores de 10
minutos.
• Teniendo en cuenta que el tiempo depende del tamaño de cada capa,
podemos suponer que:
t=k*(n reg capa 1)*(n reg capa 2) =k* n^2.
Aproximando k=t/n^2 = 97/(2198,35^2) =2,0 e-5
Posteriormente se implementó la funcionalidad de cruces elemento a elemento
mediante ArcObjects. Se hicieron tres pruebas con este método:
• Los resultados fueron altamente satisfactorios en cuanto a la calidad de los
datos.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 47 de 49
Biodiversidad V:1.0 28/03/2008
• Se pudieron cruzar capas que en el caso anterior no se pudieron cruzar.
• El tiempo empleado fue de la mitad en una ocasión y del doble en otra.
Parece que bastante influenciado por las formas de los polígonos.
Teniendo en cuenta lo anterior, en la aplicación de biodiversidad se implementará la funcionalidad de cruces elemento a elemento mediante ArcObjects. Para estimar
los tiempos de los cruces pre-programados, podemos considerar que los tiempos
serán similares en orden de magnitud a los obtenidos mediante el
BasicGeoprocessor.
#3.- Extrapolación a los datos reales
En principio tendríamos 31*34 cruces "batch" (31 bio contra los otros 30 bio + la capa
de municipios + la capa de unidades hidrológicas + la capa de componente marino +
la capa de áreas funcionales): 1054 cruces.
La media de registros de las capas de las que disponemos los datos es de 6333,75.
Aplicando el modelo que hemos descrito en el punto 1, tendremos que el tiempo
medio por cruce será t = k* n^2 = 2,00e-5 * 6333,75^2 = 805 segundos/cruce.
Multiplicando por el numero total de cruces estimados => 805 * 1054 = 848643
segundos = 235 horas.
#4.- Prueba de cruces en el entorno de desarrollo de EJIE.
Se ha realizado el cruce de la capa de parques sin dissolve previo en EJIE y en el
entorno de Lasarte.
En el entorno de Lasarte ha tardado 1 minuto y 37 segundos.
En el entorno de desarrollo de EJIE ha tardado 3 minutos y 30 segundos.
El tiempo en EJIE ha resultado un 116% superior al de Lasarte, por lo que la
extrapolación a datos reales en el entorno de EJIE siguiendo una regla de 3 se
dispararía hasta las 509 horas.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 48 de 49
Biodiversidad V:1.0 28/03/2008
Conclusión
En un entorno de desarrollo de Sitesa el cálculo de todos los cruces supondría unas
235 horas, que en el entorno de desarrollo de EJIE se convertirían en 509 horas.
Hay bastantes factores que podrían alterar el resultado de esta extrapolación:
Incrementaría el tiempo lo siguiente:
• No se están considerando los multicruces.
• No se han considerado los paisajes ni los corredores como "cruzables". Si lo
fueran, esto incrementaría el tiempo de procesamiento.
• 30 capas equivale a 900 cruces, pero 40 equivaldría a 1600. Un pequeño
aumento en el número de capas implica un gran aumento en el número de
cruces.
Disminuiría el tiempo lo siguiente
• Quizá el tiempo de cada cruce dependa de una potencia menor de n. No
tenemos datos suficientes a favor ni en contra.
• Quizá la media de datos de las capas que faltan por introducir en el GIS sea
menor que la de las capas que ya están introducidas
• Quizá solo tenga sentido cruzar las capas de delimitación, y no las de
zonificación.
• Haciendo dissolves previos en los datos y dejando en las capas únicamente
aquellos campos cuyo valor se va a necesitar desde Biodiversidad,
probablemente el rendimiento mejoraría mucho.
En cualquier caso, las conclusiones a las que hemos llegado no parecen definitivas en
tanto que no se corresponden con el entorno de producción.
De estos resultados se deduce que se deberá posibilitar la ejecución de cruces de
forma parcial, sin necesidad de lanzar siempre todos los cruces configurados.
Diseño técnico Integración con GIS-K Documento: DT_BIODIVERSIDAD_GIS_10.doc Página 49 de 49