Sistema d’Informació Geogràfica d’urbanisme integrat en ... · diferents sistemes similars...

Projecte final de Màster en Tecnologies de la informació Geogràfica, 10 Edició

Sistema d’Informació Geogràfica d’urbanisme integrat en una plataforma corporativa del SIG municipal.

Organitza: Col·labora: Autor: Albert Bigorra

Tutors: Andrés Torregrosa (Seys)

Laura Sala (Ligit)

Sistema d’Informació Geogràfica (SIG) d’urbanisme integrat en una plataforma corporativa del SIG municipal

2

ABSTRACT

El document recull la memòria del projecte final del projecte de la desena edició del Màster en

Tecnologies de la Informació Geogràfica impartit en Laboratori d’Informació Geogràfica i

Teledetecció (LIGIT) del departament de geografia de la UAB i realitzat amb col·laboració de

l’empresa SEYS.

El projecte es contextualitza en el desenvolupament del Sistema d’Informació Geogràfica (SIG)

d’urbanisme integrat en una plataforma corporativa del SIG municipal per a l’Ajuntament de

Tarragona com a resposta a la revisió del planejament urbanístic (POUM)

El projecte es desenvolupa en tres blocs: Urbanisme, Cartografia bàsica i interoperativitat. Les

tasques realitzades en aquestes pràctiques versen sobre dos d’aquest mòduls:

� Urbanisme, on s’estructura les dades del POUM per tal d’establir una base de dades.

Aquesta servirà de base pel desenvolupament de l’aplicatiu que facilitarà les tasques

del departament d’urbanisme

� Interoperativitat, on es desenvoluparà un servidor de la informació geoespacial , per

tal de poder-hi accedir des del diferents departaments de l’Ajuntament, i un geoportal

per visualitzar-les.

Este documento recoge la memoria del proyecto de la decima edición del Máster en

Tecnologies de la Informació Geogràfica impartido por el Laboratori d’Informació Geogràfica i

Teledetecció (LIGIT) del departamento de geografía de la UAB, realizado en colaboración con

la empresa SEYS

El proyecto se contextualiza en el desarrollo de un sistema de información geográfico (SIG) de

urbanismo integrado en una plataforma corporativa del SIG municipal del ayuntamiento de

Tarragona como respuesta a la revisión del planeamiento urbanístico (POUM)


3

El proyecto se desarrolla en tres bloques: urbanismo, cartografía base e interoperatividad. Las

tareas efectuadas en las prácticas se focalizan en dos de estos módulos:

� Urbanismo, en el que se estructuran los datos del PPOUM a fin de establecer una base

de datos. Esta servirá de base para el desarrollo del aplicativo que facilitara las tareas

del departamento de urbanismo

� Interoperabilidad, donde se desarrollara un servidor de información geoespacial, a fin

de poder acceder des de los distinto departamentos, y un geoportal para poder

visualizarla

This document is the final report of the tenth edition of Màster en Tecnologies de la

Informació Geogràfica make it in Laboratori d’Informació Geogràfica i Teledetecció (LIGIT) of

Geography Department in UAB, with SEYS collaboration.

The project is about the development of Geographic Information System (GIS) in urbanism

integrated into Tarragona¡s council GIS corporative platform, as a response of urban planning

(POUM) revision.

This project is developed in three blocks: urban planning, base cartography and

interoperability. My practice into this project works in two parts:

• Urban planning, where we organize POUM data in a database. This will be the

development core of software that makes easier the task of urbanism department.

• Interoperability, where we develop a platform to access to a geospatial throughout a

map server and a geo web site to show.


4

ÍNDEX 1. Introducció ........................................................................................................................... 8

1.1. Marc institucional .......................................................................................................... 9

2. Sistema d’Informació Geogràfica (SIG) d’urbanisme integrat en una plataforma

corporativa del SIG municipal ..................................................................................................... 10

2.1. Demanda ..................................................................................................................... 10

2.1.1. Funcionalitats i requeriments ............................................................................. 11

2.2. Oferta .......................................................................................................................... 15

2.2.1. Arquitectura ........................................................................................................ 18

2.2.2. Pla de treball ....................................................................................................... 22

3. El projecte ........................................................................................................................... 24

3.1. Generalitats ................................................................................................................. 24

3.2. Definició model de dades pel SIG d’Urbanisme .......................................................... 26

3.2.1. Aspectes teòrics .................................................................................................. 27

3.2.1.1. El fet urbanístic ................................................................................................ 27

3.2.1.2. L’estructuració en base de dades .................................................................... 29

3.2.2. Desenvolupament ............................................................................................... 33

3.2.3. Resultats .............................................................................................................. 36

3.3. Implementació de la conectivitat del SIG corporatiu .................................................. 38

3.3.1. Aspecte teòrics .................................................................................................... 38

3.3.2. Anàlisi de requeriments ...................................................................................... 45

3.3.3. Solució metodològica .......................................................................................... 46

3.3.4. Disseny funcional ................................................................................................ 58

3.3.5. Desenvolupament ............................................................................................... 59

3.3.6. Resultats .............................................................................................................. 63


5

4. Conclusió ............................................................................................................................ 66

4.1. Sobre les pràctiques .................................................................................................... 67

4.2. Sobre el projecte ......................................................................................................... 67

5. Bibliografia .......................................................................................................................... 68

6. Annexos .............................................................................................................................. 70

6.1. Model Base de Dades .................................................................................................. 70

6.2. Manual instalació sistema interoperativitat ............................................................... 71

6.3. Arxiu configuració WMS .............................................................................................. 81

6.3.1. Web.xml .............................................................................................................. 81

6.3.2. Wms_configuration.xml ...................................................................................... 82

6.3.3. Arxiu Feture type (Clasi.xsd) ................................................................................ 91

6.3.4. Arxiu SLD (Clasi.xml ) ........................................................................................... 93

6.4. Arxiu configuració WFS ............................................................................................... 94

6.4.1. Web.xml .............................................................................................................. 94

6.4.2. Wfs_configuration.xml ........................................................................................ 97

6.4.3. Arxiu Feture type (Classificacio.xsd) .................................................................. 103

6.5. Arxiu configuració Geoportal .................................................................................... 105

6.5.1. Wmc_urbanisme.xml ........................................................................................ 105


6

ÍNDEX TAULES

Taula 1 - Sistemes SIG existents .................................................................................................. 14

Taula 2 - Aplicatius utilitats en el sistema ................................................................................... 17

Taula 3 - Arquitectura sistema urbanisme .................................................................................. 18

Taula 4- Objectius i tasques de les pràctiques ............................................................................ 25

Taula 5 - Comparativa SGBDR ..................................................................................................... 33

Taula 6 - Consultes serveis web OGC .......................................................................................... 43

Taula 7 - Exemple consultes sobre serveis OGC .......................................................................... 44

Taula 8- Aplicatius de codi obert vs codi propietari .................................................................... 49

Taula 9- Estructura directoris deegree ........................................................................................ 52

Taula 10 - Formats deegree ........................................................................................................ 53

Taula 11- Elements arxiu configuració WMC .............................................................................. 56

ÍNDEX IMATGES Imatge 1 - Estructura funcionament Autodesk Topobase .......................................................... 16

Imatge 2 - Arquitectura del sistema ............................................................................................ 21

Imatge 3 - Fases del projecte ...................................................................................................... 22

Imatge 4 - Cronograma del projecte ........................................................................................... 23

Imatge 5 - Cronograma practiques ............................................................................................. 26

Imatge 6 - Definició Base de dades ............................................................................................. 30

Imatge 7 - Estructuració genèrica informació urbanística .......................................................... 34

Imatge 8 - Estructura de les dades (Qualificació del sòl) ............................................................ 35


7

Imatge 9 - Connexió de classificació i qualificació del sòl ........................................................... 36

Imatge 10- Arquitectura client-servidor...................................................................................... 40

Imatge 11 - Arquitectura serveis web OGC ................................................................................. 42

Imatge 12 - Arquitectura IDE ....................................................................................................... 45

Imatge 13 - Arquitectura serveis web deegree (Banda servidor) ............................................... 51

Imatge 14 - Deegree WMS. Dependencies entre fitxers ............................................................. 52

Imatge 15 - CSW: relació entre arxius ......................................................................................... 53

Imatge 16 - Entorn treball OpenJump ......................................................................................... 55

Imatge 17- Arquitectura configuració iGeoportal ....................................................................... 57

Imatge 18 - Carrega de dades al servei deegree-WMS ............................................................... 61

Imatge 19 - Carrega de dades al servei deegree-WFS ................................................................ 61

Imatge 20 - Entorn de consulta de serveis OGC .......................................................................... 63

Imatge 21 - Visulaització del geoportal ....................................................................................... 64


8

1. INTRODUCCIÓ

El document que segueix recull la memòria de les pràctiques realitzades en el marc de la

desena edició del Mestratge en Tecnologies de la Informació Geogràfica organitzat pel

departament de Geografia de la UAB. Les pràctiques s’han realitzat en l’últim trimestre del

2008 a l’empresa Seys, en el sí del projecte Sistema d’Informació Geogràfica (SIG)

d’urbanisme integrat en una plataforma corporativa del SIG municipal.

Aquest projecte té per objecte establir un SIG pel departament d’urbanisme de l’Ajuntament

de Tarragona per tal de facilitar les gestions, implementant una estructura que permeti fer-se

extensiva a altres departaments. En el desenvolupament d’aquest projecte he col·laborat en

dos punts: en l’estructuració i definició del model de dades per al desenvolupament del SIG

d’urbanisme i en l’anàlisi, disseny i implementació del sistema d’interoperativitat del SIG

corporatiu.

El treball s’organitza en quatre punts, el primer d’introducció, que es completa amb el marc

institucional. El segon punt és una contextualització del projecte en el que intervenen en les

meves pràctiques; en aquest es mostra la demanda feta per l’Ajuntament i la oferta

corresponent de l’empresa Seys. Enllaçant-ho amb les tasques que he dut a terme trobem el

centre del treball.

El tercer punt es subdivideix en tres. El primer és l’estructuració del projecte, marcant els

principals punts que configuren el projecte de pràctiques. Els altres dos punts mostren el

projecte a tráves dels dos entorns de treball, la Definició del model de dades pel SIG

d’Urbanisme i la Implementació de la connectivitat del SIG corporatiu. En ambdós casos es

comença amb una estructuració teòrica i es continua amb un aprofundiment definint els

objectius, els procediments i les metodologies que s’utilitzen.

El document es tanca amb una conclusió valorant les pràctiques, revisant els objectius

aconseguits en el projecte i estimant aquells serrells que resten per tancar i, per un altre

costat, uns annexos que mostren una sèrie de detalls de codi que poden servir per posar llum

a dubtes específics.


9

1.1. MARC INSTITUCIONAL

El Mestratge en Tecnologies de la Informació Geogràfica s’organitza en dos parts, una teòrica i

una pràctica. La part teòrica es realitza durant vuit mesos a les instal·lacions del LIGIT. Un cop

finalitzada la formació tenen lloc les pràctiques, que es realitzen al llarg de tres mesos en una

empresa o organització. En el cas concret d’aquest projecte final ha estat realitzat amb la

col·laboració de l’empresa SEYS, Semiconductores y Sistemas, S.A, fundada l’any 1989.

Seys és una Enginyeria de Tecnologies de la informació espacialitzada en el desenvolupament i

la Integració de sistemes i solucions amb component gràfica, amb forta espacialitat en entorns

cartogràfics i GIS. La gran evolució del sector en els darrers 20 anys ha permès el seu gran

creixement. L’actiu comercial més important de l’empresa és el partenrship que té amb

Autodesk Inc que es desenvolupa amb la venda de llicencies (copant el 9% del mercat de CAD

d’Espanya) encara que també ofereixen serveis de consultoria de sistemes d’informació, de

desenvolupament de projectes de sistemes d’informació, de tractament de dades, de

formació, de suport i de manteniment (de productes venuts via llicencia o via

desenvolupament). La gran expansió dels últims anys ve de l’orientació de desenvolupament

de projectes ad-hoc, amb alt valor afegit. Aquesta s’entén en base a l’experiència acumulada

de la comercialització d’aquests productes. És en aquest departament de desenvolupament

que s’han realitzat les pràctiques que es relaten en aquest document.


10

2. SISTEMA D’INFORMACIÓ GEOGRÀFICA (SIG) D’URBANISME INTEGRAT EN UNA

PLATAFORMA CORPORATIVA DEL SIG MUNICIPAL

El meu projecte de pràctiques està integrat en un gran projecte, convocat per l’Ajuntament de

Tarragona i portat a terme per l’empresa de pràctiques, Seys. En aquest apartat apuntarem el

context del projecte en el qual he col·laborat; mostrant primer la demanda de l’Ajuntament

amb les funcionalitats requerides, l’arquitectura modular demanada i els sistemes preexistents

que afecten al desenvolupament del sistema. El segon punt mostra l’oferta de Seys indicant el

programari escollit, l’arquitectura del sistema i una mostra de l’equip i calendari de treball.

El projecte, a grans trets, tracta de la implementació d’un sistema de gestió de la informació

urbanística en relació a una cartografia base unificada que permeti interoperar amb els

diferents sistemes similars existents en el si de l’Ajuntament. La meva funció respon a dos

aspectes, per una banda l’estructuració de les dades per al disseny i desenvolupament del

sistema de gestió urbanístic; per una altra banda el desenvolupament del sistema que permeti

connectar els diferents sistemes entre si.

2.1. DEMANDA

El projecte arrenca el dotze de març del 2008 a l’Ajuntament de Tarragona, a traves del seu

departament de contractació (Expedient 35/08). Es publica un concurs per l’adjudicació d’un

contracte de serveis pel disseny i desenvolupament d’un sistema d’informació geogràfica (SIG)

d’urbanisme integrat en una plataforma corporativa del SIG municipal. Aquest concurs s’obre

amb la publicació de dos plecs, un de clàusules jurídiques, econòmiques i administratives que

regeix l’adjudicació, l’avaluació i el seguiment del projecte. Al mateix temps es genera un plec

de les condicions tècniques que han de regir el desenvolupament del projecte.

En vista a la recent aprovació de la revisió del planejament general urbanístic del municipi de

l’Ajuntament de Tarragona es justifica aquest procés concursal. El plec descriu la importància

manifesta de la tasca de mantenir la informació actualitzada. Aquest objectiu, però, implica

disposar d’unes eines de manteniment i gestió adequades; les tecnologies de la informació

geogràfica facilitaran l’establiment d’un Sistema d’Informació Geogràfica (SIG) d’urbanisme

integrat en una plataforma corporativa del SIG municipal.


11

2.1.1. Funcionalitats i requeriments

El plec de condicions tècniques ens enumera les funcionalitats i requeriments que es pretenen

abastir per al sistema d’informació del departament de serveis urbanístics. El sistema ha de

comptar amb una sèrie de eines per a la gestió de la informació urbanística però, també, ha de

tenir l’estructura necessària per esdevenir un sistema corporatiu.

A nivell genèric les funcionalitats requerides al sistema d’urbanisme són:

� L’edició gràfica i alfanumèrica de bases de dades

� L’anàlisi espacial

� El seguiment i control de la publicació de la informació

� La consulta i certificació de dades, de forma interna i externa, per poder elaborar

informes i resoldre expedients

� Sistema actualització cartografia base, sobre la qual es genera tota la informació

� Sistema interoperabilitat, entre els diferents sistemes SIG ja existents en els altres

àmbits de l’Ajuntament i els que es desenvoluparan.

És en aquest punt que el plec tècnic detalla per a cada una de les parts del sistema les

funcionalitats especifiques. El desenvolupament del sistema s’ha de basar en tres blocs:

� El bloc de Gestió urbanística demana un sistema que permeti:

- La construcció, edició, validació topològica (neteja i creació de topologia),

manteniment i consulta espacial de la base de planejament urbanístic, tant

dels objectes gràfics com dels seus atributs alfanumèrics i altra informació

textual; amb una integració de la informació gràfica i alfanumèrica, relacionant

els objectes gràfics amb la informació dels seus atributs.

- La consulta de les característiques tècniques de cada parcel·la, la generació, i

impressió, de mapes temàtics i la publicació a Internet de les capes

urbanístiques, permetent la consulta per diferents atributs.

- El desenvolupament d’un aplicatiu per la determinació automàtica del valors

urbanístics i edificadors i un altre per automatitzar la redacció de projectes

d’expropiació i de reparcel·lació.


12

- El desenvolupament de funcionalitats referents a la tramitació i consulta de

llicències i expedients, informació de l’estat dels processos a tràmit de gestió

d’àmbits de planejament i informació sobre convenis, reserva de sòl, mobilitat

i patrimoni del municipi.

� La Cartografia base és el pilar del sistema demanat, així doncs la funcionalitats

especifiques demanades serà:

- Un programari de topografia i cartografia per mantenir la informació

cartogràfica actualitzada, aquest permetrà processar les dades topogràfiques

de camp i posteriorment el seu bolcat a la base de dades.

- El disseny d’eines d’edició, manteniment i consulta d’una base de dades

georeferenciada dels punts de Xarxa Topogràfica Municipal (XTM). L’aplicatiu

ha de permetre la consulta gràfica interactiva, alfanumèrica i sobre diferents

tipologies d’entitats (puntual, regular, irregular, illa, zona, ...).

- La integració operativa de la base de dades, de la XTM, en el SIG corporatiu.

� El plec tècnic demana que el sistema asseguri la Interoperativitat entre els diferents

mòduls. A nivell específic es demanada que els productes d’informació dels diferents

departaments siguin publicats en servidors de mapes, amb funcionalitats WMS i WFS,

per connectar-se en xarxa i fer accessible la informació. A més a més:

- El servei ha de permetre la publicació automàtica de les modificacions

urbanístiques (amb la menor intervenció possible dels serveis tècnics

responsables)

- La creació de metadades de dades i de serveis. Aquestes estaran enfocades a

la publicació interna (per consultes interdepartamentals) i externa (via Catàleg

IDEC). Aquestes metadades internes hauran de ser cercables i consultables a

través d’un Servidor Catàleg.

- El sistema de Interoperativitat ha de comptar amb un sistema de control

d’accessos que responguin als diferents perfils d’usuaris que es puguin

implementar.


13

L’arquitectura del sistema demanat es base a diferents mòduls funcionals que atenguin els

requeriments anteriors:

� Mòdul de configuració, ha de permetre la producció de cartografia urbanística i les

seves modificacions, assegurant la coherència topològica. Específicament ha de

permetre donar d’alta les capes a generar, configurar els productes de sortida, definir

usuaris i rols, establir les regles de validació topològica i la matriu de compatibilitats

d’usos (definir les incoherències entre cartografia i dades alfanumèriques).

� Càrrega de dades inicial: Tractament previ i càrrega de la informació existent en la

Base de Dades gràfica, i càrrega de la normativa vigent.

� Gestió de la informació urbanística, edició i manteniment: Conjunt de funcionalitats

que permeten el manteniment i l’explotació del sistema. Específicament la carrega,

edició de la informació gràfica i/o alfanumèrica, validació topològica. A part permetre

el tractament de la tramitació dels expedients dels Serveis d’Urbanisme Municipal, la

interacció amb dades d’altres departaments i la generació automàtica de diferents

productes de sortida.

� Visualitzador Web: interfície de comunicació amb els usuaris interns del sistema,

desenvolupat en JAVA, que permeti adaptacions posteriors i basat en les

especificacions OGC per a Clients WMS. Incorporarà com a bàsiques les capes

cadastral i urbanístiques bàsiques, amb opcions per a que cada usuari pugui afegir-ne.

A més a més s’ha de desenvolupar una versió espacial per a la web municipal. El

sistema ha de comptar amb funcionalitats d’impressió i consulta de documents (fitxes

informatives, cèdules urbanístiques, plànols) en una plataforma multinavegador i que

garanteixi l’accessibilitat WAI per a usuaris discapacitats.

� Mòdul de Publicació WMS: la informació estructurada en capes serà publicada en un

Servidor de Mapes, accessible a la resta de Departaments i als usuaris de la Web

Municipal (en les condicions que es determinin). El servidor de mapes complirà les

especificacions OGC en relació als serveis WMS, WFS i SLD.

Les modificacions posteriors sobre aquesta situació inicial s’han d’integrar (publicar) en

el servidor de mapes esmentat, de manera semiautomàtica en un entorn controlat (ha

d’existir un vincle amb el mòdul d’administració)


14

� Mòdul d’administració i control d’accessos: ha de permetre enregistrar usuaris del

sistema, assignar-los un nivell de permisos determinat i controlar el seu accés a la

informació (autenticació, autorització), així com elaborar estadístiques dels accessos

per tipus d’usuaris, informació demandada, etc. Caldrà diferenciar entre els usuaris

interns de gestió municipal i els usuaris Internet externs, que podran accedir a la

informació publica del planejament urbanístic.

En definitiva es tracta d’implementar un sistema de gestió de la informació urbanística sobre

una cartografia base unificada que convergeixi amb els diferents sistemes existents i garantint

la Interoperativitat entre tots ells, però mantenint l’especificitat de l’entorn de cada un.

El sistema, però, ha de convergir amb els diferents sistemes SIG preexistents en el marc del

govern municipal. Hi ha diferents àmbits de l’Ajuntament que ja en disposen, però, amb

diferents estadis d’evolució. Urbanisme i Cadastre són els que tenen més desenvolupada

