Diseño técnico Integración con GIS-K · Biodiversidad V:1.0 28/03/2008 A continuación se...

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




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



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.



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



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



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



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



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



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



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



3.4.1. Paquete s57b.biodiversidadcomunbiz.biz El paquete s57b.biodiversidadcomunbiz.biz contiene clases de lógica de negocio para

las entidades del modelo.



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.



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



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.



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.



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.



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:


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:



• 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.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:




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



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.



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



ú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



(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).



ú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



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.


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:






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.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:




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.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:




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:







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.5. Exposición en interfaz Se podrá realizar esta consulta sólo desde el EJB.



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:





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.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:




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.




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.



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:


proporciona Xlnet. Es necesario para que el Sistema GIS sólo devuelva


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



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.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



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:



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



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.



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).



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



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)



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



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



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



• 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.



• 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



- 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.



• 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.



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 · Biodiversidad V:1.0 28/03/2008 A continuación se...

Documents

Transcript of Diseño técnico Integración con GIS-K · Biodiversidad V:1.0 28/03/2008 A continuación se...