aquesta faceta, això es constata amb la descripció que en fa el plec tècnic:

Departament d’Hisenda Departament d’Urbanisme

Funcionalitat principal Manteniment del Cadastre urbà Digitalització del planejament

Software base AutocadMap,ArcInfo/ArcView9.1,ArcIMS, ArcSDE

Autocad Map, ArcView

Servidor de mapes ArcIMS / Intranet No

Base de Dades Servidor BD Oracle Server versió 9.2.0.8 - Oracle Spatial

Oracle / DB2

Aplicacions Edició, consulta, anàlisis Edició, consulta

Usuaris Personal del Departament, tècnics del serveis urbanístics

Tècnics dels serveis

Distribució de dades Mitjançant servidor Intranet (fitxer *.shp àrea urbana i dades alfanumèriques)

No. Entorn local no integrat

Control d’accessos No existeix No. Entorn local

Taula 1 - Sistemes SIG existents


15

El mateix plec ens mostra els altres àmbits que disposen de sistemes com ara: arquitectura,

topografia, llicencies d’obres, Museu d’història/ICAC, Brigada Municipal Obres i

Senyalitzacions, Tràfic, Jardins, Enginyeria Camins, Via Publica, Enginyeria Industrial

Enllumenat TGN Serveis. En aquest entorns treballen amb diferents versions de la familia de

productes de Autocad1, de l’emprea Autodesk.

2.2. OFERTA

L’oferta presentada per l’empresa Seys aporta una proposta conceptual i metodològica per

respondre als objectius i finalitats demanades en el concurs.

La solució proposada es basa en un sistema complex en el qual interactuen diferents aplicatius

per tal de resoldre les diferents especificitats demanades al plec de condicions. Tal i com es

suggereix a l’oferta: més que un conjunt de programes informàtics, és una base tecnològica, la

qual permet resoldre les necessitats de manteniment, gestió i explotació urbanística que

existeixen a dia d’avui a l’Ajuntament de Tarragona, però també adaptar-se a noves

necessitats com vagin sorgint i créixer tant com l’ organització així ho necessiti.

La base tecnològica que es proposa es basa en un nucli de sistema que pivota en dos aplicatius,

de solvència contrastada en l’entorn de projectes SIG:

� Autodesk, amb diferents solucions comercials i funcionals, com a gestor de la

informació gràfica

� Oracle, com a gestor de la informació alfanumèrica

L’elecció dels productes d’Autodesk com a nucli del sistema respon a diferents raons pero una

de les claus és la doble Interoperativitat que ofereixen els aplicatius geoespacials d’Autodesk,

per un costat, la proporcionada per la tecnologia FDO2 i per l’altre la proporcionada pels

estandards OGC3.

1 Autocad, Autocad LT, Autocad Map

2 FDO: Feature Data Object

3 OGC: Open Geospatial consortium


16

La primera, d’accés nadiu, permet la connexió a diferents orígens de dades espacials permeten

una interoperativitat entre les diferents aplicacions d’Autodesk, amb un gran amplitud de

formats acceptats. A més a més alguns aplicatius tenen incorporada la tecnologia que permet

la interconnexió amb alguns dels estàndards de comunicació OGC. En el punt 3.3.1 es detalla el

seu significat i importància ja que aquest és un dels aspectes treballats en les pràctiques.

La plataforma tecnològica sobre la que pivota el sistema treballa en base al programari

Autodesk Topobase, si bé s’integren altres components (com pot ser el servidor de mapes i de

catàleg Deegree o el sistema de creació i edició de cartografia base AutoCAD Civil 3D)

Imatge 1 - Estructura funcionament Autodesk Topobase

Aquest programari base permetrà dotar al sistema de:

� Base de dades d’informació espacial centralitzada

� Accés multi-usuari a la informació

� Aplicacions d’Autodesk integrades (Autodesk TopoBase inclou el programari AutoCAD

Map 3D i Autodesk MapGuide Enterprise, i està basat en Oracle Spatial.)

� Arquitectura oberta i flexible

� Escalabilitat gràcies a mòduls verticals espacialitzats


17

El sistema, tal i com es demana, s’estructura en tres lots, que es podran desenvolupar de

forma independent. Així doncs existeix una arquitectura comuna sobre les tres estructures

interdependents, pel fet de ser corporatiu, amb aplicatius diferents, per adaptar-se a

l’especificitat de cada dinàmica de treball. Els diferents sistemes permeten el treball

multiusuari, la definició de diferents rols d’accés i la connectivitat que aporten els estàndards

OGC, FDO i SDO.

Els aplicatius que es faran servir en el sistema es descriuen a continuació:

Ambit Aplicatiu

Urbanisme Topobase, Geoplus plan urb Mapguide, Oracle spatial

Interopertivitat Deegree

Cartografia Base AutoCad Civil 3D AutoCad Map

Taula 2 - Aplicatius utilitats en el sistema

L’entorn de treball del sistema és un altre dels fets diferencials del projectes, i es que compta

amb un doble entorn sobre un mateix nucli:

� L’entorn d’escriptori pensat per als usuaris interns encarregats de fer el manteniment

de la informació geoespacial. Aquests necessiten eines potents, personalitzables i de

fàcil aprenentatge, que permetin aprofitar les inversions ja realitzades tant en

coneixement d’eines de CAD com en dades.

� L’entorn web esta pensat per 1) l’ús intern de les diferents àrees funcionals i dels

diferents perfils d’usuari existents dins del propi Ajuntament i 2)per a la publicació

externa de la informació municipal d’interès per als ciutadans.

Ambdós entorns permeten les funcionalitats requerides (condicionat a la mateixa i al rol

d’usuari que accedeix) i emmagatzema la informació en una base de dades centralitzada

Oracle. L’objectiu és aconseguir un sistema robust i estable que asseguri la dinàmica de treball

simultània i simbiòtica.


18

2.2.1. Arquitectura

El lot 1 – Urbanisme és el centre del sistema i ens defineix l’estructura del nucli. A continuació

es descriu l’entorn, els aplicatius i les funcionalitats:

Entorn Aplicatiu Funcionalitats

Escriptori Autodesk, TopoBase (inclou AutoCAD Map 3D)

4

Elaboració gràfica de la informació

Manteniment i consulta espacial de la base de planejament urbanístic

5

Gestió i anàlisi de la informació.

GeoPlus PlanUrb Consulta espacial de la base de planejament urbanístic

Automatització de la majoria de les tasques quotidianes.

Web MapGuide Enterprise (servidor de Mapes)

Gestió, edició i manteniment de les dades

6

Publicació i consulta simple de la informació urbanística (cerca per expedient urbanístic, per carrer i número)

Taula 3 - Arquitectura sistema urbanisme

L’emmagatzematge de la informació gràfica i de les dades, en ambdós entorns, és en format

SDO en una base de dades Oracle. La base de dades esta muntada en un servidor que conte, a

més a més, l’aplicatiu Autodesk TopoBase Administrator que és el sistema de gestió i

administració del mòdul d’urbanisme. Les funcionalitats de l’aplicatiu, implementades

directament sobre Oracle Spatial, permeten crear i gestionar tots els elements que

configuraran el nostre projecte (models de dades, gestió d’usuaris, topologies, formularis,

versions, etc.), directament sobre Oracle Spatial, però mitjançant una interfície senzilla i

funcional.

4 Aportant les eines dibuix

5 Entre les funcionalitats destaca la capacitat de validació topològica (neteja i creació de topologia) i el treball amb

versions (transaccions llargues d’Oracle) 6

sense disposar del programari instal·lat en client i podent accedir a través de la intranet


19

El lot 2 – Interoperativitat respon a la necessitat plantejada en el plec de que tot el sistema

estigui connectat entre si, permetent un flux de treball simultani i simbiòtic, i fer més eficient

la gestió dels recursos.

El plec demana que el sistema d’Interoperativitat ha de respondre als estàndards definits per

el OGC, concretament el estàndards WMS, SLD, WFS i CSW. La oferta, però, permet dos tipus

d’Interoperativitat:

� Els estàndards de l’OGC (WMS, WFS, CSW), que estan descrits àmpliament a l’apartat

3.3.1

� La tecnologia FDO, integrada en tots els aplicatius Autodesk, garanteix la

interoperativitat entre sistemes basats amb aquest productes. Aquesta tecnologia de

comunicació permet l’accés nadiu a dades i ens permetrà compartir directament amb

altres aplicacions la informació emmagatzemada a Oracle Spatial o en altres formats

suportats per FDO7. Els usuaris autoritzats podran veure i consultar directament des

d’un navegador Web tota la informació geoespacial emmagatzemada al SIG

d’Urbanisme.

El sistema es complementa en un visor de mapes o geoportal per a l’entorn web amb

navegadors lleugers que treballa amb dades matrius del serveis WMS, WFS i CSW. El

programari triat per tal d’establir els protocols de conversió i comunicació entre les dades és

deegree.

Deegree és un servidor Geoespacial desenvolupat a la Universitat de Bonn concebut per estar

en total acord amb les especificacions del OGC i la ISO/ TC 211 (incloent la ISO 19115 i 19139),

desenvolupat en Java i multi-plataforma. Ofereix, a la banda de client, una estructura de

geoportal i, a la banda de servidor , els serveis WMS, WFS, CSW, WCS, SOS. El funcionament i

arquitectura es detalla en la segona part de l’apartat 3.3.3

7 Es pot disposar d’accés nadiu a múltiples formats de Dades sense necessitat de processos d’importació i

exportació, destacant l’accés de lectura i escriptura al repositori de dades ArcSDE, com es el cas de les dades

cadastrals de l’Ajuntament de Tarragona. Es pot trobar més informació a http://fdo.osgeo.org/


20

En el sistema d’urbanisme la interoperativitat esta garantida degut al servidor de mapes

MapGuide Enterprise. Aquest està desenvolupat per Autodesk, permetent la conexió FDO, i

és un producte certificat per l’OGC en els estàndards WMS i WFS. En aquest projecte ens

permetrà publicar i accedir com a clienta la informació emmagatzemada a Oracle Spatial. La

publicació WMS i WFS ens permetrà que la informació del sistema de gestió d’informació

urbanística passi a estar disponible per a qualsevol client d’escriptori o Web (en referencia a

TopoBase Web i a Geoplus PlanUrb) que suporti aquests estàndards.

El lot 3 – Cartografia base es dissenya amb una estructura senzilla amb l’ús d’un programari

específic per les funcionalitats requerides, aquest és AutoCAD Civil 3D. L’origen de l’aplicatiu,

Autodesk, permet garantir l’ operabilitat amb els diferents components del sistema general.

El programari escollit esta pensat per enginyeria civil però conté totes les funcions de dibuix

pròpies d’AutoCAD (digitalització de línies, polilínies, arcs, cercles, etc.), les funcionalitats

aportades per AutoCAD Map 3D i més pròpies de projectes SIG (treball amb imatges ràster

georeferenciades, topologia, etc.), així com també la tecnologia FDO d’accés nadiu a dades que

permetrà des d’AutoCAD Civil 3D accedir a informació espacial i no espacial emmagatzemada

en orígens de dades suportats per FDO (Oracle, SQL Server, Shape File d’ESRI, serveis web

WMS i WFS, etc.).

L’arquitectura global del sistema es visualitza de forma clara i concisa en la següent imatge:


21

Imatge 2 - Arquitectura del sistema


22

2.2.2. Pla de treball

Els altres dos pilars sobre els que se sustenta la oferta és l’equip de treball i el calendari

d’execució. El primer pilar es basa en un nucli de disseny dels aplicatius i un de disseny

conceptual, respecte a l’equip informàtic s’hi han assignat tres enginyers informàtics superiors,

dos enginyers tècnics en informàtica, un geògraf i dos enginyers de sistemes d’Autodesk.

A nivell de disseny conceptual en el projecte s’hi ha incorporat dos arquitectes urbanistes i un

advocat espacialitzat en dret urbanístic. En referència al termini d’execució aquest fixat pel

plec de contractació, de cara al desenvolupament intern del sistema es treballa en la següent

estructura:

Imatge 3 - Fases del projecte

El calendari específic que regeix el desenvolupament del projecte i les tasques programades,

per cada fase, es mostra en la següent imatge:


23

Imatge 4 - Cronograma del projecte


24

3. EL PROJECTE

3.1. GENERALITATS

Les pràctiques del Màster han estat desenvolupades en el marc del projecte esmentat a

l’apartat anterior, amb la col·laboració de l’empresa Seys. Aquest ha estat, i és, un dels gran

projectes de l’empresa de pràctiques. En el desenvolupament trobem destinades sis persones

de forma permanent i tres de forma esporadica

La grandària i importància del projecte fa que la meva aportació en el global del projecte sigui

parcial, involucrant-me en unes parts molt especifiques definides a continuació. Malgrat la

parcialitat de la meva aportació al projecte, la magnitud d’aquest projecte dona espai a poder

observar la metodologia de treball en la qual es desenvolupen aquesta tipologia de projectes.

La determinació de les tasques especifiques a realitzar es va fer pensant en la possibilitat de

poder concloure una part concreta i significativa en el període de col·laboració. Aquestes

tasques es van determinar amb el tutor, en el moment de la meva incorporació, a traves dels

objectius assenyalats.

Tal i com s’observa, es va acordar que la meva aportació pivotaria sobre dos aspectes del

projecte, per tal de tenir una visió el més genèrica possible. Tanmateix es va acordar que la

participació més activa fos en una tasca concreta a fi i efecte que es pogués dotar a les

pràctiques la solidesa d’un projecte petit. Específicament la meva aportació en el període de

pràctiques s’enfoca en una aportació especifica i puntual en el disseny del sistema de gestió

urbanística i una de més amplia en el desenvolupament del sistema i els protocols de

connectivitat del diferents sistemes dels diversos departaments.


25

Les tasques i objectius determinats a realitzar es detallen a continuació:

Taula 4- Objectius i tasques de les pràctiques

El desenvolupament del projecte tenia establert un calendari genèric de les tasques i funcions

a desenvolupar a fi efecte de acomplir els objectius amb el temps marcat (es pot veure a

l’apartat 2.2.1). És en aquest marc que també s’ha establert un calendari propi, amb els

objectius acordats prèviament, per tal de marcar la temporalitat de l’execució de les tasques

planificades.

Objectius Tasques

Urbanisme � Revisió de la informació urbanística

� Anàlisi de la informació urbanística

� Modelització dades del POUM

� Disseny de l’estructura de dades del model d’urbanisme

Interopertivitat � Anàlisi funcional de l’entorn Deegree

� Anàlisi funcional dels serveis a desenvolupar

� Definició paràmetres de connexió i conversió de les dades als diferents serveis

� Proves de funcionalitat dels diferents serveis

� Documentació de la configuració i posada en marxa dels diferents serveis

� En ambdós entorns s’ha anat fent de forma regular i constant una validació de les tasques realitzades.

� desenvolupar els diferents serveis demanats en el projecte (WMS, WFS, CSW) amb les dades reals amb diferent tipologies d’arxius (shape, oracle, WMS remots

� configuració del geoportal en funció de les necessitats, d’estil i de funcionalitat, demandades pel client

� Redacció manual de configuració per poder adaptar el sistema dissenyat a les voluntats futures


26

Imatge 5 - Cronograma practiques

3.2. DEFINICIÓ MODEL DE DADES PEL SIG D’URBANISME

En aquest apartat es mostra el disseny de l’estructura de dades del model d’urbanisme, basat

en el redactat de la normativa del POUM8. L’estructuració de les dades i de l’entorn sobre el

qual es treballa permetrà desenvolupar la base de dades en la que se sustentarà el sistema i

realitzar, a posteriori, el desenvolupament del diferents aplicatius que componen aquest part

del projecte. La optimització del temps i els recursos del desenvolupament posterior dependrà

directament del disseny de l’estructura de les dades. La tasca duta a terme s’ha basat en la

transformació del contingut del POUM en una estructura de Base de Dades.

L’estructura d’aquest punt es basa en diferenst parts, una primera d’aproximació al objecte

d’estudi i una segona que mostra el desenvolupament i els resultats de l’estructuració de les

dades per aquest projecte.

8 Pla d’Ordenació Urbana Municipal


27

3.2.1. Aspectes teòrics

Els aspectes teorics a tenir en compte en aquesta part del projectes són dos:

� L’especificitat del fet urbanístic, punt 3.2.1.1

� L’estructuració de dades en base de dades, punt 3.2.1.2

3.2.1.1. El fet urbanístic

La tasca de l’urbanisme i dels urbanistes en les ciutats actuals no és fàcil. De forma

simplificada, es tracta, d’ordenar i planificar l’ocupació i l’ús dels espais públics i privats dels

espais urbans. El fet urbanístic te una sèrie de realitats que condicionen i afecten al disseny de

l’estructura de les dades a tractar.

Específicament la tasca dels urbanistes tracta de posar en practica les normatives de les

diferents administracions sobre l’ús i la ocupació del espais; de fer convergir els interessos dels

futurs usuaris dels espais i dels propietaris primogènits dels mateixos.

L’administració autonòmica es refereix a l’urbanisme com a: una funció pública mitjançant

l’exercici de la qual les administracions públiques competents en la matèria planifiquen o

defineixen el model urbanístic de ciutat i el desenvolupen, amb la participació dels propietaris i

de la resta d’operadors públics i privats9.

Les definicions són complexes i complementaries però la realitat ho és encara més. En el intent

de posar llum en la foscor les diferents administracions competents legislen a aquest afecte

però l’entramat legal és quasi tan complex com les definicions. Els matisos i les excepcions són

la nota dominant.

A nivell legislatiu a l’Estat Espanyol tenen competències en urbanisme els tres nivells

administratius: central, autonòmica i municipal. La redacció i execució de les diferents figures

d’ordenació i planificació urbanes depenen de forma majoritària dels Ajuntaments però

l’estructura d’aquestes figures i una sèrie de normatives marc depèn de les administracions

superior, en quant a jerarquia.

9 LLEI 2/2002, de 14 de març, d’urbanisme


28

A nivell autonòmic a Catalunya trobem que l’ús i planificació dels espais urbans estan regulats

per la llei 2/2002, de 14 de març. A nivell estatal la recent Ley de vivienda (Ley de Suelo,

2/2008, de 20 de junio) marca les pautes que depassen la llei autonòmica. En aquestes lleis es

determina els objectius de creixement urbà sostenible a curt, mig i llarg termini, es determinen

les administracions amb competències urbanístiques, es marquen els diferents règims

urbanístics del sòl i les proteccions especifiques per a casos concrets i els aprofitaments

urbanístics així com els instruments de planejament urbanístic (definint els processos de

formulació, redacció i exposició ) i les eines de gestió urbanística (a fi i efecte de transformar i

regular l’ús del sòl).

A nivell municipal cada entitat te legitimitat per redactar i executar el seu planejament d’acord

amb la legislació superior vigent, de caràcter urbanístic o no. La profunda asimetria econòmica

i poblacional dels municipis catalans i espanyols porta a resultats profundament dispars

respecte al planejament.

La complexitat però no treu que hi hagi una metodologia de treball concreta. Segons la LUC hi

ha 7 instruments de planejament urbanístic ens dos grans grups: planejament general, que

inclou el pla director urbanístic (art. 56), el pla d’ordenació urbanística municipal (art. 57 a 59),

el programa d’actuació urbanística municipal (art. 60 i 61) i una sèrie de normes de

planejament urbanístic (art. 62) i per una altre banda el planejament derivat, que inclou el pla

de millora urbana (art. 68), el pla parcial urbanístic (art. 65 i 66) i el pla espacial urbanístic en

totes les variants (art. 67 LUC).

Les diferents figures de planejament pivoten sobre tres conceptes que varien en la definició i

nomenclatura però que a nivell conceptual són bastant abordables. Aquests són:

� El regim del sòl descriu la classificació jurídica del tipus de sòl que trobem en un espai,

urbà o no, abans d’executar qualsevol de les figures descrites en els instruments de

planificació. Hi ha tres grans categories: urbà, urbanitzable i no urbanitzable podent

evolucionar entre si.

� La qualificació del sòl mostra el tipus d’espai, definit per les condicions d’ús i

d’edificació, al qual es pretén arribar un cop s’executi el planejament. Així doncs el

regim ens marca el que hi ha i la qualificació el que es pretén que hi hagi, donant un

cert marge a la inversió privada dels futurs usuaris.


29

� Els sectors de desenvolupament són els espais fisics sobre els quals s’executa el

planejament, contemplant un règim i una qualificació del sól. La dinàmica espacial del

regim i la qualificació del sòl ve determinada pels sectors de desenvolupament, encara

que aquest nom pot adquirir moltes variants segon el tipus d’instrument de

planejament en el que ens trobem. En cada figura de planejament trobarem que cada

un dels tipus de regim del sòl tindrà una regió en la qual és única i especifica; en

referència a la qualificació doncs el mateix: en cada regió determinada tindrem unes

condicions d’ordenació, urbanització, edificació i usabilitat homogènies.

3.2.1.2. L’estructuració en base de dades

La informació és l’element clau de qualsevol organització o administració. Saber que és allò

que vens, distribueixes, serveixes és clau per a qualsevol estructura productiva. Aquesta

informació es basa en dades. Aquestes haurien d’estar ben estructurades per tal de poder

dotar d’eficiència els processos de les organitzacions.

L’estructuració de les dades de forma sistemàtica es pot fer constituint una base de dades.

L’emmagatzematge , administració i explotació de les dades es fa a través dels aplicatius

anomenats sistemes gestors de bases de dades (SGBD). Aquests a més a més han de garantir

que s’assegurin les regles d’integritat i redundància, la protecció de les dades en funció de rols

d’usuaris predeterminats i la representació de relacions complexes entre les dades.

El modelat de les dades descriurà l’estructura de la base de dades i és, bàsicament, un

contenidor de dades amb els mètodes d’emmagatzematge i recuperació de la informació. Els

models de dades són abstraccions de la realitat que es poden visualitzar de forma lògica, tal i

com els entendrà el sistema, o conceptuals, tal i com els entendrà l’usuari.


30

L’estructuració de les dades i les relacions determinarà la tipologia de la base de dades i el seu

SGBD. Aquesta estructuració pot ser jeràrquica, en xarxa, relacional (SGBDR) i representar la

base de dades como una col·lecció de taules, orientada a objectes (SGBDO) determinada en

funció d’aquest objectes10 i les seves propietats o combinat els dos tipus anteriors (SGBDOR).

El disseny i implementació d’una base de dades demana una sèrie de passos previs

d’estructuració i anàlisi per tal de conèixer l’especificitat de les dades i les funcionalitats

requerides. Les bases de dades es basen en :

� Objectes, Ens limitat dotat d’una sèrie de característiques. A tall d’exemple podríem

parlar d’una casa, d’un llistat de persones

� Atributs, les diferents configuracions que poden adquirir les característiques dels

objectius. Continuant amb l’exemple podríem definir com atributs el color de la casa,

l’edat de les persones, ...

� Relacions, marca la resposta entre els objectes modelats pels seus atributs. Tancat

l’exemple podríem establir una relació entre les persones i les cases a partir de la

propietat.

La definició d’aquest tres elements en una estructura d’informació ens porta a la definició del

model conceptual, a través del diagrama Entitat-Relació (E-R). Aquest és plenament

comprensiu per un operador humà. La comprensió per part d’un sistema d‘informació

requereix un altre pas i ens demana desenvolupar el model lògic.

Imatge 6 - Definició Base de dades

La gestió, edició i manteniment de l’estructura de les dades es fa a través d’un sistema gestor

de base de dades. Existeixen diferents models de relació de dades, sent el més utilitzat

actualment el relacional (SGBDR).

10Un objecte és una representació detallada i particular d’algun fet de la realitat. Tota entitat te identitat, nom,

estat i comportament (funcions i procediments)


31

Aquest sistema de modelització de les dades es caracteritza per funcionar amb l’establiment

de taules i relacions. Cada registre esdevé un objecte en el món real, composat d’una sèrie de

columnes, camps o atributs. A nivell estructural cada columna te una nomenclatura especifica i

una tipologia de dades única, i cada fila te el mateix nombre de columnes. A més a més no es

te en compte l’ordre amb el que s’emmagatzemen els registres i les taules permeten recuperar

les dades via consultes.

Aquest sistema gestor de bases de dades relacional (SGBDR) te una sèrie de avantatges:

� Proveeix el sistema d’eines que eviten la duplicitat de registres

� Garanteix la integritat referencial11

� Afavoreix la normalització de les dades

Al mateix temps però genera una sèrie de desavantatges:

� Genera deficiències en la representació de dades gràfiques, multimèdia, CAD i GIS

� No es poden manipular el blocs de text com a tipus de dada

Les deficiències mostrades pels SGBDR es poden solucionar utilitzant els sistemes gestors de

bases de dades orientats a objectes (SGBDOO). Aquest sistema de modelat de dades

representa la informació mitjançant objectes i gestiona les dades de forma transparent amb

control de concurrència i possibilitats de recuperació de dades i de consultes associatives.

El desenvolupament d’aquests sistemes de gestió es basa en els llenguatges orientat a

objectes (Java, C#, Visual Basic.NET y C++) ja que utilitzen la mateixa metodologia de treball. És

la millor opció per garantir rendiment amb sistemes en el que es manipulin dades complexes, a

més a més unifiquen el desenvolupament dels aplicatius.

11 Al eliminar un registre s’eliminen tots els registres relacionats dependents.


32

El gran desenvolupament d’aquestes estructures permet treballa actualment amb els Sistemes

de Gestió de Bases de Dades Objecte-Relacional. Aquests es caracteritzen per ser una

extensió dels models de gestió relacionals amb components de la orientació a objectes.

Aquest tipus complexos conserven les característiques dels SGBDR (rapidesa, eficiència, etc.) i,

a més, permeten que els atributs siguin de tipus complexes. Al tractar-se d'una extensió de la

tecnologia relacional, els SGBDOR són compatibles amb la tecnologia relacional i, com que

permeten treballar amb objectes, s'adapten molt millor a les aplicacions avançades.

En el cas concret del projecte que s’està desenvolupant, per les dades alfanumèriques, el

sistema estara basat en la solució oracle. Aquest és un sistema de gestió de bases de dades

relacional (o RDBMS) desenvolupada per Oracle Corporation.

El sistema basat en Oracle gaudeix de tanta popularitat degut a la seva amplia funcionalitat

caracteritzada, a grans trets per l’estabilitat, la escalabilitat i suport de transaccions i múltiples

plataformes. La millora del sistema ha fet que les ultimes versions hagin estat certificades per

poder treballar en entorn linux. A més a més en l’entorn de dades gràfiques apareixen

recentment versions anomenades spatial, que s’ajusten a les especificitats de la informació

geoespacial12.

Aquets sistema gaudeix d’una gran popularitat, en moltes institucions i empreses, encara que

la seva hegemonia en el mercat es comença a veure qüestionada. El gran augment dels

sistemes d’informació ha estimulat la competència. Aquesta comença pel RDBMS propietari

SQL Server de Microsoft i de la oferta paral·lela d’altres RDBMS, amb llicencia lliure, com

PostgreSQL, MySql o Firebird.

12Per a més información: http://www.oracle.com o http://www.oracle.com/global/lad/database/spatial.html


33

Els principals SGBDR en funcionament al mercat es detallen a continuació:

SGBDR Desenvolupament Data 1a versió

Última versió

estable

Licencia de software

Sistema operatiu

Windows Mac OS Linux

Firebird Firebird Foundation

25/07/2000 2 Licencia Pública InterBase

si si si

Microsoft SQL Server

Microsoft 11/06/1905 9.00.2047 (2005 SP1)

Propietaria si no no

MySQL MySQL AB 01/11/1996 5.0 GPL o propietaria

si si si

Oracle Oracle Corporation 30/05/1905 11g Release 1

Propietaria si si si

PostgreSQL PostgreSQL Global Development Group

01/07/1989 8.2.3 Licencia BSD

13

si si si

Taula 5 - Comparativa SGBDR

3.2.2. Desenvolupament

La meva aportació en el sistema serà, tal com referíem anteriorment, l’estructuració de les

dades pel posterior desenvolupament del mòdul. La metodologia de treball d’aquesta part

serà d’anàlisi de les dades per tal de determinar amb la major exactitud i senzillesa possible

tots els atributs, entitats i relacions.

El document base sobre el qual es realitzarà aquest anàlisi és la normativa del POUM. Una

bona estructuració de les dades permetrà desenvolupar un entorn robust sobre la qual se

sustentarà el nucli del sistema (i del projecte). Això facilitara dotar-lo de totes les funcionalitats

requerides i, en un futur, implementar nous aplicatius i/o funcionalitats de forma més senzilla.

Els elements que condicionen l’estructuració de les dades per al desenvolupament d’aquest

apartat del projecte són:

• La naturalesa de la informació: l’urbanisme, dotat de les seves particulaitats tal i com

s’ha mostrat a l’apartat 3.2.1.1

• El disseny de l’estructura de la base de dades, que ha de respondre a unes

característiques concretes.

13 Berkeley Software Distribution


34

El desenvolupament de l’estructura de les dades, a nivell conceptual, es divideix en una sèrie

de blocs que fan el conjunt més comprensible. Aquest conjunt es pot subdividir en un bloc

central o nucli i un parell de blocs subsidiaris, complementaris però necessaris:

Imatge 7 - Estructuració genèrica informació urbanística

� El règim urbanístic del sòl a nivell del nucli de l’estructura de les dades determina:

- La classificació del sòl vindrà determinada amb una tipologia de sòl concreta.

La figura que correspongui a cada entitat espacial condicionarà el

desenvolupament del mateix. Així doncs trobem tres tipus de sòl diferents:

urbà, urbanitzable i no urbanitzable. El mateix nom ja determina bastant la

naturalesa de la tipologia però el ràpid creixement del continu urbà a

Catalunya fa que aquesta classificació, tot sovint, sigui desajustada.

- La qualificació del sòl en zones o sistemes o la inclusió en un altre tipus

d’entitat (poden ser polígons d’actuació urbanística en sòl urbà o en un sector

de planejament urbanístic derivat).

� La legislació vinculant que intervé en el planejament urbà condiciona l’estructuració

de les dades. Aquesta vinculació és a nivell sectorial i territorial. Intervenen diferents

texts legislatius que regulen la definició de les diferents activitats, figures de protecció,

àrees de servitud, regulació d’usos dels espais i algunes determinacions de caràcter

territorial14.

14El desenvolupament del POUM es veu condicionat, a tall d’exemple, per la proximitat amb l’aeroport de Reus o

per l’aprovació del Pla de les activitats industrials i turístiques del Camp de Tarragona condiona el planejament


35

� Els diferents catalegs de protecció que comprenen els monuments, edificis,jardins,

paisatges o béns culturals d'interès artístic, històric, arqueològic o típic. A més a més,

també d’acord amb la llei d’Urbanisme, s’ha creat el catàleg específic de masies i cases

rurals susceptibles de reconstrucció o rehabilitació a efectes de la seva preservació i

recuperació d’acord amb raons arquitectòniques, històriques o paisatgístiques.

L’estructuració de les dades segueix la lògica de blocs explicada i es pot veure al primer annex.

La majoria d’entitats tenen relacions senzilles però la part de qualificació urbanística és més

extensa.

Les diferents entitats que es determinen a partir d’aquesta categoria es defineixen per

extensió territorial i ús principal. La trama urbana contempla tota una sèrie de polígons que

s’integren en una categoria de qualificació del sòl, podent ser zones o sistemes15. Cada entitat

tindrà una dimensió espacial i estarà inclosa en un polígon d’actuació urbanística en sòl urbà o

en un sector de planejament urbanístic derivat.

Les zones i sistemes contemplen tota una sèrie de paràmetres que els caracteritzen i que

donen pas a un conjunt d’entitats més. Els aspectes que categoritzen aquests elements són les

condicions de la parcel·la, d’edificacició, d’ús i les condicions estètiques. Les regulacions poden

venir determinades per normatives superiors, com el POUM, la LUC, ... o be per l’especificitat

d’un pla que afecta i exclusivament aquella zona.

Imatge 8 - Estructura de les dades (Qualificació del sòl)

15 La zona és un espais susceptible de l’explotació privada i el sistema els espais d’aprofitament públic


36

La connexió entre els espais de qualificació i classificació del sol és un element molt important

en aquest sistema. Aquests paràmetres claus han de tenir un connexió gràfica i lògica ja que

les determinacions d’un afecten a l’altre i viceversa. Un règim del sòl ens determina uns

paràmetres i la qualificació ens marca més acotadament alguns altres aspectes.

La solució proposada és un connexió, gràfica i lògica, d’aquests dos elements a partir de

l’establiment i definició d’un parcel·la lògica per a cada entitat espacial que contempli cada un

dels polígons amb una única categoria i classificació del sòl.

Imatge 9 - Connexió de classificació i qualificació del sòl

3.2.3. Resultats

Els objectius marcats per a aquesta part del projecte s’han acomplert a grans trets. En aquesta

part, dedicada a la definició de l’estructura de dades d’urbanisme, s’ha aconseguit analitzar i

revisar la informació de la normativa del POUM. Aquest tractament de la informació ha donat

com a resultat un model conceptual de dades. L’estructura resultant es pot veure a l’annex 6.1

i segueix la forma explicada en l’apartat anterior.

Les dificultats trobades en la realització d’aquesta estructuració de les dades han estat més

conceptuals que estructurals. El primer contacte amb aquest bloc de dades va venir

determinat per un primer model elaborat de forma superficial.


37

L’aprofundiment sobre aquest primer model conceptual ens ha permes avançar cap a la

definició dels diferents elements, atributs i relacions. Aquesta ha estat la part més complexa i

ha demanat repassar de forma exhaustiva i continuada els diferents documents al nostre

abast. La formulació legislativa de les lleis i les quantioses excepcions ha contribuït a dificultar

l’elaboració del model.

En el model resultant estem convençuts de la bondat de la definició dels diferents elements i

les seves relacions, i cardinalitat. Ens genera dubtes la incorporació dels atributs. Estimem que

aquells que estan entrats són correctes però fa falta validar el model a client.

La conclusió d’aquest part ens porta a aquells objectius no aconseguits. Ens havíem proposat ,

per aquest part, avançar una mica més en l’estructuració de les dades. En el cas de disposar de

temps es volia evolucionar del model conceptual al lògic per tal de generar l’estructura física

de la base de dades.

L’estructura física de les dades havia de permetre instal·lar, en pre-producció, el model amb

dades reals per tal de validar-lo. Aquest pas però no es va poder dur a terme per diferents

motius. Una raó important és la falta de temps: el desenvolupament del projecte ha prioritzat

el desenvolupament del mòdul de cartografia base i el de la interconnexió dels diferents

sistemes. La part de desenvolupament del mòdul de gestió urbanística es desenvoluparà a

partir de gener de 2009.

Un altre raó més estructural del client, és que en el moment de finalització de les pràctiques

s’estava revisant el document legislatiu del POUM degut a canvis en la posada en marxa del

text normatiu16. El procés que s’havia de seguir un cop revisada i analitzada la informació del

nou text era reformular aquelles parts que fessin falta.

Un cop retocat el model conceptual i validat pel client es tractava de seguir el procés descrit:

Avançar del model conceptual al lògic i d’aquí a l’estructura física de les dades per acabar amb

el desenvolupament específic del programari.

16 El 27/05/2007 es van fer eleccions a l’Ajuntament, el canvi de govern municipal va portar a la revisió dels texts

normatius de planejament


38

3.3. IMPLEMENTACIÓ DE LA CONECTIVITAT DEL SIG CORPORATIU

En aquest apartat es mostra el disseny i el desenvolupament d’uns sistema que permeti

interoperar els diferents SIG de l’Ajuntament de Tarragona. Un dels gran objectius del sistema

es que aquest sigui interoperatiu i multiusuari, es a dir que des de tots els departaments de

l’Ajuntament es pugui treballar amb les diferents dades, sempre en funció del rol d’usuari.

Les demandes del concurs que intervenen en aquesta part del projecte consta d’un servidor

web servidors de mapes per connectar-se en xarxa i fer accessible la informació; a més a més

ha de constar d’un servidor Catàleg de metadades amb un eficient sistema de control

d’accessos. Aquest servidor ha de tenir Mòdul de Publicació de les dades, en un servei WMS.

Una altre demanada és un Visualitzador Web, basat en les especificacions OGC, i que es pugui

publicar a la web corporativa municipal pels ciutadans.

Les tasques dutes a terme en aquesta part del projecte es basen en aquestes demandes. En

aquest bloc es mostra la implementació i posada en marxa dels diferents serveis servidors de

mapes i el disseny i la posada en marxa del visualitzador web. La utilització dels estàndards i la

tria dels aplicatius que es faran servir per implementar aquest bloc es fa seguint el plec de

condicions tècniques.

A nivell estructural la primera part mostra com són i com funcionen els estàndards de

comunicació en el qual es basa aquest servei i, posteriorment, es mostra el per que de la tria

dels aplicatius utilitzats. La segona part del bloc mostra la posada en marxa de les diferents

funcionalitats del sistema.

3.3.1. Aspecte teòrics

La consolidació d’Internet com a eina i mitja d’intercanvi de dades, amb una implantació real i

practica en la societat actual, ha modificat completament l’entorn del sistemes de comunicació

i de la informació geogràfica.

Hem avançat d’un escenari amb pocs proveïdors d’informació geoespacial, que aportaven

informació a molts usuaris, a un entorn en el qual ens trobem molts proveïdors i usuaris,

essent, en molts casos, un mateix proveïdor i usuari.


39

La necessitat d’accedir i utilitzar la informació existent ens porta a la voluntat d’establir uns

patrons comuns per garantir la usabilitat de les dades. És en aquest escenari que es visualitza

la necessitat d’uns estàndards de comunicació. El canvi d’escenari, però, també ens porta a

redefinir i definir alguns aspectes, com són:

� La informació geoespacial, que es pot entendre com a fets o elements ubicats sobre el

territori amb una localització coneguda, amb una forma concreta (punt, línia o

polígon), una relació amb els elements homogenis (topologia) i la possibilitat

d’associar-hi atributs.

� La característica diferencial de la informació geoespacial és el fet de ser un llenguatge

gràfic, que el dota de universalitat, i permet combinar-lo, degut a la localització

absoluta que té intrínsicament.

� l’ús, la gestió i distribució de la informació geoespacial com a resposta, tècnica i

comercial, a una necessitat, creixent, d’intercanvi d’informació. L’augment de la

informació disponible ens determina un entorn complex i dinàmic. Per una banda els

usuaris han de poder conèixer la informació que tenen disponible, les característiques

de la mateixa per poder usar-la i combinar-la. Els proveïdors, per la seva banda, han de

poder oferir la seva producció amb una sèrie de condicions d’integritat i propietat.

� La definició d’un nou paradigma de Interoperativitat, entesa com la capacitat dels

sistemes d’informació de entendre’s amb un altre de similar i poder compartir i

combinar informació, sense que hagi d’haver un tractament específic per part de

l’usuari.

L’arquitectura tecnològica necessària per fer funcional aquest entorn depèn d’una sèrie de

protocols de comunicació de dades que es va estandarditzant i ampliant. Paral·lelament a

l’augment de funcionalitat i complexitat dels sistemes d’informació corporatives les

estructures del SIG es van ajustant a aquests paradigmes.

L’augment d’estàndards de comunicació a nivell global es va definint en la realitat de la

informació geoespacial. És en aquest sentit que una organització com el OGC pren importància

i necessitat.


40

El Open Geospatial Consortium (OGC) neix el 1994 com una entitat sense ànim de lucre.

Evoluciona amb la intenció de promoure tecnologies i aproximacions comercials al

geoprocesament interoperable. Actualment la conformen més de 360 organitzacions

publiques i privades amb el leit motiv: making the location count per fer accessible i útil la

informació geoespacial.

Els estàndards OGC se sustenten en una sèrie de tecnologies de comunicació sobre la qual

treballen els serveis web:

� Arquitectura client-servidor. Aquesta arquitectura l’hem d’entendre com a la relació

establerta entre dues entitats:

- Servidor, ofereix un recurs de qualsevol tipus (físic, de programació, de dades, etc)

a un altre sistema (el client). El més habitual és que d'una entitat servidora se

n'aprofitin diverses o moltes entitats clients. Un servidor es caracteritza per ser

passiu (esclau) a l’espera de peticions, sobre les quals emet respostes.

- El client serà oposat: actiu i enviador de peticions, de les qual espera una resposta.

Aquest sistema obtindrà una resposta dels servidor per què aquesta en tregui un

profit o avantatge. La comunicació entre clients i servidors s'utilitza un protocol de

comunicacions, que descriu com es poden comunicar i quines informacions es

poden intercanviar.

Imatge 10- Arquitectura client-servidor


41

� Els serveis web (o Web Service en anglès) són una col·lecció de protocols i estàndards

que serveix per intercanviar dades, entre aplicacions de programari desenvolupades

en llenguatges de programació diferents i executades sobre qualsevol plataforma, per

l'intercanvi de dades en una xarxa, com Internet. Aquests doncs permetran una

comunicació entre servidor i client adaptada al entorn, en aquest cas les dades

geoespacials.

En aquest context la consecució de la interoperativitat és factible i es basa en establir uns

estàndards comuns, pels diferents usuaris, proveïdors i sistemes d’informació amb component

espacial. És en aquest sentit que el OGC ha desenvolupat una sèrie d’estàndards17, fins a 28,

entre els que destaquen:

� El servei WMS produeix una resposta al servidor d’una informació gràfica que

s’identifica amb les dades consultades al servidor en funció d’una sèrie de paràmetres

donats. Aquest servei te la capacitat de llegir les dades en els seus formats originals

(dgn, ESRI shp, geotiff, ecw, connexions amb bases de dades PostGIS, Oracle Spatial,

ESRI arcSDE, etc.). Això evita haver de transformar el format d’emmagatzemament de

les dades, sempre i quan estiguin correctament georreferenciades, per permetre la

superposició. El mapa generat com a resposta del servidor serà una imatge (JPG, DNG,

...) que no ens retorna les dades, si no la visualització d’aquestes dades. Aquest fet

contrasta amb dos altres serveis, WFS i WCS, que generen dades, reals, sobre arxius,

vectorials i raster, respectivament.

� Els serveis WFS i WCS són complementaris al servei WMS. Aquests són els serveis que

especifiquen les peticions per recuperar les característiques geogràfiques. La relació

entre aquest servidor i el client és que es poden comunicar a nivell d’objecte i atribut.

L’edició de les dades respondrà a la naturalesa de les dades, aixi doncs en el servei

WFS, a més a més, defineix les operacions per accedir i manipular les dades, a traves

del llenguatge GML, podent crear noves entitats o atributs aixi com editar-les,

bloquejar-les o actualitzar-les.

17 Si voleu consultar tots podeu accedir-hi a http://www.opengeospatial.org/standards


42

- El servei WFS permet accedir a les dades en format vectorial

- El servei WCS és l’estàndard que permet accedir a les dades en format raster.

� El servei CSW és l’estàndard que permet catalogar les dades per facilitar la publicació,

consulta i cerca de dades geoespacials. Aquest servei fa referència a la dimensió

espacial i als atributs definint les metadades del servei.

� La codificació GML (Geography Markup Language) és un codificació de caràcter XML

per a transportar i emmagatzemar informació geogràfica, incloent la geometria i les

propietats dels objectes geogràfics.

Una arquitectura que relaciona serveis amb clients i servidors i la interactuació dels mateixos

es pot veure en la següent figura:

Imatge 11 - Arquitectura serveis web OGC

Els diferents serveis web dels estàndards OGC generen respostes en el client, a través de

consultes concretes sobre els servidors de dades. Així doncs les operacions de consulta són el

fet clau del sistema. Aquests ens permetran accedir a la informació, en funció de la naturalesa

de les dades i el sistema.


43

Les diferents operacions de consulta que ens permeten els diferents serveis varien en funció

de la definició i el tipus de servei. Algunes tenen caràcter obligatori i altres suggerit.

Específicament trobem les següents:

Definició Servei – Consulta Obligetorietat

descripció del contingut de la informació i dels paràmetres de petició admissibles

WMS/WCS/WFS - GetCapabilities Si

Torna una imatge del mapa els paràmetres geospacials i dimensionals de la mateixa s’han definit.

WMS – GetMap WFS – GetFeature WCS – GetCoverage

Si

Torna informació sobre entitats particulars mostrades al mapa

WMS – GetFeatureInfo, WFS – DescribeFeatureType, WCS - DescribeCoverage

Si

Afegeix, actualitza i bloqueja el contingut de les dades

WFS – InsertFeature, UpdateFeature, LockFeature

No

Taula 6 - Consultes serveis web OGC

Les diferents operacions de consulta dels diferents serveis es poden invocar a traves d’un

client lleuger o un client pesat. El primer cas la resposta al client vindrà donada a traves de la

interfície d’un navegador web a traves de la URL’s del servei, que detallen la tipologia de la

operació. En un client pesat la resposta del servidor es visualitzarà en un SIG d’escriptori,

invocant les diferents consultes de forma automatitzada.

Aquestes consultes, als diferents serveis, demanen que s’especifiqui la informació que es vol

mostrar (quines capes) la seva localització, sistema de coordenades, format de sortida,

amplada, alçada,...


44

Serveis Consulta URL

WMS GetCapabilities http://localhost:8080/deegree-wms/services?VERSION=1.0.0&SERVICE=WMS&REQUEST=GetCapabilities

WMS GetMap http://localhost:8080/deegree-wms/services?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=742&HEIGHT=667&LAYERS=pos,man, cs&FORMAT=image/png&BBOX=421344.2901594042,4584917.934759011,518622.9158858364,4661186.058168719&SRS=EPSG:23031&STYLES=

WFS DescribeFeatureType http://localhost:8080/deegree-wms/services?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType

Taula 7 - Exemple consultes sobre serveis OGC18

L’auge dels estàndards i l’èxit de la implementació dels mateixos fa possible crear un entramat

de dades consultables dinàmicament, estiguin o no emmagatzemades al mateix servidor per

realitzar les diferents operacions de visualització, consulta i operacions de geoprocés.

En aquest context d’Interoperativitat i d’augment d’intercanvi de la informació geoespacial

que es desenvolupen entorns web específicament dissenyats per tal d’emmagatzemar i

gestionar aquest conjunt creixent d’informació.

Les anomenades infraestructures de dades espacials (IDE) o Spatial Data Infrastructure (SDI),

basades en l’aplicació d’aquestes tecnologies que impulsen aquest nou paradigma de la

informació geoespacial, espacialment vinculat a l’administració.

Les IDE es basen en la integració a Internet de dades, metadades, serveis i informació

geoespacial dels diferents proveïdors facilitant als usuaris la localització, identificació, selecció

i accés a traves d’un geoportal.

18 Les URL a les quals es fa referencia són funcionals en el CD adjunt a aquest doucment que mostra la funcionalitat

del sistema


45

L’arquitectura d’una IDE:

Imatge 12 - Arquitectura IDE

Les IDE només són possibles en un context d’alt desenvolupament de la informació

geoespacial de base, en combinació amb les tecnologies de comunicació adequades. Aquest

entorn ha d’anar acompanyat per una legislació que l’afavoreixi19 i uns recursos humans amb

voluntat i coneixement per establir-la, mantenir-la i consultar-la. A nivell regional i sectorial el

creixement de les IDE és imparable esdevenint-se a més una interactuació entre els diferents

estructures.

3.3.2. Anàlisi de requeriments

El plec de condicions del concurs d’aquest projecte demana que els diferents sistemes puguin

interaccionar entre ells sense intervenció de conversió per part dels usuaris. La

Interoperativitat entre els diferents sistemes SIG municipals permet de constituir entre ells una

verdadera plataforma corporativa SIG.

19 La gran majoria d’informació prové d’organismes oficials i ha de ser possible, legislativament, la seva distribució.


46

El sistema ha d’estar conformat pels diferents productes d’informació dels diferents

departaments. Les funcionalitats i requisits especifiques que el plec demana per al sistema

d’Interoperativitat són varies:

� La creació d’un servidor/s de mapes amb funcionalitats WMS i WFS, per connectar-se

en xarxa i fer-la accessible (a usuaris externs i interns).

� La visualització a través d’un client WMS/WFS (segons protocols OGC) per a la

consulta, edició, manteniment i descàrrega de les dades. Aquest estarà desenvolupat

en:

- Llenguatge JAVA

- Codi obert

� La creació d’un catàleg de metadades de les dades i serveis existents, tant per a

publicació interna (per consulta dels diferents departaments) i externa (a través del

Catàleg IDEC) a través de l’estàndard CSW.

� La publicació automàtica de les modificacions urbanístiques en els esmentats

servidors de mapes, amb la menor intervenció possible dels serveis tècnics

responsables.

� El desenvolupament d’un sistema de control d’accessos, que responguin als diferents

perfils d’usuaris que es puguin implementar.

� La formació del personal per a la publicació i ús dels estandards

� La publicació les dades ja existents, elaborant-ne les metadades.

� L’adaptació dels sistemes existents, amb un cots baix, al sistema.

3.3.3. Solució metodològica

Les especificacions del plec ens marquen els diferents paràmetres del lot d’Interoperativitat a

implementar, i aquestes ens determinen l’elecció del mateix. L’elecció del programari a

implementar és clau per tal d’ajustar el sistema a la demanda especifica i per tal de complir

estrictament les funcionalitats demanades.


47

El programari escollit compleix els requisits i el procés de pre-producció del mateix ens ha

permès validar la opció triada, que a més a més comptava amb el vist-i-plau del client. Entre

els diferents paràmetres que s’han de tenir en compte:

� La capacitat de treballar amb els diferents estàndards OGC. Les possibilitats de tria en

aquest aspecte ens limiten molt poc, però ens mostren l’amplia gamma de possibilitats

existents. El consorci OGC, a la seva web corporativa, refereix una llista de programari

que interpreta els diferents estàndards desenvolupats, en aquesta trobem una llista de

464 productes registrats. La llista inclou des de petites consultores que han

desenvolupat un programa propi i específic, adaptant-lo als paràmetres dels

estàndards, fins a grans empreses del sector (moltes del quals han contribuït en el

desenvolupament dels mateixos). Uns mirada a la llista ens mostra que els estàndards

més presents són el WMS i WFS, en les seves diferents versions. Entre aquest llarga

llista hi ha 113 programes que compleixen els requisits oficials del consorci, és a dir

tenen l’etiqueta de compliant. La possibilitat de tria en aquest cas és immensa.

� L’adaptabilitat als diferents sistemes ja existents. En el plec de condicions tècniques i

al inici d’aquest document es mostra aquest informació. La majoria de sistemes

existents treballen amb diferents productes d’Autodesk (AutocadMap, Autocad i

autocad LT) i, alguns, amb programari d’ESRI (ArcInfo/ArcView9.1,ArcIMS i ArcSDE).

Així doncs el sistema ha de poder ser interoperable amb aquest programari, les

especificacions dels propietaris i la prova dels mateixos ens garanteixen que els

diferents programes assenyalats són capaços d’utilitzar dades amb origen d’un WMS.

El plec demana, a més a més, que el sistema ha de poder ser compatible amb

posteriors ampliacions del mateix, això farà que s’informi al client de les capacitats

d’Interoperativitat del sistema desenvolupat i els protocols per tal d’implementar nous

mòduls.

� L’accés multiusuari ens determina que el sistema d’Interoperativitat ha de poder

treballar en funció dels diferents rols d’usuaris establerts. Aquest paràmetre és el que

condiciona de forma més lleu. El sistema global està desenvolupat amb aquesta idea.

Els usuaris accediran al servei, amb un rol d’usuari predefinit, aquest determinarà les

funcionalitats que poden executar. Aixi doncs la implemetació d’aquest requisit es

solventara ajustant els diferents rols del global del sistema a aquest lot concret. En


48

l’entorn d’aquestes pràctiques aquest punt no s’ha dut a terme ja que mancava a

definir la tipologia d’usuaris per part del client. Hi ha una tipologia d’usuaris amb una

especificitat manifesta:

- usuaris externs: amb accés exclusiu, tal i com refereix el plec, a traves de la

web municipal. Les funcionalitats especifiques que el client pretén aportar als

usuaris externs no entra dins la definició d’aquest producte. Encara que la

implementació del geoportal porta definides una serie de funcionalitats

basiques de zoom i de visualització de la llegenda, de les capes

complementada amb una de carrega de dades externes.

� El programari amb codi obert, és aquell que pot ser usat, estudiat i modificat sense

restriccions permetent la millora, la copia i la redistribució (modificada o no). Els

aplicatius en codi obert són aquells en el qual el codi font està obert als usuaris

permetent modificar i millorar les funcionalitats en funció de les necessitats. El

desenvolupament s’acostuma a basar en comunitats d’usuaris i desenvolupadors que

van modificant i millorant les funcionalitats conforme aquest es va utilitzant.

Tanmateix hi ha empreses que treballen amb sistemes basats en codi obert, aquestes

es basen en un model de negoci diferent.

- En l’entorn SIG la si utilització de programari amb codi obert cada cop és més

nombrosa i es van desenvolupant cada cop més aplicatius i sistemes basats

parcialment o totalment en aquest tipus de programari. En aquest sentit

destaquen a nivell de servidor de mapes MapServer, una plataforma open

source per publicar dades geoespacials en entorn web. A nivell de SIG

d’escriptori aplicatius com QuantumGIS, GRASS, OpenJump, ... El llistat de

sistemes SIG basats en codi obert és ampli i cada dia creix, una llista es pot

veure a http://opensourcegis.org/. Una altre gran empresa dels sector que

aposta, parcialment, per aquesta estructura de desenvolupament és Autodesk

amb el producte mapguide i l’estàndard FDO com a bucs insígnia. A nivell

estructural per al projecte aquest condicionant per la presa de decisió ens

limita poc i ens permet continuar tenint una llarga llista de possibilitats.


49

Codi Punts positius

Obert Gratuïtat del sistema, espacialment interessant per les administracions públiques

Les noves versions no depenen d’estratègies comercials i permeten la correcció més rapida i eficient dels errors.

La possibilitat d’adaptació del sistema als nostres requeriments específics

L’augment de la compatibilitat entre sistemes degut al desenvolupament dels estàndards de comunicació.

Propietari Una millor protecció de la tasca de desenvolupament i per tant un desenvolupament sistematitzat i estandaritzat

l’evolució del programari prové d’una presa de decisió centralitzada i això fa que es generin productes funcionalment complementaris i inteoperables

En molts casos el producte propietari acaba esdevenint un estandar de facto (per exemple el paquet office de microsoft o els shapes d’ESRI)

una millor comptabilitat amb el hardware degut a la sinergia que creen en el mercat.

Taula 8- Aplicatius de codi obert vs codi propietari

� El llenguatge de desenvolupament de l’entorn en el qual treballem és JAVA. Aquest és un

llenguatge orientat a objectes dissenyat per Sun Microsystems, l'any 1990. El llenguatge

està caracteritzat per la seva senzillesa, robustesa, seguretat, concurrència, ja que permet

l'execució de múltiples fils d'execució o varies tasques simultàniament, i dinamisme,

l'entorn es pot estendre mitjançant enllaços a classes que poden estar localitzades en

servidors remots o en una xarxa, en una arquitectura neutral, es a dir, és independent de

la plataforma final on s'executarà el programa.

La presa de desició és complexa degut a que l’entorn de programari i aplicatius que responen

a la majoria dels criteris demanats són nombrosos amb existents i provats casos d’èxit. Entre el

maremàgnum d’opcions disponibles n’hi ha algunes que comptem amb major presencia,

algunes per portar temps en el sector i altres per oferir un elevat numero de funcionalitats i

possibilitats de customització de les mateixes.


50

El cas d’aquest projecte però te una especificitat que la fa única i és el llenguatge JAVA però el

desenvolupament de sistemes SIG en aquest llenguatge augmenta. En el panorama de l’actual

projecte el sistema que hem trobat que respongui a totes les demandes del plec és deegree, a

més a més alguns dels casos d’èxit documentats i la creixent comunitat d’usuaris inspira

confiança en el sistema a desenvolupar.

El sistema de interoperativitat en el SIG corporatiu es basarà en deegree, aquest és un entorn

de treball per al desenvolupament dels diferents blocs que composen una infraestructura de

dades espacials (IDE).

La seva arquitectura esta formada, exclusivament, per estàndards OGC en un entorn de

llicencia GNU Lesser General Public License. L’origen d’aquest sistema es remunta a l’any 2000

quan la divisió GIS del departament de geografia de la universitat de Bonn juntament amb el

spin-off Lat-lon iniciaren el desenvolupament d’una llibreria, anomenada JaGO (Java

framework for Geographical Solutions). La finalitat d’aquest desenvolupament estava pensada

per utilitzar-se en projectes basats en el processament de dades espacials, amb estàndards

OpenGIS.

En el desenvolupament d’aquest projecte canvia de nom per anomenar-se deegree i passa a

incloure un gran numero d’especificacions OGC20. Enfocats al disseny i desenvolupament de

una IDE, l’èxit del projecte es constata en que els estàndards WMS i WFS estan dins els

anomenats compilant.

El projecte està desenvolupat sota la versió 2.1, aquesta era la versió estable fins a desembre

de 2008 en el qual les diferents release version (fins a les 2.1.7) ha donat pas a la versió estable

2.2.

Els serveis web de deegree són mòduls de java controlats per un servlet21, aquest ha d’estar

integrat en un servidor web. Hi ha diferents possibilitats de servidors web encara que ells

proposen fer servir Apache-Tomcat 5.5 Servlet-Engine22 .

20 Web Map Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS), Gazetteer Service (WFS-G),

Catalog Service (CSW), Web Coordinate Transformation Service (WCTS) i Web Terrain Service (WTS). 21

un servlet és un programa que s’executa en un servidor. 22

Web page apache software foundation


51

La tria es basa en el fet de ser open-source i per la amplia difusió dotant el sistema

d’universalitat. Aquets servidor web treballa com a un contenidor de servlets, desenvolupat

per l'Apache Software Foundation que implementa les especificacions de servlet i de Java

Server Pages (JSP) de Sun Microsystems. Aquest proporciona un entorn per al codi Java, a

executar en cooperació amb un servidor web, i afegeix eines per a la configuració i el

manteniment. L’edició del sistema permet ser configurat editant els diferents fitxers de

configuració, normalment en format XML.

El funcionament de deegree a traves del servidor web es basa en l’execució dels diferents

servlet dels diferents serveis webs. Aquests reben una petició a traves del protocol http i creen

la resposta adequada, amb una arquitectura definida en la següent imatge:

Imatge 13 - Arquitectura serveis web deegree (Banda servidor)


52

L’estructura interna dels serveis web WMS, WFS i WCS és comuna, en la seva configuració

inicial respon a la següent estructura i dependència entre els diferents fitxers:

Directori Contingut

./WEB-INF Carpeta interna tomcat, permet el funcionament correcte de les aplicacions en el servidor web.

./WEB-INF/conf/w*s Arxius de configuració del servei

./WEB-INF/conf/w*s/featuretypes Arxius d’esquema de les dades (*.XSD)

./WEB-INF/conf/wms/styles Arxius d’estil de la visulaització de les capes (*.xml). Respon al estàndard OGC: SLD.

Taula 9- Estructura directoris deegree

Imatge 14 - Deegree WMS. Dependencies entre fitxers

El sistema deegree funciona amb un nucli de dades caracteritzat pels serveis WMS, WFS i WCS.

La catalogació de les dades ens permetrà accedir de forma més àgil a les dades. El serveis web

CSW és el catàleg de metadades, que ens permetrà tenir un catàleg de la informació

geoespacial que tenim a la nostra disposició. Les dades s’estructuren a traves del servei WFS,

com a origen de dades. La versió actual només permet treballar en contra el servei deegree

WFS encara que es pretén per noves versions poder treballar amb qualsevol WFS que

compleixi les especificacions del protocol OGC. El servei funciona amb la següent arquitectura:


53

Imatge 15 - CSW: relació entre arxius

La base dels serveis web de deegree és la informació geoespacial que implementarem al

servei, per tant, un dels punt importants és l’entrada de dades al servei. El serveis web deegree

WMS es caracteritzen per molts fets. Una de les característiques que més ens ha sorprès és

que no te implementat l’accés a dades de forma directa. Les dades que conformen el servei es

visualitzen i es carreguen a través dels serveis WFS, per dades vectorials, i WCS, per dades

raster. En l’estructura interna del servei hi ha dos arxius que configuren l’accés a les dades

internes. Una altre característica del sistema és que l’origen dels recursos del servei web pot

ser de caràcter local o de caràcter remot. Així doncs podem visualitzar dades pròpies però

també dades externes de diferents servidors. Els diferents formats al qual poden acceptar els

diferents serveis web són:

WMS WFS WCS

GML2 - GML3 (origen: WFS)

deegree WFS

deegree WCS

Remot WFS

Remot WCS

PostgreSQL / PostGIS

Oracle (Spatial / Locator)

Base de dades, amb conexió JDBC

ESRI Shapefiles

ArcSDE

JPEG,

GIF

PNG

BMP,

TIFF /GeoTIFF

Taula 10 - Formats deegree


54

La carrega de capes als diferents serveis web, amb independència del format original, és a

traves de la conversió a un format estàndard que permet llegir, editar i modificar les dades. La

tipologia dels arxius amb que els serveis web treballen són esquemes xml (*.xsd). Aquests

arxius s’ubiquen en una carpeta (./WEB-INF/conf/w*s/featuretypes), en la qual fem referència en

l’arxiu de configuració (w*s_configuration.xml, en la configuració original).

La conversió d’aquestes dades es pot realitzar de forma manual o amb l’ajuda d’un GIS

d’escriptori. La carrega de dades manual es fa editant les propietats en un editor, l’estructura

dels arxius es pot consultar en l’exemple existent en la documentació.

La conversió a traves d’un GIS d’escriptori, en entorn Open Source, anomenat Open Jump.

Aquest esta basat en el projecte JUMP Pilot Project (JPP)23 i permet el treball en diferents

sistemes operatius (Windows, Linux, Unix, Macintosh), permetent l’edició de geometria i

atributs. A més a més disposa de diferents plug-in (per exemple per formats específics com

ArcSDE) i esta disponible en vuit idiomes.

Les dades que permet treballar Open Jump són:

� Lectura i escriptura de dades Vectorial: ESRI Shapefile, GML, DXF

� Lectura de dades raster TIFF, JPG, PNG i ECW

� Guarda imatges JPG i PNG georeferenciades.

� Connexió a estàndards WMS i WFS.

� Connexió a Bases de dades PostGIS i Oracle

La utilització d’aquest programari es deu a que els desenvolupadors de deeegree formen part

del projecte i han realitzat un plug-in que permet la carrega i gestió de les dades a través

d’aquest aplicatiu. Aquest complement ens situa un menú específic de deegree, tal i com es

veu en la següent imatge:

23 La xarxa que desenvolupa OpenJUMP es basa en els grups Jump-Pilot Project, Projet SIGLE, el projecte Pirol

(Universitat University of Osnabrück, Alemania) i les empreses Lat/Lon GmbH (desenvolupadors de degree) i Integrated Systems Analysts, Inc. ; apart d’altres desenvolupadors independents de la comunitat.


55

Imatge 16 - Entorn treball OpenJump

La visualització de les dades dels diferents serveis web es pot:

� Per consultes directes al servidor. El protocol HTTP24 estableix la comunicació per a

l'intercanvi de documents d'hipertext i multimèdia al web. Hi ha vuit maneres

definides (a vegades anomenats "verbs") per indicar l'acció desitjada que s'ha de dur a

terme sobre el recurs. En aquest cas es pot fe la consulta mitjançant dos formats:

- Get, que sol·licita una representació del recurs especificat

- Post, que envia dades per a ser processades a un recurs específic.

� Per implementació del client WMS a traves de l’especificació Web Map Context

documents (WMC) i que permet la visualització a traves d’un navegador web. Deegree

compta amb un servei web específic per desenvolupar aquesta funcionalitat anomenat

iGeoportal que treballa amb el servei WMS com a origen de les dades.

La configuració del geoportal es basa en arxius xml, vàlid segons el XML-schema definit

pel Web Map Context specification 1.0.0. del OGC. El nucli de la configuració es

basa en un arxiu xml que conte un tag anomenat ViewContext , amb dos parts

diferenciades.

24 Protocol de transferència d'hipertext (HyperText Transfer Protocol)


56

La primera mostra la configuració del arxiu i la segona les dades a visulitzar, tal i com

es veu a la següent taula:

General Layerlist

Window Bbox Title Keyword list DescrptionURL ContactInformation Extension

Server Name Title SRS FormatList

• Format StyleList

• Style o Name o Tittle

Extension

• IOsettings:

- TempDirectory (M) - DownloadDirectory - SLDDirectory - PrintDirectory (M)

• FrontEnd

- Controller - Style - Header - Footer - CommonsJS - North - East - West - Center

• MapParameters

- Ofererinfoformats - Zoomfactor - Panfactor - Minescale - Maxescale

Taula 11- Elements arxiu configuració WMC

La configuració del geoportal compta amb dos elements capitals:

� la carrega de dades, aquestes treballen contra el servei WMS. La carrega de les

mateixes no reportarà dificultats en tant quan tinguem el servei WMS carregat i en

marxa, així doncs tan sols farà falta que el geoportal estigui ben referència al servei

WMS.

� el disseny gràfic i funcional del geoportal, que es basa en mòduls independents els uns

respecte als altres. Aquests poden ser ordenats a voluntat del client. Aquest

modularització permet adaptar l’aspecte formal a la necessitat del client. A excepció

del mapa tots els altres mòduls poden ser omesos i/o modificar les funcionalitats

associades que tenen.


57

Els mòduls es configuren a traves d’un arxiu html i javaScript incloses en l’arxiu de

configuració (WMC) o extern. L’esquema de l’arquitectura en que es basa el geoportal

és la següent:

Imatge 17- Arquitectura configuració iGeoportal

- Header i footer: arxius html estàtics en el qual, es suposa, estan a disposició de la

informació corporativa.

- North una botonera de funcionalitats avançades.

- Weast

· mòdul 2 trobem el mapa de situació

· modul 3 l’escala actual (i un combobox amb escales prefixades)

- Center:

· mòdul 4: les funcionalitats bàsiques sobre el mapa

· mòdul 5: el mapa

- South estan les coordenades x,y,

- East

· mòdul 7 l’intercambiador de contextos

· modul 8 un panell informatiu sobre les capes existents (activades o

no) o la llegenda del mapa (realitzada a partir d’una consulta

GetGraphicLegend).


58

3.3.4. Disseny funcional

L’anàlisi de requeriments de la oferta ens ha mostrat unes característiques que havia de tenir

el lot d’Interoperativitat. La cerca d’alternatives ens ha mostrat deegree com a l’opció per dur

a terme els objectius del lot. En l’apartat anterior hem fet referència a l’estructura de

l’aplicatiu triat com a base pel desenvolupament del sistema, el disseny i implementació del

sistema recau en aquet per un part. L’altre pilar que conforme el sistema són les dades i les

funcionalitats que ens demana el client.

Les dades espacials i alfanumèriques que farà servir el sistema són:

� Aquelles que posseeix i/o necessita l’Ajuntament en el moment actual

� Aquelles que seran necessàries (crear o consultar) en un futur.

Aquest mòdul de Interoperativitat ha de poder funcionar amb tota la informació geoespacial

que demandi l’Ajuntament. L’entorn de desenvolupament de deegree ens permet treballar

amb els diferents formats amb els quals es treballa des de l’Ajuntament. Així doncs farà falta

desenvolupar tota una sèrie de protocols per tal d’automatitzar l’entrada de dades, actual i

futura, als diferents serveis.

Els sistemes a desenvolupar que haurà de tenir el servei venen determinades per la oferta i el

plec de condicions. En aquests es determina que ha d’haver-hi un serveis web de mapes de

consulta i descarrega i un servei catàleg de dades.

El desenvolupament d’aquest entorn vindrà determinat per la implementació d’un servei

WMS i WFS per la publicació de dades vectorials. No es posarà en marxa el servei WCS degut a

que d’origen no es necessita la implementació en el servei de dades raster.

La visualització d’aquest sistema es farà a traves de dos interfícies:

� Una URL en la qual es podran fer les consultes de forma manual funcional per la

majoria d’usuaris però útil només per usuaris experts. A nivell funcional els diferents

serveis web han de permetre les diferents consultes associades a les especificacions

dels estàndards OGC.


59

� Un geoportal susceptible d’incorporar-se a la web corporativa de l’Ajuntament. Aquest

comptara amb les funcionalitats bàsiques (eines de zoom, pan, activació i desactivació

de capes, selecció d’informació, mesuraments i exportació)i amb dos contextos de

mapa: cadastre i urbanisme.

A mig termini es pretén és la implementació d’un servei de metadades que segueixi

l’estàndard CSW de OGC. El Client, a més a més, permetrà visualitzar aquesta informació,

combinar-la, realitzar operacions elementals amb ella (cerca per atributs, buffer..) i

descarregar-la en el propi entorn d’usuari com a fitxer GML.

A nivell estructural tot el sistema te un aspecte extern que ha d’ajustar-se a algun criteri, més

enllà del que ve per defecte amb el servei de test. En el cas d’aquest projecte l’aspecte extern

que tindran els diferents serveis vindrà determinat pel llibre d’estil de l’Ajuntament de

Tarragona.

3.3.5. Desenvolupament

La configuració dels diferents serveis web demana diferents passos per la seva posada en

marxa:

� La constitucció de l’entorn per al desenvolupament, determinat per una sèrie de

prerequisits Els que ens fan falta per implementar el servei són:

- el servidor web Tomcat Apache a partir de la versió 5.5 o superior, aquest ha

de estar associat amb un entorn de java (JRE or JSDK) en la versió 1.5 o

superior.

- L’ aplicatiu SIG d’escriptori anomenat OpenJump, en la versió 1.2, que

necessita d’una sèrie de plug-in per tal de comptar amb totes les funcionalitats

que ens permetre:

· deeJUMP plugin: implementen un menú deegree amb unes

funcionalitats per tal de carregar i editar els serveis

· OWSConfig-Plugin: implementen la correcta lectura i escriptura del

estàndards OGC

· WFS-Plugin: implementa una funcionalitat per carregar i visualitzar

dades originaries d’un servei WFS

· SisDB plugin: implementa la connexió amb una base de dades Oracle


60

� La instal·lació dels diferents serveis web de deegree, en la banda de client o servidor.

Aquest s’executen a traves d’un arxiu *.war. Al ser arxius open source estan

caracteritzats per la lliure distribució, son descarregables des de la seva pagina web

(http://www.deegree.org). La instal·lació és extremadament senzilla: un cop

descarregats els arxius al nostre entorn de treball només fa falta col·locar l’arxiu *.war

al directori $TOMCAT_HOME$/webapps i reiniciar el servidor Tomcat. Si tot ha anat

be el servei, o serveis, estarà instal·lat. Els diferents serveis s’instal·len tots de la

mateixa manera i porten una configuració de test que permet comprovar la instal·lació

del mateix i les seves capacitats.

� La carrega de dades als diferents serveis. Aquest es poden fer de forma manual o

automàtica amb l’ajuda d’un aplicatiu. Les diferents capes publicades als servei estan

estructurades en un fitxer xsd, i en el cas dels ervei WMS, te associat un arxiu SLD. En

el visualitzador web els passos a seguir són similars encara que a costumització de

l’entorn, espacialment aquell destinat a la web corporativa, haurà de estar associat al

llibre d’estil de l’Ajuntament de Tarragona.

- La carrega de dades al servei WMS amb l’ajuda de l’aplicatiu open jump es fa en

base a una, o més capes, carregades. El menu contextual que ens apareix amb el

boto dret del ratolí ens remet a l’opció: Add layer to local WMS. La carrega ens

remet a definir el nom, el títol, la definició i el sistema de coordenades. Un cop

carregada se’ns fa reiniciar el servidor. Aquest procediment es repeteix per a cada

una de les diferents capes que es vulguin afegir al sistema. L’estructura de l’arxiu

del servei aixi com de les capes es pot visualitzar a l’annex 6.2


61

Imatge 18 - Carrega de dades al servei deegree-WMS

- La carrega de dades en el servei WFS és similar. També es pot realitzar de forma

manual o amb l’ajuda de l’aplicatiu open jump. El procediment de carrega és molt

similar però l’accés és diferent. En aquest cas concret s’accedeix des del menú

deegree amb l’opció add spatial data to WFS.

Imatge 19 - Carrega de dades al servei deegree-WFS


62

- La carrega de dades en el visualitzador web el procediment és més complex. La

carrega de dades demana la configuració dels diferents arxius involucrats en el

sistema:

· La configuració de l’estructura formal i funcional es fa a traves de la

configuració de l’arxiu basic de configuració web.xml i l’arxiu de

context (wmc_xxx.xml). El geoportal de deegree permet desenvolupar

entorns amb diferents contextos, com és el cas. S’ha de tenir en

compte que cada context pot tenir un aspecte formal diferent, per

tant s’ha d’anar en compte, a nivell visual, de que tot el sistema sigui

uniforme. L’ajust dels diferents arxius que interactuen en el correcte

funcionament del geoportal és el següent pas. Tal i com definíem

anteriorment són un conjunt d’arxius html, jsp i js que podem

modificar per tal d’adaptar l’entorn a les nostres funcionalitats i estil.

A més a més en la visualització del conjunt intervé un arxiu css. En el

cas d’aquest geoportal s’ha ajustat a un arxiu subministrat pel client

per tal d’adaptar-lo al seu context. Cada cop que realitzem canvis

reiniciem el servidor per que tinguin validesa i ja tindrem el geoportal

funcionant.

· La carrega de capes de forma manual es realitza a partir de l’adició a la

secció layerlist de l’arxiu de context (WMC). La definició d’aquest

paràmetres està vinculada al servei WMS de referència, així doncs

només es poden carregar capes existents al servei WMS. El

procediment es basa en afegir un esquema de dades per cada capa

relacionat amb el servei/s WMS definits, en base a una estructura

comuna. S’ha d’anar en compte ja que el format de visualització ve

definit pel servei WMS, així doncs qualsevol modificació de les dades

ens hi hem de remetre. El sistema de coordenades ha de coincidir

amb el definit a layerlist a l’arxiu de configuració del mapa (WMC) i

que la capa estigui ubicada dins les coordenades definides.


63

3.3.6. Resultats

Els objectius que ens havíem marcat al iniciar del projecte en l’apartat de interoperativitat

s’han complert de forma genèrica. A nivell visual els resultats del sistema consta de dos parts

diferenciades:

� El servei WMS, en el qual la posada en marxa amb dades reals de client, aquest ha

estat un èxit rotund. Els serveis han incorporat dades de:

- diferents serveis: WMS i WFS.

- diferents orígens de les dades: shapes i taules d’oracle.

S’han realitzat proves, amb èxit, de les diferents consultes possibles dels serveis. A més

a més he elaborat un dossier (es troba a l’annex) que marca com implementar el servei

en l’entorn del client. La visualització dels resultats es pot veure en una URL que

permet fer consultes bàsiques del servei, tal i com es veu a la imatge:

Imatge 20 - Entorn de consulta de serveis OGC


64

� El desenvolupament del geoportal és un altre dels objectius aconseguits. Aquest ha

estat implementat amb les dades proporcionades pel client i carregades a través del

servei WMS. Tal i com s’havia plantejat s’ha desenvolupat amb dos entorns diferents

intercanviables: urbanisme i cadastre.

El geoportal s’ha implementat amb les funcionalitats bàsiques típiques d’aquests tipus

de pagines web:

- Diferents opcions de zoom: augmentar, disminució, extensió màxima, panning, ...

- Retorn d’informació i Activació/desactivació de les capes

- Carrega de capes WSM externes, per defecte es poden incorporar el WMS raster del ICC i el WMS de Cadastre

- Visualització de la llegenda, a traves de la consulta Get LegendGraphic

- Visualització de dades a partir d’escales predeterminades

Imatge 21 - Visulaització del geoportal


65

Els objectius pendents d’aconseguir en el mòdul WMS és la implementació en el seu entorn.

Aquesta es farà un cop finalitzada la pre-producció del sistema de cartografia base. En el

mòdul del geoportal el passos per a finalitzar-lo són:

� La incorporació a la pagina web de l’Ajuntament (www.tarragona.cat) a fi efecte de

que els ciutadans tinguin accés a les dades.

� La carrega de dades temàtiques:

- dels carrers i vies de circulació, per tal d’implementar un carrerer funcional

- de les parcel·les, per poder fer consultes de cadastre

En aquest cas concret no s’ha pogut implementar la funcionalitat de cerca degut a que la que

venia per defecte treballava tan sol en contra una base de dades PostGis. Aquesta tipologia

d’estructura no es contempla de treballar en el sistema descrit. En aquest cas es plantejava la

definició, dissenys i desenvolupament d’un mòdul de cerca a implementar al sistema ad-hoc

L’altre gran objectiu pendent d’aconseguir és la implementació del mòdul de metadades

(CSW). La configuració original del sistema deegree-CSW treballava contra la base de dades

PostGis però varem fer alguns intents per tal d’implementar dades des de oracle. A base

d’incorporar llibreries i fer diferents proves varem intuir per on seguir el desenvolupament.

Aquesta part no es va concloure per diferents motius: la falta de temps i la falta de voluntat del

client per tal de tenir un catàleg de dades.

Les dificultats trobades en la posada en marxa del sistema han estat sobre tot en la posada en

marxa dels diferents sistemes. La documentació aportada pels desenvolupadors del sistema és

minimalista i de comprensió complexa. A més a més l’entorn esta pensat en funció d’una

estructura molt definida i qualsevol canvi respecte aquest escenari era de dificultosa

adaptació. A tall d’exemple: aconseguir implementar dades des d’oracle va costar molts

esforços.

La principal dificultat, però, ha estat en la definició funcional del geoportal. Hem tingut repetits

problemes per tal de costumitzar-lo a voluntat del client. Descobrir les mil i una opcions que te

el sistema ha estat molt lent i esgotador. Una curiositat que te el sistema es queda guardat en

la cache dels navegadors la configuració. Cada canvi en el disseny demana esborrar la mateixa

per poder visualitzar-ho. Fins que no varem descobrir aquest punt la sensació de no avançar va

ser majúscula. En els moments en que vaig sol·licitar ajuda als companys desenvolupadors de

l’empesa de pràctiques es quedaven astorats en veure el funcionament de deegree.


66

4. CONCLUSIÓ

El final de la memòria ens porta a fer el balanç de la realització de les pràctiques. Aixó es fara

en diferents parts: a nivell generic i a nivell conceptual en aquesta primera part, que es tanca

amb el captiol d’agraiments. La segona part de la conclusió es detalla la valoració sobre les

pràctiques i sobre el projecte.

A nivell genèric crec que les conclusions són força positives. Estic satisfet en referència al

compliment de dates i objectius, en linies generals he aconseguit allo que ens haviem marcat.

Un altre punt en el qual em sento satisfet és sobre l’aprenentatge aconseguit, considero que

els tres mesos de pràctiques han estat molt utils.

A nivell conceptual és obvi el fet de l’augment d’Internet com a mitjà de difusió de la

informació geoespacial. Els canvis a nivell social i economic que aixo ha suposat han estat

impresionants; quasi tant com l’aparició de la impremta. La radical transformació del

paradigma de la infomació geoespacial ha suposat la obertura al gran public. Espacialment

d’aplicatius que no es basen en la precisió de la informació sino la usubilitat. El canvi ha estat

tant impressionant que res de tot el que en aquest document es detalla no hauria estat

possible sense aquesta revolució tecnologica.

La realització d’aquestes pràctiques i d’aquesta memoria no haria estat possible sense l’ajuda

de moltes persones. En primer lloc haig d’agrair la inestimable ajuda dels meus tutors: l’Andres

i la Laura. A nivell personal haig d’agrair la companyia del companys del department tecnic de

Seys també han estat una molt gran ajuda, tant a nivell tecnic com personal. Els companys del

Master han estat tambe una molt gran ajuda en molts moments. La familia i els amics m’han

donat la llibertat i l’estabilitat per invertir hores en la memoria i quedar-se’n ells sense. A nivell

més tecnic haig d’agrair el desenvolupament de deegree per part de l’empresa Lat/lon i,

sobtretot, el seu suport en cas de dubtes.


67

4.1. SOBRE LES PRÀCTIQUES

A nivell tecnològic estic força satisfet pel coneixement aconseguit. Per una banda considero

satisfactori la validació, a nivell personal, de la utilitat i la posada en marxa dels serveis amb

estàndard OGC. El camí ha estat complex i en molts moments desesperants però els resultats

em semblen correctes i, sobretot, hi ha molts aspectes que no s’han pogut especificar en la

memòria ja que no són tangibles. El coneixement adquirit és notable i allò que al començar em

semblava extraordinari o inabastable ara ho comprenc més, malgrat tot queda un llarg camí

per resoldre. És una obvietat que la implementació de servidores de mapes està tenint un

extraordinari auge en els últims anys, espacialment en entorns de programari obert, tant en

empreses publiques com privades. Això genera noves oportunitats en diferents àmbits amb

una elevada component espacial, per una banda a nivell laboral a diferents sectors, però per

l’altre, espacialment, a nivell de gestió d’actius i recursos.

Un altre fet que estic força satisfet d’haver utilitzat i provat és el programari SIG d’escriptori

amb codi Obert. A més a més de l’aplicatiu Open Jump hem testejat la possibilitat de fer servir

altres aplicatius, encara que no s’han fet servir pel projecte he validat la seva utilitat. Les grans

corporacions de SIG d’escriptori hauran de fer un gran esforç de diferenciació per tal de

mantenir la seva quota de mercat.

4.2. SOBRE EL PROJECTE

La conclusió a nivell del projecte realitzat en les pràctiques estic molt satisfet d’haver pogut

participar en aquest projecte; al mateix temps em sento molt afortunat de l’empresa de

pràctiques en que he fet les pràctiques. La possibilitat de veure com es desenvolupa un gran

projecte en una empresa privada ha estat molt interessant, a més a més la col·laboració de

diferents tècnics i amb diferents perfils ha estat una experiència molt profitosa.

En la meva aportació en el projecte estic satisfet de les tasques realitzades. En linies generals el

objectius que ens haviem marcat han estat aconseguits. Especificament estic molt satisfet dels

resultats del modul de interoperativitat. Haver pogut desenvolupar des de 0 el servei i

implementar-lo ha estat molt important a nivell personal i profesional. Encara que considero

que es podria haver pogut avançar més, no he sabut o no he pogut avançar més. Ha estat una

llàstima no haver pogut seguir avançant en els aspectes que han quedat oberts.


68

5. BIBLIOGRAFIA

Ajuntament de Tarragona. PLEC DE CLÀUSULES JURÍDIQUES, ECONÒMIQUES I

ADMINISTRATIVES PER LES QUALS S'HA DE REGIR EL PROCEDIMENT OBERT MITJANÇANT

CONCURS CONVOCAT PER A ’ADJUDICACIÓ DEL CONTRACTE DE SERVEIS CONSISTENT EN EL

DISSENY I DESENVOLUPAMENT D’UN SISTEMA D’INFORMACIÓ GEOGRÀFICA (SIG)

D’URBANISME INTEGRAT EN UNA PLATAFORMA CORPORATIVA DEL SIG MUNICIPAL EN

L’ÀMBIT DE L’AJUNTAMENT DE TARRAGONA Ajuntament de Tarragona - Expedient 35/08

Març 2008, Tarragona.

Ajuntament de Tarragona. PLEC DE CLÀUSULES TÈCNIQUES PER LES QUALS S’HA DE REGIR EL

PROCEDIMENT OBERT MITJANÇANT CONCURS CONVOCAT PER A L’ADJUDICACIÓ DEL

CONTRACTE DE SERVEIS CONSISTENT EN EL DISSENY I DESENVOLUPAMENT D’UN SISTEMA

D’INFORMACIÓ GEOGRÀFICA (SIG) D’URBANISME INTEGRAT EN UNA PLATAFORMA

CORPORATIVA DEL SIG MUNICIPAL EN L’ÀMBIT DE L’AJUNTAMENT DE TARRAGONA.

Ajuntament de Tarragona - Expedient 35/08 . Març 2008, Tarragona.

Ajuntament de Tarragona. POUM DE TARRAGONA, 4ª REVISIÓ PLA D’ORDENACIÓ

URBANÍSTICA MUNICIPAL . Ajuntament de Tarragona. Juny de 2007, Tarragona.

Seys. SISTEMA D’ INFORMACIÓ GEOGRAFICA D’URBANISME EN UNA PLATAFORMA

CORPORATIVA MUNICIPAL DE L’AJUNTAMENT DE TARRAGONA. Seys.

LLEI 2/2002, de 14 de març, d’urbanisme. Generalitat de Catalunya

VVAA. Introduction to OGC Web Services. OGC . Maig 2001

VVAA. Overview of OGC's Interoperability Program. OGC.

VVAA. Sistematització del planejament urbanístic. Codis d’identificació en el

planejamenturbanístic.. DPTOP – Generalitat de Catalunya. Gener 2008

VVAA. Web Map Server Implementation Specification. Versió 1.3.1 Open Geospatial

Consortium Inc. Març 2006

VVAA. Web Feature Service Implementation Specification. Versió 1.1.0 Implementation

Standard. Open Geospatial Consortium Inc. Maig 2005

VVAA. Web Coverage Service (WCS). Versió 1.1 Implementation Standard. Open Geospatial

Consortium Inc. Març 2008

VVAA JUMP (Plataforma unificada de mapas) WORKBENCH:Guía de Usuario. Vivid Solutions.

Gener 2005

VVAA. Deegree Web Map Service v2.1. lat/lon GmbH. Desembre, 2007

VVAA. Deegree Web Feature Service v2.1. lat/lon GmbH. Gener, 2007

VVAA. Deegree Web Coverage Service v2.1. lat/lon GmbH. Juny, 2007


69

VVAA. Deegree Catalogue Web Service v2.1. lat/lon GmbH. Març, 2007

VVAA. Deegree iGeoPortal -Standard Edition v2.1. lat/lon GmbH. Maig, 2007

VVAA. Deegree Web Map Service v2.2. lat/lon GmbH. Abril, 2008

VVAA. Deegree Web Feature Service v2.2. lat/lon GmbH. Abril, 2008

VVAA. Deegree Web Coverage Service v2.2. lat/lon GmbH. Abril, 2008

VVAA. Deegree Catalogue Web Service v2.2. lat/lon GmbH. Abril, 2008

VVAA. Deegree iGeoPortal -Standard Edition v2.2. lat/lon GmbH. Abril, 2008

Guimet, J. LES INFRAESTRUCTURES DE DADES ESPACIALS (IDE), UN NOU PARADIGMA EN EL

DOMINI DE LA INFORMACIÓ GEOESPACIAL. L’EXEMPLE DEL PROJECTE IDEC. Revista

CONEIXEMENT I SOCIETAT. Número 5. DURSI 2n quadrimestre 2004

GINIE (Geographic Information Network in Europe): <http://www.ec-gis.org/ginie>

GSDI (Global Spatial Data Infrastructure) Association: http://www.gsdi.org

IDEE (Infrastructura Datos Especiales España):

<http://www.idee.es/show.do?to=pideep_Info_IDEs.ES>

IDEC (Infrastructura de Dades Especials de Catalunya): <http://www.geoportal-idec.net>

INSPIRE (Infrastructure for Spatial Information in Europe): <http://www.ec-gis.org/inspire>

OpenJump < http://www.opengis.org>

Open GIS Consortium: < http://www.opengis.org>

Estandards OGC: <http://www.opengeospatial.org/standards>

Estandard FDO: <http://fdo.osgeo.org/>

Sistema d

’Info

rmació

Geo

gràfica (SIG) d

’urb

anism

e integrat en

un

a p

lataform

a corp

orativa d

el SIG m

un

icipal

70

6.

AN

NE

XO

S

6.1

. MO

DE

L BA

SE

DE

DA

DE

S

Autor: Div. Projecte Seys

Proposta Model Urbanisme Tarragona

Clasificació del Sòl (Régim Sòl)

Identificador Regim SolCodi Tipus Regim de Sol

<pi> ITXT

<M><M>

Identifier_1 <pi>

Sistemes Urbanístics

Identificador SistemaCodi Tipus SistemaTitularitatObservacions

ITXTTXTTXT

<M><M>

Sectors de Planejament

Identificador Unitat ActuacióDefinció SubzonaNom_PlaTipus PlaSuperficie aproxOcupació MàximaSostre màximPercentatge ViariPercentatge de lliure UrbaPercentatge d'equipamentsPercentatge de sol aprof privatNombre maxim de plantesIndex densitat neta màximaEstat execucióSistema d'actuacióCondicions d'usObservacions

<pi> ITXTTXTTXTFFFFFFFIFTXTTXTTXTTXT

<M><M>

Identifier_1 <pi>

Qualificació del Sól

Identificador Qualificació SòlCodi qualificació del sòlSuperficie IllaOrdreQuali_RGPOrdre_RGP

<pi> ITXTFTXTTXTTXT

<M><M>

Identifier_1 <pi>

Bens i domini public

Codi Ben i immobleIdentificador BenNom InmobleAdreçaOrigen (Adquisició, cessió)Ref catastralSuperficie del solarSuperficie construidaData construccióDescripció inmobleDestinacióClassificacióLimitsExpedient de DominiInscripció registralAntecedents de la fincaData adquisicióPreu adquisicióValoració del inmobleData alta inventariData Baixa inventariObservacions

<pi> TXTITXTTXTTXTTXTFFFTXTTXTTXTTXTTXTTXTTXTDIIDDTXT

<M><M><M>

Identifier_1 <pi>

Catàleg de protecció

Identificador element catalegCodi catalegCodi cataleg anteriorNom de catalegTipus de catalegAdreçaRef_CadastralNivell de proteccióNivell de protecció anteriorUs autoritzatUsos no autoritzatsConsideracions sobre l'usAccesoriaBarriDescripcióJustificacióEpocaSegle iniciSegle finalData projecteCronologiaElements destacatsAccions realitzadesElements PerdutsActuacions ProposadesPropietariAutor fitxaObservacionsDescatalogat?

<pi> ITXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTDTXTTXTTXTTXTTXTTXTTXTTXTBL

<M><M>

<M><M>

<M>

<M>

Identifier_1 <pi>

Servituts (Infraestructures)

Identificador servitutsCodi Tipus servitutsNom servitut

<pi> ITXTTXT

<M><M><M>

Identifier_1 <pi>

Subzones qualificació

Identificador SubzonaDefinció SubzonaTipus ordenació

<pi> ITXTTXT

<M><M>

Identifier_1 <pi>

Tipus Classificació Sol

Identificador codi RSDescripció codi regim sol

<pi> ITXT

<M><M>

Identifier_1 <pi>

Tipus Servitut

Identificador tipus servitutDescripció tipus servitut

<pi> ITXT

Identifier_1 <pi>

Plans territorias i Directors

Identificador PlanTipus PlanNom planCodi Plan

<pi> ITXTTXTTXT

<M><M><M><M>

Identifier_1 <pi>

Categories de sol

Identificador categoriaCodi categoria

<pi> ITXT

<M><M>

Identifier_1 <pi>

Normativa plans sectorials y directors

Identificador Normativa Planvalor 1valor 2valor 3etc ...

ITXTTXTTXTTXT

<M><M>

Normativa Servituts

Identificador Normativa Planvalor 1valor 2valor 3etc ...

ITXTTXTTXTTXT

<M><M>

Zones qualificació

Identificador zonaCodi zonaTipus ordenació

<pi> ITXTTXT

<M><M>

Identifier_1 <pi>

Condicions de parcel·la

Identificador C_parcel·laSuperficie minima edificableFaçana minima parcel·laOcupació MàximaDistancia minima entre edificisObservacionsExcepció1Excepció2Excepció3

<pi> IFFFFTXTTXTTXTTXT

<M><M>

Identifier_1 <pi>

Condicions edificació

Identificador C_edificacióNombre maxim de plantesFaçana mínimaAlçada reguladora màxima1Alçada reguladora màxima2Alçada reguladora màxima3Alçada reguladora màxima4Alçada reguladora màxima5Nombre màxim d'habitatgesVolum edificableEdificabilitat brutaEdificabilitat netaSeparació edificació a carrerSeparació edificació altresFondaria edificableSoterranisEspai interior d'illaVol màximIndex intensitat edificacióCossos sortintsTipus edificació permesosConstruccions auxiliarsEspai lliure d'edificacióObservacionsExcepció1Excepció2Excepció3Fondaria edificatoria (funció Sup_illa)% VPO

<pi> IIFTXTTXTTXTTXTTXTIFFFFFFBLBLFFTXTTXTBLBLTXTTXTTXTTXTFI

Identifier_1 <pi>

Condicions estetiques

Identificador C_estetiquesAlçades de plantesComposició de façanesCobertesBuits de façanesCossos volatsPlantes BaixesMaterialsBaranesRetolsProhibicionsObservacionsExcepció1Excepció2

<pi> ITXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXTTXT

<M>

Identifier_1 <pi>

Condicions Us

Identificador C_usUs principalUsos compatiblesObservacionsExcepció1Excepció2Excepció3

<pi> ITXTTXTTXTTXTTXTTXT

<M><M>

Identifier_1 <pi>

Tipus Plans

Identificador Tipus PlaCodi Tipus PlaDescripció Tipus Pla

<pi> ITXTTXT

<M><M><M>

Identifier_1 <pi>

Parcela_Logica

Identificador Parcela logicaRef_CadastralSuperficie

<pi> ITXTD

<M><M>

Identifier_1 <pi>

Normativa de cataleg

identificador normativa catalegProteccióDescripcio proteccio

<pi> IITXT

<M>

Identifier_1 <pi>

Normativa masia

identificador normativa masiaUs principalÚs adminisibleNumero de plantesAlçada realAlçada originalSostre edificableSeparació partionsNumero habitatges

<pi> <UNDEF>TXTTXTTXTIIIII

Identifier_1 <pi>

Cataleg_masies

Id_MasiaNomAdreçaBarriRef_CadastralId cataleg massosId cataleg patrimoniQualificacio solSuperficie fincaSuperficie construidaUTM XUTM Y

ITXTTXTTXTTXTIITXTTXTFSISI


71

6.2. MANUAL INSTALACIÓ SISTEMA INTEROPERATIVITAT

INSTAL�LACIÓ DE L’APLICACIÓ DE

INTEROPERABILITAT DE L’AJUNTAMENT DE

TARRAGONA


72

Arquitectura

Deegree és un conjunt d’aplicacions en entorn java. L’entorn de treball ofereix les principals eines per desenvolupar Infraestructures de Dades Especials (IDE). El global de l’arquitectura compleix amb el protocols del Open Geospatial Consortium (OGC) i la ISO/TC 211 (ISO Technical Committee 211 -- Geographic Information/Geomatics).

Originari del grup de recerrca en GIS de la Universitat de Bonn, Alemanya els aplicatius estan desenvolupats sota el paraigües de la Open Source Geospatial Foundation (OSGeo)-Project; en un entorn de software de codi lliure sota la llicencia GNU Lesser General Public License (GNU LGPL).

Els serveis web orientats a servidor responen a la següuent estructura:

Serveis

Els serveis desenvolupats segons protocols OGC permeten visualitzar, gestionar i manipular dades (raster o vectorial), en diferents formats d’emmagatzematge, i servir-lo al client.

Els diferents protocols desenvolupats s’han convingut desenvolupar els descrits a continuació:


73

Servei Nomenclàtor Descripció

WMS Web Mapping Service Accés dinàmic a la informació geoespacial, i integració i visualització d’aquesta informació.

WFS Web Feature Service Orientat a les operacions de manipulació de dades

CSW Catalog Service for Web

Orientat a les operacions de publicació i gestió de dades i serveis geoespacials

Geoportal La visualització dels serveis orientada al clinet/usuari.

El servei deegree-WMS és el centre al entorn del qual pivoten la resta. La especificació desenvolupada ens permet treballar amb diferents tipologies de dades amb els següents formats:

• GML2, GML3 originats per un servei WFS (segons protocols OGC) • Imatges originades per un servei WCS (segons protocols OGC) • Definits per un servei WFS:

� Bases de dades (Si permeten connexió JDBC) � PostgreSQL / PostGIS � Oracle (Spatial / Locator)

� ESRI Shapefiles

Prerequisits

Aplicatius necessaris:

Java (JRE or JSDK) version 1.5.x

Tomcat Apache 5.5.x

Servidor de Base de dades Oracle

OpenJump 1.2

Llibreries necessàries OpenJUMP:

� deeJUMP plugin � WFS-Plugin � OWSConfig-Plugin � SisDB plugin

Serveis deegree

Els arxius d’instal�lació dels diferents serveis oferts per Deegree son descarregables des de la seva pagina web (http://www.deegree.org). Un cop descarregats al nostre entorn de treball només fa falta col�locar l’arxiu *.war al directori $TOMCAT_HOME$/webapps i reiniciar el servidor Tomcat. Si tot ha anat be el servei estarà instal�lat. Els diferents serveis s’instal�len


74

tots de la mateixa manera i porten una configuració de test que permet comprovar la instal�lació del mateix i les seves capacitats.

Es pot comprovar el rendiment i provar la configuració dels mateixos en les següents adreces:

Servei Adreça

WMS http://localhost:8080/deegree-wms

WFS http://localhost:8080/deegree-wfs

CSW http://localhost:8080/deegree-csw

iGeoportal http://localhost:8080/igeoportal-std

Deegree a més a més ofereix la possibilitat d’instal�lar els serveis en directoris alternatius al Tomcat; per més informació comproveu la seva documentació.

Aplicatius complementaris

OpenJump és una plataforma basada en Java i en codi obert. Respon a la voluntat i necessitat de desenvolupar una plataforma d’edició i gestió de cartografia i serveis web cartogràfics. Aquest aplicatiu es caracteritza per la interoperabilitat i obertura. La instal�lació requereix tan sols d’executar l’arxiu openjump.bat (dins la carpeta .\bin) sense necessitar ubicació especifica.

La carrega de fitxers en aquest aplicatiu es realitza en base al menú Archivo->Open:

Tipus Arxius

File Shp, GML, xml, arxius imatge

Project Projectes OpenJump

Data Store Layer Arxius de Base de dades (oracle, PostGis, ...)25

WMS Layer Arxius de servei WMS

25 Oracle necessita les llibretes definides a 1.3 requisits -> llibreries -> OpenJump


75

CONFIGURACIÓ

WMS

• Arquitectura

Estructura interna del Servei (configuració original)

Directori Contingut

./WEB-INF Intern de tomcat, permet el funcionament correcte

./WEB-INF/conf/wms Arxius de configuració del servei

./WEB-INF/conf/wms/featuretypes Arxius d’esquema de les dades (*.XSD)

Dependencies entre els fitxers

• Carrega de dades

La carrega de dades demana la conversió dels arxius en estàndards que puguin interpretar el diferents servidors WMS. Aquesta conversió es pot realitzar de diferents maneres però, en aquest cas concret, s’opta per realitzar-lo a traves de l’aplicatiu OpenJump (és necessari que estiguin disponibles les llibretes especificades a l’apartat 1.3 llibreries).

La carrega de dades subministrada demana un parell d’accions. El primer canviar l’arxiu de configuració (wms_configuration.xml) a: ./WEB-INF/conf/wms/ pel subministrat; això permet configurar l’entorn de treball. El segon pas és la implementació de les dades del servei.

Aquest procés es fa a traves de la carrega dels esquemes de les dades a la carpeta: ./WEB-INF/conf/wms/featuretypes; canviant les de test que venen per defecte per les subministrades. Arribats a aquest punt només resta reiniciar els servidor Tomcat.

La carrega de dades es possible, també, fer-la de forma manual o a traves de l’aplicatiu OpenJump. En l’últim cas s’han de carreguen les dades que es volem implementar al servei a l’entorn de treball del programa. En aquest espai es comença la carrega a traves del submenú desenvolupat per deegree (faran falta les llibreries definides a: 1.3 requisits -> llibreries -> OpenJump)


76

• Procediment carrega dades manuals: � Accedim al sub-menu deegree i triem Add to local WMS configuration � Accedim al arxiu de configuració del servei26 � Definim, en dos fases, les característiques de l’esquema de l’arxiu pel servei

WMS � Visualitzem la configuració resultant, acceptant si estem conformes

El procés de carrega de dades es repeteix un a un per a totes les capes que facin falta; aquest serà idèntic en els diferents formats admesos. A fi de que els canvis en el servei tinguin validesa s’ha de reiniciar el servidor Tomcat. A més a més OpenJump permet editar la configuració de les capes. Aquest procés es fa a partir del submenú deegree: Edit local WMS. Ens permet realitzar diferents canvis: afegir capes, editar la configuració, … Un cop realitzats els canvis reiniciem el servidor per que tinguin validesa.

WFS

o Arquitectura


Directori Contingut


./WEB-INF/conf/wfs Arxius de configuració del servei

./WEB-INF/conf/wfs/featuretypes Arxius d’esquema de les dades (*.XSD)

Dependencies entre els fitxers

26 L’esquema de l’arxiu del servei ha d’anar associat al arxiu de configuració, per defecte: wms_configuration.xml


77

• Carrega de dades

La carrega de dades demana la conversió dels arxius per tal que puguin interactuar amb els diferents serveis. La implementació del servei es realitza via modificacions a l’arxiu de configuració i als arxius d’esquema de les dades. El primer pas és personalitzar l’arxiu de configuració, tan sols fa falta canviar-lo pel subministrat. En referència a la carrega dels esquema el procediment és similar. Hem de canviar els arxius existents (de test) pels subministrats a dins de a la carpeta: ./WEB-INF/conf/wms/featuretypes. Un cop realitzats els canvis reiniciem el servidor per que tinguin validesa.

La conversió dels arxius es pot realitzar de diferents maneres però es descriu la forma de realitzar-ho amb l’aplicatiu OpenJump (és necessari que estiguin disponibles les llibretes especificades a l’apartat 1.3 llibreries). Un cop obert l’aplicatiu a dins el submenú deegreee (faran falta les llibreries definides a: 1.3 requisits -> llibreries -> OpenJump). Ens posicionem a l’opció Create local WFS configuration i seguim el protocol descrit a continuació

• Procediment carrega dades manuals: � Accedim al arxiu de configuració del servei � Accedim a l’edició de feature types i creem un de nou � Escollim el tipus de format27 � Definim les característiques i el sistema de coordenades de l’esquema de l’arxiu pel servei WFS

NOTA: En cas de configurar el WFS a partir del fitxer wfs_configuration.xml original s’ha d’anar en compte de suprimir, o comentar, la part de featuretypes que porta definida per defecte (deixant aquesta linia: <wfs:FeatureTypeList/>). En cas de no fer-ho el servei no funcionarà.

Geoportal

o Arquitectura

27 Ens faran falta les llibretes definides a: 1.3 requisits -> llibreries -> OpenJump


78


Directori Contingut


./WEB-INF/conf/igeoportal Arxius de configuració del servei

./WEB-INF Arxius definidors de l’aspecte formal (*js, *.jsp, *.html)

El geoportal treballa a partir d’un entorn web configurat amb pagines estàtiques (*.html) i pagines dinàmiques (*.js i *.jsp). La configuració general es basa en arxius XML, que es relacionen els uns amb el altres, permetent la configuració de l’aspecte i l’accés a les dades.

Les dades provindran d’un servei WMS, que ens permetran, via peticions, informació de les capes, la creació de la llegenda, la gestió de les metadades, ...

L’arxiu Context configuration (.xml) refereix l’enllaç d’entrada al servei i l’arxiu de configuració. Aquest està definit com a Web Maping Context (WMC), en format *.xml. Ens permetrà configurar els diferents elements que incideixen en el geoportal. L’estructura base és la següent:

• Viewcontext o General

� Window � Bbox � Title � Keyword list � DescrptionURL � ContactInformation � Extension

• IOsettings • FrontEnd MapParameters

o Layerlist

El iGeoportal de deegree treballa en mòduls que permeten la personalització de forma senzilla, en base a la següent estructura:


79

o Carrega de dades

La carrega de dades demana la configuració dels diferents arxius, en resposta a l’aspecte formal pretès i l’accés a les dades. El primer pas és la configuració de l’arxiu basic de configuració web.xml i l’arxiu de context (wmc_xxx.xml). Aquest procés es fa canviant-los pels arxius subministrats.

El següent pas és ajustar els diferents arxius que interactuen en el correcte funcionament del geoportal. El procediment es basa en canviar els diferents arxius per aquells subministrats; els de test s’ubiquen al directori matriu del servei i s’han de canviar tots, a fi d’evitar conflictes entre la configuració inicial de test i la subministrada. Un cop estan canviats només resta canviar l’arxiu d’estil, l’existent pel subministrat; aquest s’ubica a la carpeta ./css i s’anomena deegree.css.

Un cop realitzats els canvis reiniciem el servidor per que tinguin validesa i ja tindrem el geoportal funcionant.

o Configuració manual

El geoportal admet múltiples configuracions formals i d’accés a les dades, a continuació es detallen els procediments basics per implementar noves dades i s’apunta un procediment per configurar el servei de nou. En cas de neceitar reformar la configuració presentada del geoportal pot ser interessant remetre’s a la documentació oficial del producte per entendre les multiples relacions existents en el servei.

La carrega de dades de forma manual es realitza a partir de l’adició a la secció layerlist de l’arxiu de context (WMC). La definició d’aquest paràmetres està vinculada al servei WMS de referència, així doncs només es poden carregar capes existents al servei WMS. El procediment es basa en afegir un esquema de dades per cada capa relacionat amb el servei/s WMS definits, en base a l’estructura existent.

Estructura de l’esquema de dades:

<Layer queryable="1" hidden="1"> queryable="1" especifica la capacitat de ser demanat via el process GetFeatureInfo (WMS). hidden="1" defineix la visibilitat de la capa en el moment inicial

header.html

footer.html

menubartop.html

contextswitcher.html

defaultcontentswitch.html

legend.html

layerlistview.html

menubarbottom.html

mapoverview.html

bboxinput1.html

scaleswitcher.html

note.html spacer.html

toolbar.html

mapview.html

scalebarswitcher.html

modules/gazetteer/gazmodule.html

coordinatedisplay.html


80

<Server service="OGC:WMS" version="1.1.1" title="deegree2.1 Demo WMS">

<OnlineResource xlink:type="simple" xlink:href="http://demo.deegree.org/deegree-wms/services?" />

</Server> Definiex servei de referencia, versió, titol i ubicació

<Name>Springs</Name> Nom de la capa, per la crida del servei

<Title>Springs</Title> Nom de la capa, visible al geoportal

<SRS>EPSG:26912</SRS> Sistema de coordenades

<FormatList>

<Format current="1">image/png</Format>

</FormatList> Configura el fitxer de sortida

<StyleList>

<Style current="1">

<Name>default</Name>

<Title>default</Title>

</Style>

</StyleList> Configura l’estil de la capa

<Extension xmlns:deegree="http://www.deegree.org/context">

<deegree:MasterLayer>false</deegree:MasterLayer>

</Extension>

</Layer>

El geoportal permet visualitzar les capes en diferents formats, els paràmetre d’estil (style) i de format (format) vindran definits per defecte segons el servei WMS, encara que es poden editar entrant a la carpeta featuretypes o style del servei WMS ($TOMCAT_HOME$/webapps\deegree-wms\WEB-INF\conf\wms). El sistema de coordenades ha de coincidir amb el definit a layerlist a l’arxiu de configuració del mapa (WMC) i que la capa estigui ubicada dins les coordenades definides.

Es pot definir un WMC que estableixi l’aspecte i l’accés a les dades. Aquest arxiu sera molt similar al entregat però una configuració exitosa demana alguns canvis. Els sistema de coordenades i les coordenades del mapa han de quedar definides a la part superior de l’arxiu ( <BoundingBox SRS=" " minx=" " miny=" " maxx=" " maxy=" "/>). L’altre aspecte a retocar és l’intercanvi de context , al mòdul ContextSwitcher en funció de la necesitat especifica.

L’ultim pas a realitzar és validar que el geoportal refereixi a l’arxiu pretès, si es necesita com a carrega inicial, això es fa canviant el valor als arxius:

• web.xml (webapps\igeoportal-std\WEB-INF)

<init-param>

<param-name>MapContext.configFile</param-name>

<param-value>WEB-INF/conf/igeoportal/[WMC personalitzat]l</param-value>

</init-param>

• welcome.html (\webapps\igeoportal-std)

var startContext = "wmc_tarraco.xml";

81

6.3. ARXIU CONFIGURACIÓ WMS

6.3.1. Web.xml

<?xml version="1.0"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<display-name>deegree 2.1 - WMS</display-name>

<description>deegree 2.1 OWS</description>

<servlet>

<servlet-name>owservice</servlet-name>

<servlet-class>org.deegree.enterprise.servlet.OGCServletController</servlet-class>

<init-param>

<param-name>services</param-name>

<param-value>wms</param-value>

<description>

list of supported services, e.g.: wfs,wms (comma separated) allways use lowercase

</description>

</init-param>



<init-param>

<param-name>wms.handler</param-name>

<param-value>org.deegree.enterprise.servlet.WMSHandler</param-value>

</init-param>

<init-param>

<param-name>wms.config</param-name>

<param-value>WEB-INF/conf/wms/wms_configuration.xml</param-value>

</init-param>



<init-param>

<param-name>wfs.handler</param-name>

<param-value>org.deegree.enterprise.servlet.WFSHandler</param-value>

</init-param>

<init-param>

<param-name>wfs.config</param-name>

<param-value>WEB-INF/conf/wms/LOCALWFS_capabilities.xml</param-value>

</init-param>

<load-on-startup>1</load-on-startup>


82

</servlet>

<servlet-mapping>


<url-pattern>/services</url-pattern>

</servlet-mapping>

<welcome-file-list>

<welcome-file>/index.jsp</welcome-file>

</welcome-file-list>

<error-page>

<error-code>500</error-code>

<location>/error.jsp</location>

</error-page>

<error-page>

<exception-type>org.deegree.ogcwebservices.OGCWebServiceException</exception-type>


</error-page>

</web-app>

6.3.2. Wms_configuration.xml

<?xml version="1.0" encoding="UTF-8"?><WMT_MS_Capabilities xmlns:deegree="http://www.deegree.org/wms" xmlns:gml="http://www.opengis.net/gml" xmlns:sld="http://www.opengis.net/sld" xmlns:xlink="http://www.w3.org/1999/xlink" updateSequence="1.1.0" version="1.1.1">

<deegree:DeegreeParam>

<deegree:DefaultOnlineResource xlink:href="http://localhost:8080/deegree-wms/services" xlink:type="simple"/>

<deegree:CacheSize>100</deegree:CacheSize>

<deegree:MaxLifeTime>3600</deegree:MaxLifeTime>

<deegree:RequestTimeLimit>45</deegree:RequestTimeLimit>

<deegree:MapQuality>0.95</deegree:MapQuality>

<deegree:MaxMapWidth>1500</deegree:MaxMapWidth>

<deegree:MaxMapHeight>1500</deegree:MaxMapHeight>

<deegree:AntiAliased>true</deegree:AntiAliased>

<deegree:Copyright>deegree-WMS v2.1 2007</deegree:Copyright>

<deegree:FeatureInfoRadius>10</deegree:FeatureInfoRadius>

</deegree:DeegreeParam>

<Service>

<Name>deegree wms</Name>

<Title>WMS Tarragona</Title>

<Abstract>WMS Tarragona</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>


83

<Keyword>wms</Keyword>

</KeywordList>

<OnlineResource xlink:href="http://localhost:8080/deegree-wms/services" xlink:type="simple"/>

<ContactInformation>

<ContactPersonPrimary>

<ContactPerson/>

<ContactOrganization/>

</ContactPersonPrimary>

<ContactPosition/>

<ContactAddress>

<AddressType/>

<Address/>

<City/>

<StateOrProvince/>

<PostCode/>

<Country/>

</ContactAddress>

<ContactVoiceTelephone/>

<ContactFacsimileTelephone/>

<ContactElectronicMailAddress/>

</ContactInformation>

<Fees/>

<AccessConstraints/>

</Service>

<Capability>

<Request>

<GetCapabilities>

<Format>application/vnd.ogc.wms_xml</Format>

<DCPType>

<HTTP>

<Get>


</Get>

</HTTP>

</DCPType>

</GetCapabilities>

<GetMap>

<Format>image/gif</Format>

<Format>image/png</Format>


84

<Format>image/jpg</Format>

<Format>image/tif</Format>

<Format>image/bmp</Format>

<DCPType>

<HTTP>

<Get>


</Get>

<Post>


</Post>

</HTTP>

</DCPType>

</GetMap>

<GetFeatureInfo>

<Format>application/vnd.ogc.gml</Format>

<Format>text/plain</Format>

<Format>text/html</Format>

<DCPType>

<HTTP>

<Get>


</Get>

</HTTP>

</DCPType>

</GetFeatureInfo>

<GetLegendGraphic>

<Format>image/gif</Format>

<Format>image/png</Format>

<Format>image/jpeg</Format>

<Format>image/jpg</Format>

<Format>image/tif</Format>

<Format>image/bmp</Format>

<DCPType>

<HTTP>

<Get>



85

</Get>

</HTTP>

</DCPType>

</GetLegendGraphic>

</Request>

<UserDefinedSymbolization RemoteWFS="1" SupportSLD="1" UserLayer="1" UserStyle="1"/>

<Layer xmlns:app="http://www.deegree.org/app" cascaded="0" noSubsets="0" queryable="0">

<Title>WMS Tarragona</Title>

<Abstract>WMS Tarragona</Abstract>

<KeywordList>


<Keyword>layer</Keyword>

</KeywordList>

<LatLonBoundingBox maxx="1504379.0" maxy="5432672.0" minx="0.0" miny="3581352.0"/>

<ScaleHint max="1000000" min="0"/>

<SRS>EPSG:23031</SRS>

<BoundingBox SRS="EPSG:23031" maxx="-2.9708592245890454E32" maxy="4.26503184267251E35" minx="396561.5437009193" miny="3.978598432972582E11"/>

<Layer fixedHeight="0" fixedWidth="0" noSubsets="0" queryable="1">

<Name>cs</Name>

<Title>cs</Title>

<Abstract>cs</Abstract>

<Style>

<Name>default:cs</Name>

<Title>default:cs</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/cs.xml</deegreewms:StyleResource>

</Style>

<ScaleHint max="1000000000" min="0.01"/>

<deegreewms:DataSource xmlns:deegreewms="http://www.deegree.org/wms" failOnException="0" queryable="1">

<deegreewms:Name>app:cs</deegreewms:Name>

<deegreewms:Type>LOCALWFS</deegreewms:Type>

<deegreewms:GeometryProperty>app:geometry</deegreewms:GeometryProperty>

</deegreewms:DataSource>


<BoundingBox SRS="EPSG:23031" maxx="362517.0" maxy="4558877.244688496" minx="346009.53" miny="4551279.74668351"/>


</Layer>



86

<Name>clasi</Name>

<Title>clasi</Title>

<Abstract>clasi</Abstract>

<Style>

<Name>default:clasi</Name>

<Title>default:clasi</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/clasi.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:clasi</deegreewms:Name>







</Layer>


<Name>quali</Name>

<Title>quali</Title>

<Abstract>quali</Abstract>

<Style>

<Name>default:quali</Name>

<Title>default:quali</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/quali.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:quali</deegreewms:Name>







87


</Layer>


<Name>MuniPoly</Name>

<Title>MuniPoly</Title>

<Abstract>MuniPoly</Abstract>

<Style>

<Name>default:MuniPoly</Name>

<Title>default:MuniPoly</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/MuniPoly.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:MuniPoly</deegreewms:Name>







</Layer>


<Name>tcalp</Name>

<Title>tcalp</Title>

<Abstract>tcalp</Abstract>

<Style>

<Name>default:tcalp</Name>

<Title>default:tcalp</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/tcalp.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:tcalp</deegreewms:Name>





88




</Layer>


<Name>par</Name>

<Title>par</Title>

<Abstract>par</Abstract>

<Style>

<Name>default:par</Name>

<Title>default:par</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/par.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:par</deegreewms:Name>







</Layer>


<Name>cscl</Name>

<Title>cscl</Title>

<Abstract>cscl</Abstract>

<Style>

<Name>default:cscl</Name>

<Title>default:cscl</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/cscl.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:cscl</deegreewms:Name>


89







</Layer>


<Name>man</Name>

<Title>man</Title>

<Abstract>man</Abstract>

<Style>

<Name>default:man</Name>

<Title>default:man</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/man.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:man</deegreewms:Name>







</Layer>


<Name>pos</Name>

<Title>pos</Title>

<Abstract>pos</Abstract>

<Style>

<Name>default:pos</Name>

<Title>default:pos</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/pos.xml</deegreewms:StyleResource>

</Style>



90


<deegreewms:Name>app:pos</deegreewms:Name>







</Layer>


<Name>tcall</Name>

<Title>tcall</Title>

<Abstract>tcall</Abstract>

<Style>

<Name>default:tcall</Name>

<Title>default:tcall</Title>

<deegreewms:StyleResource xmlns:deegreewms="http://www.deegree.org/wms">styles/tcall.xml</deegreewms:StyleResource>

</Style>



<deegreewms:Name>app:tcall</deegreewms:Name>







</Layer>

</Layer>

<Exception>

<Format>application/vnd.ogc.se_xml</Format>

<Format>application/vnd.ogc.se_inimage</Format>

<Format>application/vnd.ogc.se_blank</Format>

</Exception>

</Capability>

</WMT_MS_Capabilities>


91

6.3.3. Arxiu Feture type (Clasi.xsd)

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:app="http://www.deegree.org/app" xmlns:gml="http://www.opengis.net/gml" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.deegree.org/app">

<xs:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/feature.xsd"/>

<xs:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/geometryAggregates.xsd"/>

<xs:annotation>

<xs:appinfo>

<deegreewfs:Prefix xmlns:deegreewfs="http://www.deegree.org/wfs">app</deegreewfs:Prefix>

<deegreewfs:DefaultSRS xmlns:deegreewfs="http://www.deegree.org/wfs">EPSG:23031</deegreewfs:DefaultSRS>

<deegreewfs:Backend xmlns:deegreewfs="http://www.deegree.org/wfs">SHAPE</deegreewfs:Backend>

<deegreewfs:File xmlns:deegreewfs="http://www.deegree.org/wfs">..\..\..\..\..\deegree-wfs\WEB-INF\data\clasi</deegreewfs:File>

</xs:appinfo>

</xs:annotation>

<xs:element name="clasi" substitutionGroup="gml:_Feature" type="app:clasiType">

<xs:annotation>

<xs:appinfo>

<deegreewfs:table xmlns:deegreewfs="http://www.deegree.org/wfs"/>

<deegreewfs:gmlId xmlns:deegreewfs="http://www.deegree.org/wfs" prefix="CLASI_">

<deegreewfs:MappingField field="ID" type="VARCHAR"/>

<deegreewfs:IdentityPart>true</deegreewfs:IdentityPart>

</deegreewfs:gmlId>

<deegreewfs:transaction xmlns:deegreewfs="http://www.deegree.org/wfs" delete="false" insert="false" update="false"/>

</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:complexType name="clasiType">

<xs:complexContent>

<xs:extension base="gml:AbstractFeatureType">

<xs:sequence>

<xs:element minOccurs="0" name="clasi" type="xs:string">

<xs:annotation>

<xs:appinfo>

<deegreewfs:Content xmlns:deegreewfs="http://www.deegree.org/wfs">

<deegreewfs:MappingField field="CLASI" type="VARCHAR"/>

</deegreewfs:Content>


92

</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="us" type="xs:string">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="US" type="VARCHAR"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="cadID" type="xs:integer">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="CADID" type="INTEGER"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="superficie" type="xs:double">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="SUPERFICIE" type="DOUBLE"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="perimetre" type="xs:double">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="PERIMETRE" type="DOUBLE"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element name="geometry" type="gml:GeometryPropertyType">


93

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="GEOM" srs="-1" type="GEOMETRY"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:schema>

6.3.4. Arxiu SLD (Clasi.xml )

<?xml version="1.0" encoding="UTF-8"?><sld:StyledLayerDescriptor xmlns:sld="http://www.opengis.net/sld" xmlns="http://www.opengis.net/sld" xmlns:app="http://www.deegree.org/app" xmlns:deegreewfs="http://www.deegree.org/wfs" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:gml="http://www.opengis.net/gml" xmlns:java="java" xmlns:ogc="http://www.opengis.net/ogc" xmlns:wfs="http://www.opengis.net/wfs" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xslutil="de.latlon.deejump.plugin.style.XSLUtility" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">

<sld:NamedLayer>

<sld:Name>clasi</sld:Name>

<sld:UserStyle>

<sld:Name>default:clasi</sld:Name>

<sld:Title>default:clasi</sld:Title>

<sld:IsDefault>1</sld:IsDefault>

<sld:FeatureTypeStyle>

<sld:Name>clasi</sld:Name>

<sld:Rule>

<ogc:Filter>

<ogc:PropertyIsInstanceOf>

<ogc:PropertyName>app:geometry</ogc:PropertyName>

<ogc:Literal>gml:_Surface</ogc:Literal>

</ogc:PropertyIsInstanceOf>

</ogc:Filter>

<sld:Name>basicPolyStyle</sld:Name>

<sld:MinScaleDenominator>0.01</sld:MinScaleDenominator>

<sld:MaxScaleDenominator>1000000000</sld:MaxScaleDenominator>

<sld:PolygonSymbolizer>

94

<sld:Geometry>

<ogc:PropertyName>app:geometry</ogc:PropertyName>

</sld:Geometry>

<sld:Fill>

<sld:CssParameter name="fill">#ffcccc</sld:CssParameter>

<sld:CssParameter name="fill-opacity">0.588</sld:CssParameter>

</sld:Fill>

<sld:Stroke>

<sld:CssParameter name="stroke">#b28e8e</sld:CssParameter>

<sld:CssParameter name="stroke-opacity">0.588</sld:CssParameter>

<sld:CssParameter name="stroke-width">1</sld:CssParameter>

</sld:Stroke>

</sld:PolygonSymbolizer>

</sld:Rule>

</sld:FeatureTypeStyle>

</sld:UserStyle>

</sld:NamedLayer>

</sld:StyledLayerDescriptor>

6.4. ARXIU CONFIGURACIÓ WFS

6.4.1. Web.xml

<?xml version="1.0"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<display-name>deegree 2.1 - WFS</display-name>

<description>deegree 2.1 OWS</description>

<servlet>


<servlet-class>org.deegree.enterprise.servlet.OGCServletController</servlet-class>

<init-param>

<param-name>services</param-name>

<param-value>wfs</param-value>

<description>

list of supported services, e.g.: wfs,wms (comma separated) allways use lowercase

</description>

</init-param>

95





<init-param>

<param-name>wfs.handler</param-name>

<param-value>org.deegree.enterprise.servlet.WFSHandler</param-value>

</init-param>

<init-param>

<param-name>wfs.config</param-name>

<param-value>WEB-INF/conf/wfs/wfs_configuration.xml</param-value>

</init-param>

96





<init-param>

<param-name>csw.handler</param-name>

<param-value>org.deegree.enterprise.servlet.CSWHandler</param-value>

</init-param>

<init-param>

<param-name>csw.config</param-name>



<param-value>..\..\..\..\deegree-csw\WEB-INF\conf\wfs\csw_capabilities.xml</param-value>

</init-param>







<!-- <init-param>

<param-name>wpvs.handler</param-name>

<param-value>org.deegree.enterprise.servlet.WPVSHandler</param-value>

</init-param>

<init-param>

<param-name>wpvs.config</param-name>

<param-value>WEB-INF/conf/wpvs/example_wpvs_configuration.xml</param-value>

</init-param>

97

-->

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>


<url-pattern>/services</url-pattern>

</servlet-mapping>

<welcome-file-list>

<welcome-file>/index.jsp</welcome-file>

</welcome-file-list>

<error-page>

<error-code>500</error-code>


</error-page>

<error-page>

<exception-type>org.deegree.ogcwebservices.OGCWebServiceException</exception-type>


</error-page>

</web-app>

6.4.2. Wfs_configuration.xml

<?xml version="1.0" encoding="UTF-8"?><wfs:WFS_Capabilities xmlns:wfs="http://www.opengis.net/wfs" xmlns:app="http://www.deegree.org/app" xmlns:deegreewfs="http://www.deegree.org/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:xlink="http://www.w3.org/1999/xlink" updateSequence="0" version="1.1.0">







<deegreewfs:deegreeParams>



<deegreewfs:DefaultOnlineResource xlink:href="http://desarrollo8:8080/deegree-wfs/services" xlink:type="simple"/>



<deegreewfs:CacheSize>250</deegreewfs:CacheSize>



<deegreewfs:RequestTimeLimit>120</deegreewfs:RequestTimeLimit>



<deegreewfs:DataDirectoryList>

98

<deegreewfs:DataDirectory>featuretypes</deegreewfs:DataDirectory>

</deegreewfs:DataDirectoryList>





</deegreewfs:deegreeParams>







<ows:ServiceIdentification>

<ows:Title>WMS Ajuntament de Tarragona</ows:Title>

<ows:Abstract>WMS Ajuntament de Tarragona</ows:Abstract>

<ows:ServiceType>WFS</ows:ServiceType>

<ows:ServiceTypeVersion>1.1.0</ows:ServiceTypeVersion>

<ows:Fees>None</ows:Fees>

<ows:AccessConstraints>None</ows:AccessConstraints>

</ows:ServiceIdentification>







<ows:ServiceProvider>

<ows:ProviderName></ows:ProviderName>

<ows:ProviderSite xlink:href="http://www.lat-lon.de"/>

<ows:ServiceContact>

<ows:IndividualName></ows:IndividualName>

<ows:PositionName>

</ows:PositionName>

<ows:ContactInfo>

<ows:Phone>

<ows:Voice></ows:Voice>

<ows:Facsimile></ows:Facsimile>

</ows:Phone>

<ows:Address>

<ows:DeliveryPoint>

</ows:DeliveryPoint>

<ows:City>Tarragona</ows:City>

<ows:AdministrativeArea>

99

</ows:AdministrativeArea>

<ows:PostalCode></ows:PostalCode>

<ows:Country>Germany</ows:Country>

<ows:ElectronicMailAddress>

</ows:ElectronicMailAddress>

</ows:Address>

<ows:OnlineResource />

<ows:HoursOfService></ows:HoursOfService>

<ows:ContactInstructions>

</ows:ContactInstructions>

</ows:ContactInfo>

<ows:Role></ows:Role>

</ows:ServiceContact>

</ows:ServiceProvider>







<ows:OperationsMetadata>

<ows:Operation name="GetCapabilities">

<ows:DCP>

<ows:HTTP>

<ows:Get xlink:href="http://desarrollo8:8080/deegree-csw/services?"/>

</ows:HTTP>

</ows:DCP>

<ows:Parameter name="AcceptVersions">

<ows:Value>1.1.0</ows:Value>

<ows:Value>1.0.0</ows:Value>

</ows:Parameter>

<ows:Parameter name="AcceptFormats">

<ows:Value>text/xml</ows:Value>

</ows:Parameter>

<ows:Parameter name="Sections">

<ows:Value>ServiceIdentification</ows:Value>

<ows:Value>ServiceProvider</ows:Value>

<ows:Value>OperationsMetadata</ows:Value>

<ows:Value>FeatureTypeList</ows:Value>

<ows:Value>ServesGMLObjectTypeList</ows:Value>


100

<ows:Value>SupportsGMLObjectTypeList</ows:Value>

<ows:Value>Filter_Capabilities</ows:Value>

</ows:Parameter>

</ows:Operation>

<ows:Operation name="DescribeFeatureType">

<ows:DCP>

<ows:HTTP>


<ows:Post xlink:href="http://desarrollo8:8080/deegree-csw/services"/>

</ows:HTTP>

</ows:DCP>

<ows:Parameter name="outputFormat">

<ows:Value>text/xml; subtype=gml/3.1.1</ows:Value>

</ows:Parameter>

</ows:Operation>

<ows:Operation name="GetFeature">

<ows:DCP>

<ows:HTTP>


<ows:Post xlink:href="http://desarrollo8:8080/deegree-csw/services"/>

</ows:HTTP>

</ows:DCP>

<ows:Parameter name="resultType">

<ows:Value>results</ows:Value>

<ows:Value>hits</ows:Value>

</ows:Parameter>

<ows:Parameter name="outputFormat">


</ows:Parameter>

</ows:Operation>

<ows:Operation name="Transaction">

<ows:DCP>

<ows:HTTP>


</ows:HTTP>

</ows:DCP>

<ows:Parameter name="inputFormat">

101


</ows:Parameter>

<ows:Parameter name="idgen">

<ows:Value>GenerateNew</ows:Value>

<ows:Value>UseExisting</ows:Value>

<ows:Value>ReplaceDuplicate</ows:Value>

</ows:Parameter>

<ows:Parameter name="releaseAction">

<ows:Value>ALL</ows:Value>

<ows:Value>SOME</ows:Value>

</ows:Parameter>

</ows:Operation>

<ows:Parameter name="srsName">

<ows:Value>EPSG:23031</ows:Value>

</ows:Parameter>

<ows:Constraint name="DefaultMaxFeatures">

<ows:Value>20000</ows:Value>

</ows:Constraint>

<ows:Constraint name="LocalTraverseXLinkScope">


<ows:Value>*</ows:Value>

</ows:Constraint>

<ows:Constraint name="RemoteTraverseXLinkScope">


<ows:Value>*</ows:Value>

</ows:Constraint>

<ows:Constraint name="DefaultLockExpiry">


</ows:Constraint>

</ows:OperationsMetadata>







<wfs:FeatureTypeList/>







<ogc:Filter_Capabilities>

<ogc:Spatial_Capabilities>

<ogc:GeometryOperands>


102

<ogc:GeometryOperand>gml:Envelope</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>

<ogc:GeometryOperand>

gml:LineString

</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>

</ogc:GeometryOperands>

<ogc:SpatialOperators>

<ogc:SpatialOperator name="BBOX"/>

<ogc:SpatialOperator name="Equals"/>

<ogc:SpatialOperator name="Disjoint"/>

<ogc:SpatialOperator name="Intersects"/>

<ogc:SpatialOperator name="Touches"/>

<ogc:SpatialOperator name="Crosses"/>

<ogc:SpatialOperator name="Within"/>

<ogc:SpatialOperator name="Contains"/>

<ogc:SpatialOperator name="Overlaps"/>

<ogc:SpatialOperator name="Beyond"/>

</ogc:SpatialOperators>

</ogc:Spatial_Capabilities>

<ogc:Scalar_Capabilities>

<ogc:LogicalOperators/>

<ogc:ComparisonOperators>

<ogc:ComparisonOperator>LessThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>LessThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>EqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>NotEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Like</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Between</ogc:ComparisonOperator>

<ogc:ComparisonOperator>NullCheck</ogc:ComparisonOperator>

</ogc:ComparisonOperators>

<ogc:ArithmeticOperators>

<ogc:SimpleArithmetic/>

</ogc:ArithmeticOperators>

</ogc:Scalar_Capabilities>

<ogc:Id_Capabilities>

<ogc:EID/>


103

<ogc:FID/>

</ogc:Id_Capabilities>

</ogc:Filter_Capabilities>

</wfs:WFS_Capabilities>

6.4.3. Arxiu Feture type (Classificacio.xsd)

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:app="http://www.deegree.org/app" xmlns:gml="http://www.opengis.net/gml" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.deegree.org/app">

<xs:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/feature.xsd"/>

<xs:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/geometryAggregates.xsd"/>

<xs:annotation>

<xs:appinfo>

<deegreewfs:Prefix xmlns:deegreewfs="http://www.deegree.org/wfs">app</deegreewfs:Prefix>

<deegreewfs:DefaultSRS xmlns:deegreewfs="http://www.deegree.org/wfs">EPSG:23031</deegreewfs:DefaultSRS>

<deegreewfs:Backend xmlns:deegreewfs="http://www.deegree.org/wfs">SHAPE</deegreewfs:Backend>

<deegreewfs:File xmlns:deegreewfs="http://www.deegree.org/wfs">..\..\..\data\clasi</deegreewfs:File>

</xs:appinfo>

</xs:annotation>

<xs:element name="classificacio" substitutionGroup="gml:_Feature" type="app:classificacioType">

<xs:annotation>

<xs:appinfo>

<deegreewfs:table xmlns:deegreewfs="http://www.deegree.org/wfs"/>

<deegreewfs:gmlId xmlns:deegreewfs="http://www.deegree.org/wfs" prefix="CLASSIFICACIO_">

<deegreewfs:MappingField field="ID" type="VARCHAR"/>

<deegreewfs:IdentityPart>true</deegreewfs:IdentityPart>

</deegreewfs:gmlId>

<deegreewfs:transaction xmlns:deegreewfs="http://www.deegree.org/wfs" delete="false" insert="false" update="false"/>

<deegreewfs:OtherSRS xmlns:deegreewfs="http://www.deegree.org/wfs">EPSG:23031</deegreewfs:OtherSRS>

</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:complexType name="classificacioType">

<xs:complexContent>

<xs:extension base="gml:AbstractFeatureType">

<xs:sequence>


104

<xs:element minOccurs="0" name="CLASI" type="xs:string">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="CLASI" type="VARCHAR"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="US" type="xs:string">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="US" type="VARCHAR"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="CADID" type="xs:integer">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="CADID" type="BIGINT"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="SUPERFICIE" type="xs:double">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="SUPERFICIE" type="DOUBLE"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="PERIMETRE" type="xs:double">

<xs:annotation>

<xs:appinfo>


105

<deegreewfs:MappingField field="PERIMETRE" type="DOUBLE"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element name="geometry" type="gml:GeometryPropertyType">

<xs:annotation>

<xs:appinfo>


<deegreewfs:MappingField field="GEOM" srs="-1" type="GEOMETRY"/>


</xs:appinfo>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:schema>

6.5. ARXIU CONFIGURACIÓ GEOPORTAL

6.5.1. Wmc_urbanisme.xml

<?xml version="1.0" encoding="UTF-8"?>

<ViewContext xmlns="http://www.opengis.net/context" xmlns:sld="http://www.opengis.net/sld"

xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

version="1.0.0" id="String">

<General>



<Window width="800" height="600" />

<BoundingBox SRS="EPSG:23031" minx="345800" miny="4547000" maxx="367000" maxy="4560000"/>



<Title>Geoportal de l'ajuntament de Tarragona</Title>

<KeywordList>


<Keyword>iGeoPortal</Keyword>

<Keyword>SDI</Keyword>

106

<Keyword>GDI</Keyword>

</KeywordList>

<DescriptionURL format="text/html">

<OnlineResource xlink:type="simple" xlink:href="http://www.deegree.org" />

</DescriptionURL>

<ContactInformation>

<ContactPersonPrimary>

<ContactPerson>Andreas Poth</ContactPerson>

<ContactOrganization>lat/lon</ContactOrganization>

</ContactPersonPrimary>

<ContactPosition>developer</ContactPosition>

<ContactAddress>

<AddressType>postal</AddressType>

<Address>Aennchenstr. 19</Address>

<City>Bonn</City>

<StateOrProvince>NRW</StateOrProvince>

<PostCode>53177</PostCode>

<Country>Germany</Country>

</ContactAddress>

<ContactVoiceTelephone>++49 228 184960</ContactVoiceTelephone>

<ContactElectronicMailAddress>[email protected]</ContactElectronicMailAddress>

</ContactInformation>


<deegree:IOSettings>

<deegree:TempDirectory>

<deegree:Name>../../../tmp</deegree:Name>

<deegree:Access>

<OnlineResource xlink:type="simple"

xlink:href="http://desarrollo8:8080/igeoportal-std" />

</deegree:Access>

</deegree:TempDirectory>



<deegree:SLDDirectory>

<deegree:Name>../../../</deegree:Name>

107

<deegree:Access>


xlink:href="http://desarrollo8:8080/igeoportal-std" />

</deegree:Access>

</deegree:SLDDirectory>

<deegree:PrintDirectory>

<deegree:Name>../../../print</deegree:Name>

<deegree:Access>


xlink:href="http://desarrollo8:8080/igeoportal-std/print" />

</deegree:Access>

</deegree:PrintDirectory>

</deegree:IOSettings>

<deegree:Frontend scope="JSP">

<deegree:Controller>./modules/controller/controller.jsp</deegree:Controller>

<deegree:Style>./css/deegree.css</deegree:Style>

<deegree:Header>header.html</deegree:Header>

<deegree:Footer>footer.html</deegree:Footer>

<deegree:CommonJS>

<deegree:Name>event.js</deegree:Name>

<deegree:Name>envelope.js</deegree:Name>

<deegree:Name>geotransform.js</deegree:Name>

<deegree:Name>pushbutton.js</deegree:Name>

<deegree:Name>togglebutton.js</deegree:Name>

<deegree:Name>layergroup.js</deegree:Name>

<deegree:Name>htmllayer.js</deegree:Name>

<deegree:Name>layerutils.js</deegree:Name>

<deegree:Name>rpc.js</deegree:Name>

<deegree:Name>recentertolayer.js</deegree:Name>

</deegree:CommonJS>



<deegree:North hidden="false">

<deegree:Module hidden="false" type="content" width="1200" height="35">

<deegree:Name>MenuBarTop</deegree:Name>

<deegree:Content>menubartop.html</deegree:Content>

<deegree:ModuleJS>menubar.js</deegree:ModuleJS>

</deegree:Module>

</deegree:North>



<deegree:East hidden="false">

108


<deegree:Name>ContextSwitcher</deegree:Name>

<deegree:Content>contextswitcher.html</deegree:Content>

<deegree:ModuleJS>contextswitcher.js</deegree:ModuleJS>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>label</deegree:Name>

<deegree:Value>'Temes disponibles:'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>listOfContexts</deegree:Name>



<deegree:Value>'Urbanisme|wmc_urbanisme.xml;Cadastre|wmc_tarraco.xml'</deegree:Value>






<deegree:Parameter>

<deegree:Name>size</deegree:Name>

<deegree:Value>1</deegree:Value>


<deegree:Parameter>

<deegree:Name>bgcolor</deegree:Name>

<deegree:Value>'#EEF9F4'</deegree:Value>


</deegree:ParameterList>

</deegree:Module>


<deegree:Name>DefaultContentSwitch</deegree:Name>

<deegree:Content>defaultcontentswitch.html</deegree:Content>

<deegree:ModuleJS>contentswitch.js</deegree:ModuleJS>


<deegree:Parameter>

<deegree:Name>targetIFrame</deegree:Name>


109

<deegree:Value>'LayerListView'</deegree:Value>


<deegree:Parameter>

<deegree:Name>sourceModules</deegree:Name>

<deegree:Value>

'Llista de capes visibles|layerlistview.html;Llegenda|legend.html'

</deegree:Value>



</deegree:Module>

<deegree:Module hidden="true" type="content" width="250" height="460">

<deegree:Name>Legend</deegree:Name>

<deegree:Content>legend.html</deegree:Content>

<deegree:ModuleJS>legend.js</deegree:ModuleJS>


<deegree:Parameter>


<deegree:Value>'Llegenda'</deegree:Value>


<deegree:Parameter>




<deegree:Parameter>

<deegree:Name>layerlist</deegree:Name>

<deegree:Value>this.layerList</deegree:Value>


<deegree:Parameter>

<deegree:Name>width</deegree:Name>



<deegree:Parameter>

<deegree:Name>height</deegree:Name>




</deegree:Module>


<deegree:Name>LayerListView</deegree:Name>

<deegree:Content>layerlistview.html</deegree:Content>

110

<deegree:ModuleJS>layerlist.js</deegree:ModuleJS>

<deegree:ModuleJS>layerlistview.js</deegree:ModuleJS>






<deegree:Parameter>

<deegree:Name>name</deegree:Name>

<deegree:Value>'Llista de capes visibles'</deegree:Value>


<deegree:Parameter>

<deegree:Name>layerlist</deegree:Name>

<deegree:Value>this.layerList</deegree:Value>


<deegree:Parameter>


<deegree:Value>'Urbanisme'</deegree:Value>


<deegree:Parameter>




<deegree:Parameter>

<deegree:Name>fgcolor</deegree:Name>




</deegree:Module>

</deegree:East>



<deegree:South hidden="false">

<deegree:Module hidden="false" type="content" width="300" height="20" bgcolor="#FDF5ED">

<deegree:Name>CoordinateDisplay</deegree:Name>

<deegree:Content>coordinatedisplay.html</deegree:Content>

<deegree:ModuleJS>coordinatedisplay.js</deegree:ModuleJS>


<deegree:Parameter>

<deegree:Name>digits</deegree:Name>

111



<deegree:Parameter>

<deegree:Name>labelX</deegree:Name>

<deegree:Value>'X:'</deegree:Value>


<deegree:Parameter>

<deegree:Name>labelY</deegree:Name>

<deegree:Value>'Y:'</deegree:Value>



</deegree:Module>

<deegree:Module hidden="false" type="content" width="900" height="20" bgcolor="#FDF5ED">

<deegree:Name>MenuBarBottom</deegree:Name>

<deegree:Content>menubarbottom.html</deegree:Content>

<deegree:ModuleJS>menubar.js</deegree:ModuleJS>

</deegree:Module>

</deegree:South>



<deegree:West hidden="false">

<deegree:Module hidden="false" type="content" width="200" height="150"

scrolling="no">

<deegree:Name>MapOverview</deegree:Name>

<deegree:Content>mapoverview.html</deegree:Content>

<deegree:ModuleJS>mapoverview.js</deegree:ModuleJS>

<deegree:ModuleJS>wz_jsgraphics_box.js</deegree:ModuleJS>


<deegree:Parameter>

<deegree:Name>src</deegree:Name>

<deegree:Value>'./images/tarragona.png'</deegree:Value>


<deegree:Parameter>

<deegree:Name>minx</deegree:Name>



<deegree:Parameter>

<deegree:Name>miny</deegree:Name>

112

<deegree:Parameter>

<deegree:Name>maxx</deegree:Name>



<deegree:Parameter>

<deegree:Name>maxy</deegree:Name>



<deegree:Parameter>

<deegree:Name>foregroundColor</deegree:Name>

<deegree:Value>'#E9E9E9'</deegree:Value>


<deegree:Parameter>

<deegree:Name>width</deegree:Name>



<deegree:Parameter>

<deegree:Name>height</deegree:Name>




</deegree:Module>




<deegree:Name>ScaleSwitcher</deegree:Name>

<deegree:Content>scaleswitcher.html</deegree:Content>

<deegree:ModuleJS>scaleswitcher.js</deegree:ModuleJS>


<deegree:Parameter>


<deegree:Value>'Escala:'</deegree:Value>


<deegree:Parameter>

<deegree:Name>listOfScales</deegree:Name>

113

<deegree:Value>

'1:1000;1:2500;1:5000;1:10000;1:25000;1:50000;1:100000;1:500000;1:1000000;1:5000000'

</deegree:Value>


<deegree:Parameter>

<deegree:Name>listSize</deegree:Name>



<deegree:Parameter>


<deegree:Value>'#cccccc'</deegree:Value>



</deegree:Module>


<deegree:Name>Note</deegree:Name>

<deegree:Content>note.html</deegree:Content>

<deegree:ModuleJS>dummy.js</deegree:ModuleJS>

</deegree:Module>

</deegree:West>



<deegree:Center hidden="false">

<deegree:Module hidden="false" type="toolbar" width="450" height="45">

<deegree:Name>Toolbar</deegree:Name>

<deegree:Content>toolbar.html</deegree:Content>

<deegree:ModuleJS>toolbar.js</deegree:ModuleJS>

<deegree:ModuleJS>buttongroup.js</deegree:ModuleJS>


<deegree:Parameter>

<deegree:Name>refresh|Refresca el mapa</deegree:Name>

<deegree:Value>PushButton</deegree:Value>


<deegree:Parameter>

<deegree:Name>fullextent|Zomm a tot el mapa</deegree:Name>



<deegree:Parameter>

114

<deegree:Name>movetoprevious|Torna al mapa anterior</deegree:Name>



<deegree:Parameter>

<deegree:Name>movetonext|Torna al mapa posterior</deegree:Name>



<deegree:Parameter>

<deegree:Name>zoomin|Augmenta zoom</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>


<deegree:Parameter>

<deegree:Name>zoomout|Redueix zoom</deegree:Name>







<deegree:Parameter>

<deegree:Name>featureinfo|Informació de la capa activa</deegree:Name>



<deegree:Parameter>

<deegree:Name>recenter|Centra el mapa</deegree:Name>



<deegree:Parameter>

<deegree:Name>move|Mou-te sobre el mapa</deegree:Name>



<deegree:Parameter>

<deegree:Name>addwms|Afegeix un servei WMS</deegree:Name>



<deegree:Parameter>

115

<deegree:Name>print|Imprimeix</deegree:Name>



<deegree:Parameter>


<deegree:Value>'#E9E9E9'</deegree:Value>





</deegree:Module>

<deegree:Module hidden="false" type="content" width="750" height="550"

scrolling="no">

<deegree:Name>MapView</deegree:Name>

<deegree:Content>mapview.html</deegree:Content>

<deegree:ModuleJS>mapview.js</deegree:ModuleJS>

<deegree:ModuleJS>mapcontroller.js</deegree:ModuleJS>

<deegree:ModuleJS>mapmodel.js</deegree:ModuleJS>

<deegree:ModuleJS>wmsrequestfactory.js</deegree:ModuleJS>

<deegree:ModuleJS>wmslayer.js</deegree:ModuleJS>


<deegree:Parameter>

<deegree:Name>model</deegree:Name>

<deegree:Value>this.mapModel</deegree:Value>


<deegree:Parameter>

<deegree:Name>border</deegree:Name>




</deegree:Module>

<!--

<deegree:Module hidden="false" type="content" height="550" width="550" scrolling="no">

<deegree:Name>ScaleBarSwitcher</deegree:Name>

<deegree:Content>scalebarswitcher.html</deegree:Content>

<deegree:ModuleJS>scalebarswitcher.js</deegree:ModuleJS>

116


<deegree:Parameter>

<deegree:Name>scaleBarValues</deegree:Name>

deegree:Value>'10;50;100;200;250;300;350;400;500;600;700;1000;1500'</deegree:Value>


<deegree:Parameter>

<deegree:Name>unit</deegree:Name>

<deegree:Value>'km'</deegree:Value>



</deegree:Module>

-->

</deegree:Center>

</deegree:Frontend>



<deegree:MapParameter>



<deegree:OfferedInfoFormats>

<deegree:Format>application/vnd.ogc.gml</deegree:Format>

<deegree:Format selected="true">text/html</deegree:Format>

</deegree:OfferedInfoFormats>



<deegree:OfferedZoomFactor>

<deegree:Factor selected="true">25</deegree:Factor>

</deegree:OfferedZoomFactor>



<deegree:OfferedPanFactor>

117

<deegree:Factor selected="true">15</deegree:Factor>

</deegree:OfferedPanFactor>



<deegree:MinScale>1</deegree:MinScale>



<deegree:MaxScale>100000</deegree:MaxScale>

</deegree:MapParameter>

</Extension>

</General>

<LayerList>



<Layer queryable="1" hidden="1">

<Server service="OGC:WMS" version="1.1.1" title="Geoportal">


xlink:href="http://desarrollo8:8080/deegree-wms/services?" />

</Server>

<Name>Qualificacio Urbanistica</Name>

<Title>Qualificacio Urbanistica</Title>


<FormatList>


</FormatList>

<StyleList>

<Style current="1">



</Style>

</StyleList>



</Extension>

</Layer>

<Layer queryable="1" hidden="0">


118

<Server service="OGC:WMS" version="1.1.1" title="Geoportal">


xlink:href="http://desarrollo8:8080/deegree-wms/services?" />

</Server>

<Name>Classificacio Urbanistica</Name>

<Title>Classificacio Urbanistica</Title>


<FormatList>


</FormatList>

<StyleList>

<Style current="1">



</Style>

</StyleList>



</Extension>

</Layer>

</LayerList>

</ViewContext>

Sistema d’Informació Geogràfica d’urbanisme integrat en ... · diferents sistemes similars...

Documents

Transcript of Sistema d’Informació Geogràfica d’urbanisme integrat en ... · diferents sistemes similars...