Revista Catalana de Geografia

Indexació semàntica per a les cerques al catàleg de metadades: cap a un cercador minimalista

Pascual, V. — Tue, 28 Feb 2012 00:00:00 +0100

INDEXACIÓ SEMÀNTICA PER A LES CERQUES AL CATÀLEG DE METADADES: CAP A UN CERCADOR MINIMALISTA

Víctor Pasual
Centre de Suport IDEC. Institut Cartogràfic de Catalunya

1. Introducció

Podríem definir una Infraestructura de Dades Espacials (IDE) com un conjunt de tecnologies, polítiques, estàndards, serveis i recursos humans necessaris per a la recopilació, la descripció, l'accés, la distribució i la utilització de dades geogràfiques a diferents nivells. Una IDE és una base per al descobriment de dades espacials, la seva avaluació i la seva utilització per tot tipus d'usuaris: del sector públic, empresarial, acadèmic, no governamental o ciutadans en general.

En un escenari òptim, tot usuari d'una IDE hauria de poder descobrir, per exemple, quina informació geogràfica existeix en una zona concreta del territori, visualitzar aquesta informació i finalment, si és del seu interès, descarregar-la.

Des d'un punt de vista tecnològic una IDE ha d'implementar aplicacions que permetin arribar a aquest escenari òptim. Una d'aquests aplicacions, si no la més important, és el catàleg de metadades.

La Infraestructura de Dades Espacials de Catalunya (IDEC), que fou la primera IDE creada a l'Estat espanyol l'any 2002, té com a missió promoure que les institucions d'àmbit català descriguin i comparteixen la seva informació geogràfica i que aquesta pugui ser accessible i interoperable de forma oberta i transparent pels usuaris finals.

L'any 2005, la Llei 16 d'Informació Geogràfica i de l' Institut Cartogràfic de Catalunya (ICC) atribuïa les funcions de creació, difusió, estructuració i manteniment de la Infraestructura de Dades Espacials de Catalunya a l'ICC, i dins el seu capítol cinquè, que regula la Infraestructura, crea el Centre de Suport (CS IDEC) com a aparell tècnic i òrgan bàsic de promoció, explotació i manteniment de la IDEC.

Així, doncs, és el CS IDEC l'encarregat de mantenir i impulsar el catàleg de metadades de la IDEC amb tota la informació geogràfica referent al territori català.

Catàleg de metadades

El catàleg de metadades és, segurament, la peça més important dins de qualsevol IDE i podríem definir-lo com una base de dades espacial amb funcionalitats de registre que contindria l'inventari de tota la informació geogràfica disponible en un territori concret.

Esmentar que la implementació d'un catàleg de metadades és una tasca complexa i en alguns moments feixuga. El treball consisteix bàsicament a localitzar tots els possibles productors o distribuïdors de dades geogràfiques (departaments, ens públics, empreses privades, universitats, centres de recerca...) i convèncer-los de fer un inventari de tota la seva informació per seguidament descriure-la seguint un procés estandarditzat. Això és el què anomenem "creació de metadades".

No cal dir que la creació de metadades no és una tasca fàcil i implica conèixer i descriure al detall la informació de què es disposa. En una metadada cal descriure camps com l'escala de la informació, la data de creació, les dates de les revisions, l'accessibilitat, els formats de les dades, la qualitat, la distribució i la caixa de coordenades que correspon a la informació descrita.

Aquestes metadades, expressades amb llenguatge de marques extensible¹ (XML) són codificades d'acord amb l'Oficina Internacional de Normalització (ISO)², seguint les normes ISO 19115 per als conjunts de dades i ISO19119 per als serveis relacionats amb la visualització, procés o descàrrega de les dades. Són normes molt extenses on cada organisme té la llibertat de crear els seus esquemes seguint la realitat de les seves dades. A Catalunya existeix el perfil IDEC que conté un conjunt dels apartats expressats en aquestes normes ISO i que ha estat dissenyat per a catalogar les dades que s'hi produeixen.

Al mateix temps, la càrrega de tota aquesta informació dins d'un catàleg de metadades també es fa seguint les especificacions fixades per l'Open Geoespatial Consortium (OGC)³.

L'OGC és un consorci sense ànim de lucre, creada el 1994 i integrada per més de 400 empreses, agències governamentals i universitats. És l'encarregat de crear especificacions obertes que permetin la interoperabilitat geoespacial entre sistemes heterogenis sense un esforç real per l'usuari. En altres paraules, ha de permetre que el catàleg pugui ser interrogat de forma transparent per altres catàlegs o aplicacions que segueixin aquestes mateixes especificacions.

En qualsevol IDE la interoperabilitat entre els seus components i entre altres IDE es basa en especificacions OGC.

El paper d'OGC en el món geoespacial no és tan diferent del paper del W3C⁴ pel que fa a l'estandardització de la World Wide Web.

L'especificació "OGC Catalogue Services Specification" , és l'encarregada de definir les "regles de joc" tant alhora de definir el model de dades per emmagatzemar les metadades com de definir els protocols i paràmetres per a la interrogació de les metadades.

La primera versió de l'especificació va sortir l'any 1999 amb una clara motivació per definir una especificació ateses les enormes quantitats de recursos d'informació geoespacial que s'han distribuït entre les múltiples bases de dades, emmagatzemats en molts formats i en moltes interfícies d'accés diferents (Nerbert, 1999).

En aquest context el terme "Catàleg" es descriu com un conjunt d'interfícies de serveis que donen suport a l'organització, al descobriment i a l'accés a la informació geoespacial. Els catàlegs ajuden als usuaris o a les aplicacions de programari a trobar la informació que existeix en qualsevol lloc en un entorn de computació distribuïda (Kottman, 1999) .

En l'actual versió 2.0.2 (any 2009) s'estableix com a llenguatge d'interrogació l'anomenat CSW (Catalog Service for the Web), una codificació XML que permet la interrogació tant lògica com espacial de les metadades.

Durant aquest anys l'OGC ha anat definint diversos protocols i perfils d'aplicació per a integrar la gran quantitat de catàlegs amb informació espacial existents. Vegeu taula 1.

Any	Versió	Les qüestions clau
1999	1.0	L'aplicació per als entorns d'OLEDB, CORBA i ANSI Z39.50 (ISO 23950)
2001	1.1.0
2002	1.1.1
2003	2.0.0	HTTP Protocol d'enllaç. CS-W (Catàleg de Serveis per a la Web)
2004	2.0.0	ISO19115/ISO19119 perfil de l'aplicació de CS-W 2,0
2005	2.0.1
2005	2.0.1	EbRIM (ISO / TS 15000-3) Perfil d'aplicació per al CS-W
2007	2.0.2
2009	2.0.2	OWL perfil d'aplicació per al CS-W
201?	3.0.0	OGC OpenSearch

Taula 1: Versions de les especificacions d'OGC Catàleg

Aplicacions web per a cercar metadades

Hem vist com la implementació d'un catàleg és subjecta a uns estàndards que bàsicament cerquen un nivell de comunicació màquina - màquina, la interconnexió entre catàlegs o entre terceres aplicacions especialitzades.

Però una gran part d'usuaris que cerquen informació no tenen per què conèixer aquesta manera de fer i, per tant, és indispensable que tota IDE construeixi una aplicació web, el més ràpida, usable i senzilla que permeti trobar tota la informació catalogada.

Al llarg d'aquests 10 anys de l'existència de l'IDEC, l'aplicació web per cercar les metadades ha estat la que més atenció i canvis ha experimentat dins de les aplicacions de la IDEC. Tots aquests canvis han seguit la mateixa tendència: reduir la complexitat i les opcions de cerca en el disseny de la interfície web i, exponencialment, augmentar la complexitat i el nombre de processos dins del servidor; processos sempre ocults per a l'usuari final.

Aquesta tendència a minimitzar les opcions de cerca no ha estat una evolució aïllada en el món de les IDE. Els factors clau, a nivell global, han estat les millores relacionades amb el disseny i la usabilitat web amb un compromís clar de centrar-se a respondre millor les demandes dels usuaris.

Òbviament, l'aparició de noves tècniques de programació web com AJAX (Asynchronous JavaScript And XML) i llibreries de programació web com ara jQuery⁵ o OpenLayers⁶ han afectat el disseny i el rendiment d'aplicacions web. Però, el major impacte, probablement, ha estat l'existència d'un motor de cerca com Google.

Aquest ha canviat el comportament dels usuaris alhora d'utilitzar aplicacions de cerca. Aquest impacte ha afectat a tots els nivells i dominis de les aplicacions basades en la cerca d'informació i, també, als catàlegs de metadades. Aquesta tendència ha estat anomenada "googlization" (Battelle, 2003; Salkever, 2003).

No hi ha volta enrere, Google ofereix un únic quadre de cerca, va molt ràpid i, en general, el que s'està cercant sempre apareix a la primera pàgina ben posicionat. Això no succeeix en la majoria dels motors de cerca de metadades, tot i contenir un volum molt menor d'informació i tenir una informació molt rica i ben estructurada.

Cercador de catàleg de la IDEC

A final de 2002 l'IDEC va publicar el seu primer cercador web de catàleg. Si observen la figura 1 veurem com l'usuari podia omplir fins a 18 caixes de cerca per encadenar fins a 8 opcions de cerca.

Figura 1: Cercador de catàleg IDEC. Any 2003.

Era, sens dubte, una aplicació enfocada a usuaris experts i que convidava a preguntar si existia allò concret en aquell lloc concret.

Estudis interns posteriors sobre l'ús que els usuaris finals feien del catàleg, van demostrar la poca efectivitat d'aquesta interfície de cerca. Per exemple , els usuaris experts que concatenaven més de tres opcions de cerca normalment obtenien resultats negatius.

No trobar res, en una operació de cerca lògica és, sens dubte, una experiència frustrant per a un usuari final i que cal evitar de totes les maneres.

Aquests tipus d'aplicacions web, molt esteses en la cerca de metadades, cometen - encara avui n'hi ha moltes - l'error de basar la seva interfície web amb una relació quasi d'1 a 1 amb els camps definits a la base de dades segons les especificacions d'OGC (vegeu taula 2).

Nom	Definició
Tema	El tema del contingut del recurs
Títol	Un nom que es dóna al recurs
Resum	Un resum del contingut del recurs
AnyText	Un objectiu per a la recerca de text complet dels tipus de dades de caràcters en un catàleg
Format	La manifestació física o digital del recurs
Identificador	Una referència única per al registre en el catàleg
Modificat	Data en què es va crear el registre o actualització en el catàleg
Tipus	La naturalesa o gènere del contingut del recurs. Pot incloure categories generals, gèneres o nivells d'agregació de continguts
BoundingBox	Un quadre de límit per a la identificació d'una àrea geogràfica d'interès
CRS	Sistema de referència de les coordenades geogràfiques
Associació	Declaració completa d'una relació un a un

Taula 2: Catàleg de serveis OGC elements comuns consultable

Cal, doncs, separar clarament els dictats dels estàndards alhora de catalogar les dades de les interfícies web de cerca pensades per a usuaris finals. Potser cal que en un primer moment l'usuari només es pregunti que hi ha en aquest lloc per després, mitjançant filtres, pugui anar acotant la cerca.

Un cercador de catàleg de metadades hauria de donar resposta a usuaris NO experts que no saben exactament com trobar allò que cerquen i ajudar a usuaris EXPERTS que si saben exactament el que cerquen però no ho troben. Tot això de forma usable, ràpida i fàcil.

Actualment el cercador de catàleg de la IDEC presenta només quatre opcions de cerca, per intentar donar sempre una primera resposta positiva a l'usuari.

Les quatre opcions són:

Per lloc (ON): Aquesta opció cerca sobre la base toponímica de Catalunya 1:5.000 i 1:50.000 i ofereix una llista de suggeriments mentre l'usuari està escrivint un nom de lloc. L'objectiu és obtenir les coordenades del lloc a cercar i així interrogar espacialment el catàleg. Això és possible ja que tots els catàleg de metadades tenen capacitat de cerca espacial i totes les metadades contenent, com un camp d'informació obligatori, l'àmbit espacial (caixa de coordenades) a què fan referència
Per text (QUÈ): En un primer moment, igual que en la cerca per lloc, aquesta opció oferia una llista de suggeriments a partir d'una taula indexada de termes descrits a les metadades. Aquesta opció s'ha reforçat amb l'ús de tècniques semàntiques que es descriuen en l'apartat següent.
Per organització: Aquesta opció mostra un llistat amb cada organització (proveïdor i/o distribuïdor) i el seu nombre de metadades de conjunts de dades, sèries i serveis disponibles en el catàleg. L'usuari només ha de fer un clic per accedir al proveïdor de metadades.
Per Mapa. El mapa es considera una opció de cerca també, no com abans, quan el mapa era només un "instrument" utilitzat per a obtenir les coordenades per a delimitar una cerca. Amb un únic clic al mapa o dibuixant un rectangle, es poden obtenir les metadades perquè interaccionin els seus àmbits amb les geometries dibuixades.

La figura 2 mostra una captació del cercador de metadades de la DEC. Com es pot veure, les cerques per lloc i text són a la part superior dreta, per organització a la part inferior del costat dreta i, finalment, el mapa a la banda esquerra.

Figura 2: Catàleg IDEC client web amb 4 opcions de cerca.

Val a dir que un cop feta la primer cerca, el catàleg mostra una llista de candidats. Aquesta llista pot ser refinada per l'usuari utilitzant valors com l'escala o el format de les dades.

Aquests valors de filtre tradicionalment havien format part de la primera pantalla de la cerca, però s'ha vist que el seu ús és més satisfactori com a un possible filtre que com a opció inicial de cerca.

Indexació semàntica

Un cop analitzat el comportament dels usuaris i els tipus de cerques llançades al catàleg, es va concloure que les cerques espacials i les cerques per llista tancada, com és la d'organismes, donaven resultats satisfactoris, mentre que la cerca per text, on l'usuari expressava lliurement el que volia cercar, retornava un percentatge importat de respostes negatives o errònies.

Alguns exemples clars extrets d'aquestes anàlisis seria quan l'usuari, per exemple, cercava "Inundacions" o "Pol·lució" i el catàleg retornava 0 resultats.

Efectivament no hi havia cap metadada que contingués aquesta cadena de text però sí que hi havia metadades que contenien informació sobre "Àrees inundables" o "Contaminació".

Per això, es va decidir de dotar el catàleg amb algunes capacitats semàntiques i una major complexitat en la banda del servidor. Bàsicament calia entendre millor que estava cercant l'usuari.

Les tècniques utilitzades consisteixen en crear taules indexades a partit dels principals camps d'informació de les metadades. Cada text és indexat amb el que s'anomena "stemming" o reducció de cada paraula a la seva arrel. Aquesta tècnica permet que una cerca que conté la paraula "Inundacions" retorni resultats amb el text "Inundables" ja que comparteixen la mateixa arrel.

Una altra tècnica utilitzada, i tenint en compte que els usuaris tendeixen a cercar a partir de conceptes claus, ha estat la descomposició de la cerca amb bigrames o parells de paraules i la posterior classificació dels resultats d'acord amb les vegades que apareixen en les metadades.

Així, per exemple, la cerca "contaminació riu Ter", respondria si:
Aparegués a la metadada "contaminació del riu Ter", "contaminació riu", "contaminació del Ter" o estiguessin en una mateixa metadada però en camps separats les paraules "contaminació", "riu" i "Ter".

Els primers resultats d'aplicar aquestes capacitats semàntiques han estat una millora considerable en el nombre dels resultats obtinguts. Així, per exemple, una cerca com "Zona agrícola" va passar de tenir un resultat a tenir-ne 485.

Sens dubte, no tots els 485 resultats obtinguts tenien a veure estrictament amb "Zones agrícoles", però si els més ben posicionats.

Això implica que en una futura segona fase s'incrementaran les capacitats semàntiques del catàleg afegint-hi coneixement expert que permeti classificar els conceptes a partir de famílies de sinòmins i homònims, per exemple. També s'aplicaran millores en les anomenades "facetes", que són classificacions a partir de textos similars obtinguts en els resultats i que permeten refinar les cerques temàticament.

Referències

Battelle, John (2003).The Creeping Googlization Meme.BusinessWeek Online. http://battellemedia.com/archives/000145.php. Web document.Last date accessed 12.2010.
Bernard,M (2003) .Optimal Web Design.Web document. http://uwf.edu/ddawson/d3net/documents/web_usability/optimal%20web%20design.pdf. Last date accessed 12.2010.
Bernard J. Jansen a,*, Amanda Spink(2005).How are we searching the World Wide Web? A comparison of nine search engine transaction logs. Web document.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.4299&rep=rep1&type=pdf. Last date accessed 01.2011.
ISO, 2003. Geographic information - Metadata. ISO 19115:2003, International Organization for Standardization (ISO).
Kottman, C., 1999. The OpenGIS Abstract Specification. Topic13: Catalog Services (version 4). OpenGIS Project Document 99-113, OpenGIS Consortium Inc.
Martell, R (2005)OpenGIS Catalogue Services - ebRIM (ISO/TS 15000-3) profile of CSW. OpenGIS Project Document 05025r3, OpenGeoSpatial Consortium Inc.
Nebert, D., 2002. OpenGIS Catalog Services Specification, Version 1.1.1. OpenGIS project document 02-087r3, Open GIS Consortium Inc.
Nebert, D., 2004. OpenGIS - Catalogue Services Specification (version: 2.0). OpenGIS Project Document 04-021, Open GIS Consortium Inc.
Nebert, D.,Whiteside,A., Vretanos,P. 2007. OpenGIS - Catalogue Services Specification (version: 2.0.2). OpenGIS Project Document 07-006r1, OpenGeoSpatial Consortium Inc.
Nebert, D.,Whiteside,A,. 2005. OpenGIS - Catalogue Services Specification (version: 2.0.1).OpenGIS Project Document 04-021r3, OpenGeoSpatial Consortium Inc.
Nebert, D. (2004). Developing Spatial Data Infrastructures: The SDI Cookbook. Web document. http://www.gsdi.org/docs2004/Cookbook/cookbookV2.0.pdf. Last date accessed 12.2010.
Salkever A. (2003). Google Here, There, and Everywhere BusinessWeek Online. http://www.businessweek.com/technology/content/dec2003/tc20031216_9018_tc047.htm. Web document.Last date accessed 12.2010.

Notes

1. eXtensible Markup Language. Web: http://www.w3.org/XML
2. International Standards Office.web: http://www.iso.org
3. Open GeoSpatial Cosortium. Web: http://www.opengeospatial.org/
4. W3C. Web: http://www.w3.org
5. Jquery.web: http://jquery.com/
6. OpenLayers.web: http://openlayers.org

Cap a les infraestructures de recursos de geoinformació

Guimet, J. — Tue, 31 Jan 2012 00:00:00 +0100

CAP A LES INFRAESTRUCTURE DE RECURSOS DE GEOINFORMACIÓ

Jordi Guimet
Centre de Suport IDEC. Institut Cartogràfic de Catalunya

1. Introducció

Fins ara el procès seguit en el desenvolupament de la Infraestructura és el que s'ha anat aplicant arreu: a partir de la consideració de les utilitats potencials de compartir dades a través d'Internet s'han promogut iniciatives orientades a que els diversos proveïdors de geoinformació facilitessin l'accessibilitat de les seves dades tots els interessats, el que inclou l'inventari i catalogació dels recursos, eines per a publicitar-los i cercar-los així com eines per a utilitzar-los.

En aquest procès s'ha incidit fortament en aquest objectiu, confonent-lo amb la finalitat del mateix, que no és més que fer ús de la plataforma Interent per a connectar i fer utilitzables en estructura distribuïda els recursos d'informació existents en multiplicitat d'organismes públics i privats. El que vol dir que l'èmfasi s'ha situat, i encara està, en l'aprovisionament dels recursos, i no tant en la seva utilització, amb les mancances d'efectivitat que això comporta.

Es clar que previ a la utilització és la disponibilitatde la infraestructura, però, possiblement per manca de models de referència clars, la primera fase exhaureix, fins ara, les activitats dels centres impulsors de les IDE, que s'han vingut preocupant de dotar-es de fonts de dades, catalegs, visualitzadors, etc., però d'alguna manera descuidant o deixant de banda els efectes d'aquesta disponibilitat, els seus beneficis obtenibles en la plena utilització dels recursos.

Cal una aposta decidida i estratègica ara per a fer possible aquest nivell de complitud en la utilització dels recursos.

2. Evolució i situació actual de la IDEC

Els gràfics següents expressen l'evolució de diversos actius de la IDEC [1]:


Figura 1.- Gràfic d'evolució nº total de metadades de datos.	Figura 2.- Gràfic d’evolució de metadades de serveis.


Figura 3.- Gràfic d'evolució del nombre de proveïodors de metadades de serveis.	Figura 4.- Gràfic d'evolució del nombre de proveïodors de metadades de dades.

Figura 5.- Gràfic d'evolució del nombre de geoserveis.

Arribats a finals del 2010, amb els actius i els resultats que s'han anat exposant i havent reflexionant durant aquest any sobre l'estratègia a seguir pels propers anys respecte al desenvolupament de la infraestructura i especialment a la seva utilització, es conclouen les següents reflexions.

3. Diagnosi de la situación actual

a) Hem arribat a la maduresa. Tenim una massa crítica, com ho indica el fet de que l' interès dels proveïdors ha augmentat:
a. Volen aparèixer en el Catàleg de Metadades
b. S'interessen per l'actualització de les seves metadades
c. Tenen interès en millorar la qualitat de les seves metadades i els seus serveis
Tenim una bona base per a pensar en el futur, allargar el cicle de vida mitjançant la innovació, que implica processos d'adaptació a un entorn més exigent i canviant.
b) Es disposa d'uns importants recursos de geoinformació, distribuits en la xarxa
c) Aquests recursos son encara poc utilitzats i poc coneguts, al menys respecte al que es podria considerar com a nivell adequat
d) Es necessari desplaçar l'èmfasi sobre els recursos cap a una orientació als usos finalistes dels mateixos
e) Com afirmen alguns experts [2], cal considerar la Web com una plataforma i implementar una xarxa de serveis distribuits interoperables, com si es tractés d'un magatzem on la gent posa i comparteix o ven aplicacions, i on l'usuari pugui obtenir aquestes aplicacions, a més de les dades, i utilitzar-les immediatament. No es tracta doncs de proveir dades solament, sinó proveir serveis i aplicacions amb aquestes dades, creant un entorn que pugui ser fàcilment i dinàmicament programat per a suportar aplicacions. Evidentment, orientat a professionals i empreses SIG, que seran els encarregats de traduïr i adaptar els recursos, per a generar aplicacions d'usuari final. No es descarta, però, que algunes de les funcionalitats de la plataforma pugui ser utilitzada directament pels usuaris finals.
El rol de les IDE està canviant [3], han de convertir-se en plataformes per donar suport a l'encadenament de serveis entre les organitzacions participants, unint serveis i informació entre organitzacions i jurisdiccions. Aquesta plataforma ha de fer disponibles eines, aplicacions i informacions. I cal tenir en compte que cada vegada és meu freqüent que els usuaris d'una IDE no siguin professionals sino usuaris finals als que, en alguns casos, seria convenient facilitar algun tipus de coneixement específic per a que puguin extreure'n més utilitats dels recursos existents.

En definitiva, cal oferir dades juntament amb serveis i aplicacions que les facin immediatament i fàcilment utilitzables pels usuaris.

4. El procés de canvi: de l'acumulació de recursos a la seva utilització

Diversos autors i estudiosos del novedós tema de les IDE han aportat els seus punts de vista i consideracions sobre l'evolució de les IDE, essencialment considerant-les com entorn fonamentalment assimilat a les TIC, i subjecte, per tant, a un cicle de vida similar al que presenten les TIC a les organitzacions. Amb això han elaborat un discurs en el que es defineix diverses fases o estadis de desenvolupament: iniciativa solitaria, intercanvi i estandardització, intermig i xarxa. El nivel de col·laboració en aquest model es progressiu, sent la fase de "xarxa" quan es dòna la participació activa i col·laboració entre participants. També s'ha fet moltes referències a la construcción de les IDE seguint models "top-bottom" i "bottom - top", essent més freqüents els primers i el models hybrids. I és pales que el model top-down porta implícita una visió jerárquica que amb tota seguretat no recull actualment les aspiracions dels potencials beneficiaris de les infraestructures en el seu sentit més ampli i li merma les capacitats d'innovació i expansió que d'altra manera es podría aconseguir, al trobar en la mera acumulació de dades la justificació de la seva finalitat. I és clar que, com a infrastructura, aquesta disponibilitat de dades és condició necessària, però no suficient per a garantir-ne una utilització massiva, económica i eficaç dels recursos i les inversions que els han fet possibles. [4]
Es evident, tot i que s'esmenta molt poc per part dels experts, que una IDE requereix o comporta implícitament la participación de molts agents, que serán inicialment els que conformaran els diversos nusos de la xarxa en què consisteix una IDE, a la que s'aniran afegint progressivament nous participants. I per tant és fa difícil asimilar o projectar models aplicats al desenvolupament i cicle de vida de projectes tradicionals TIC, en qué el lideratge i la participación son únics, els de l'organisme que el duu a terme, a la construcción, desenvolupament i utilització de les IDE's. Per definició una IDE implica participació, diversitat, multiplicitat, xarxa... I per tant no s'hauria de qualificar com a IDE els estadis inicials qualificats com a "iniciativa solitària", puig no es fins que convergeixen varies iniciatives i acorden de participar en una xarxa comuna que no apareix pròpiament una IDE.
Per altra banda també ès pot afirmar que pràcticament totes les iniciatives IDE han sorgit en la propia administración pública o amb el seu suport. El que ha donat lloc a que moltes IDE's, endegades pels poders públics, aplicant un model "top-down", hagin quedat com a projectes o iniciatives molt limitades a uns quants organismes públics. El model IDEC partí del suport públic però decididament obert a totes les administracions, entitats públics i privades, universitats, empreses i els mateixos ciutadans. Probablement per aquesta raò d'origen presenta unes particularitats en quant a nombre de participants i actius de geoinformació accessibles dificils de trobar en altres IDE's, situació que li permet afrontar ara un repte important, donant resposta a les demandes, actuals i futures, dels usuaris, amb una oferta més que notable de dades, serveis i, en el futur i d'acord amb el que s'assenyala en el present document, aplicacions.
Aquests reflexions, més les que ja s'han presentat en anterior apartat, ens porten a la ratificació del canvi necessari per a la IDEC, entrant en una fase clarament orientada a potenciar la utilització massiva dels recursos que ha generat.

5. Els orígens. Història de l'evolució cap a la Plataforma de Recursos de Geoinformació

Té l'origen en la IDE temàtica Local, amb la intenció de dotar els ens locals amb unes eines fàcils d'utilitzar, intuitives, interessants i participatives (per exemple, per a creació d'informació pròpia) i personalitzables (els serveis s'ofereixen com a « marca blanca »), adaptables al seu respectiu entorn corporatiu, i orientats a donar servei tant a les estructures administratives locals com als ciutadans que acceideixen a les webs municipals.

Poc a poc altre entitats van interessar-se en les aplicacions i en les solucions que s'anaven oferint, el que va incrementar la demanda i diversitat de les mateixes. Així es complementà les aplicacions amb una funcionalitat de tematizació de dades, es dissenyaren nous visualitzadors més en la línia actual, oferint-se varies bases de referència (fondos cartogràfics) i altres mesures de millora del comportament dels serveis.

El nombre creixent d'usuaris i el d'aplicacions va obligar a crear un Centre de Recursos, amb un entorn d'administració, BdDades, etc., el que anà conformant el que venim a anomenar actualment com a Plataforma de Recursos. Actualment s'està treballant en altres incorporacions, com ara eines per a la creació de Atlas temàtics, tracking de vehicles, així com ampliació de les utilitats dels visualitzadors amb la representació 3D, routing i altres.

Què és la Plataforma de Recursos:
La PRG és un entorn web d'aplicacions, on, amb totals garanties de seguretat les administracions públiques podrán:
- Accedir a totes les dades geogràfiques i metadades disponibles a la xarxa IDEC
- Disposar d'eines simples i intuïtives per a la creació i personalització d'aplicacions
- Aprofitar aplicacions i serveis preparades per a ser adaptades a les necessitats de l'usuari

Components:
- Una base cartogràfica de referència (ortofotos, topogràfic, rondaire, toponímia..), distribuïda i accessible en Internet a través de WMS estàndard.
- Metadades per a descobrir dades i serveis
- Cartografia i geoinformación temática
- Aplicacions i serveis transversals, reusables i compartibles (p.e. per a editar, personalitzar recursos, actualitzar BdDatos distribuïdes, guardar informació)

L'estratègia, en aquesta línia, ha de ser la d'anar creixent en nombre d'aplicacions que es poden trobar en la Plataforma i en la simplificació dels processos de personalització als diferents entorns d'usuari.

Plataforma de Governança: projectes cooperatius
Pot ser una plataforma de govern (en l'ambit de la gestió del territori) on es trobessin, fonamentalment, les diverses administracions i els seus diversos nivells competencials, axí com les universitats, les empreses i, perquè no, els ciutadans. Interaccionant tots ells, ja que tots poden afegir valor públic.

6. Noves estratègies

Es basaran en uns quants punts de referència :
• De l'acumulació de recursos a la seva difusió i utilització.
• La Plataforma de Recursos de Geoinformación, com a origen i motor del canvi, millorant accessibilitat, el nombre d'aplicacions, integració de nous recursos (Sensors, imatges), amb vocació de plataforma de governança.
• Noves IDE's temàtiques i nous Geoportals (WebSensors, imatges, fotos aèries, geología, cartografia oficial, entre d'altres).
• Integració de nous recursos de Crowdsourcing i Tecnologies participatives.
• Nous tipus de recursos: models de dades, estils...
• Del concepte de Plataforma al concepte d'Infrastructura.

En definitiva, ampliant el concepte, utilitats i àmbit de la Plataforma, dirigir-nos cap al concepte més ampli d'Infrastructra, introduint noves missions, visions, objectius, activitats....evitant el creixement pla o el col·lapse, a través de la innovació.

Infrastructura de Recursos de Geoinformació:
Dades, Serveis, Aplicacions, Imatges, Dades de Sensors, Plataformes col·laboratives, models, fotos...

Referencias
[1] Memòries 2002-2010 CS IDEC.
[2] Jack Dangermond (2010), Revista GEOInformatics, Entrevista, Febrer 2010.
[3] Abbas Rajabifard (2008).
[4] Kok, B., and van Loenen,B., 2005, How to assess the success of National Spatial Data Infrastructures? in: Computers, Environment and Urban p.700, 702, 703, 704,709.

Propuesta de modelo de callejero: Un primer paso en la interoperabilidad de los modelos de direcciones y de transportes

Thu, 02 Feb 2012 00:00:00 +0100

PROPUESTA DE MODELO DE CALLEJERO: UN PRIMER PASO EN LA INTEROPERABILIDAD DE LOS MODELOS DE DIRECCIONES Y DE TRANSPORTES

Alicia González, José Miguel Rubio, Ana Velasco, Julián González, Paloma Verdejo, Ángel García, Sebastián Mas
Instituto Geográfico Nacional. Centro de Informacion Geográfico

1. Introducción

Todos los países miembros de la Unión Europea deben implementar las Normas de Ejecución de los temas recogidos en el anexo I de la Directiva INSPIRE[1] durante los próximos años (hasta 2012 si se trata de datos nuevos y 2017 si se trata de datos ya existentes) de modo que sus modelos de datos y esquemas de aplicación satisfagan los requisitos exigidos en dicha normativa europea.

Dentro de los temas del anexo I se encuentran los temas de Direcciones y de redes de Transportes entre los que existen determinadas relaciones que deben tenerse en consideración a la hora de elaborar la metodología a aplicar durante las respectivas implementaciones de modo que se garantice la interoperabilidad entre los modelos de datos que se definan.

Desde un punto de vista gráfico, parece lógico pensar que el nexo de unión entre ambas temáticas se defina a través de un escalón intermedio: un modelo de red viaria al que vincular las direcciones y, a la vez, sobre el que planificar la red de transporte por carretera, en definitiva un modelo de callejero.

En relación a estas materias, el Instituto Geográfico Nacional (IGN) desarrolla el proyecto CartoCiudad[2] desde 2006 en el que, por un lado, se integra toda la información oficial que compone las direcciones a través de los datos facilitados por el Instituto Nacional de Estadística (INE), la Sociedad Estatal de Correos y Telégrafos(Correos) y la Dirección General del Catastro (DGC), y por otro la asocia a un entramado viario de ejes que discurren por ámbitos urbano e interurbano (a partir de datos del propio IGN), abarcando todo el territorio nacional. El resultado de esta integración de datos permite que se puedan desarrollar aplicaciones que realizan operaciones complejas más propias de un modelo de transportes como son el cálculo de rutas entre dos puntos definidos por sus direcciones postales o de áreas de influencia respecto de una localización concreta.

El objetivo de este documento es proponer, a nivel conceptual, un modelo inicial de callejero que facilite la interoperabilidad entre ambos temas.

2. CartoCiudad: propuesta de modelo de callejero como punto de partida

2.1 ¿Por qué el modelo de CartoCiudad?

Dada la alta difusión y aceptación que actualmente tiene el modelo de callejero de CartoCiudad entre los usuarios y organismos, especialmente porque en gran medida la producción y, sobre todo, la actualización de los datos se realizan en colaboración con varias comunidades autónomas (País Vasco, Navarra, C. Valenciana, Baleares, Murcia, La Rioja, Andalucía), desde el IGN se propone este modelo como punto de partida para la elaboración del modelo de callejero que facilite la conexión e interoperabilidad entre los temas de direcciones y de redes de transporte.

2.2 Síntesis del modelo de CartoCiudad

El modelo de CartoCiudad es un modelo de red viaria que discurre por todos los núcleos y ciudades de España sobre un fondo urbano de origen catastral al que adicionalmente se le han vinculado datos de carácter postal y censal. Por tanto, desde un punto de vista esquemático la tipología de datos que se integra en este proyecto se pueden sintetizar en:
· Red viaria
· Unidades Administrativas
· Información postal (códigos postales)
· Información Censal (secciones y distritos censales)
· Fondo cartográfico en zonas urbanas de origen catastral

Figura 1. Modelo de datos de CartoCiudad.

Considerando el objetivo en que se quiere emplear este modelo (como punto de partida en el nexo de unión entre los modelos de direcciones y transportes), habría que limitar su contenido a los fenómenos propios de ambos temas es decir, los correspondientes a unidades administrativas, red viaria e información postal.

Figura 2. Modelo de datos de partida (basado en CartoCiudad) para la definición del modelo de callejero.

A partir de este modelo básico inicial, el siguiente paso consistirá en analizar el modo en el que aparecen integrados los fenómenos característicos de direcciones y de redes de transporte por carretera en este esquema inicial, y su compatibilidad con los modelos facilitados en las Normas de Ejecución correspondientes de la Directiva INSPIRE.

3. Análisis de la documentación de referencia en relación con el tema de direcciones

3.1 Norma de Ejecución de INSPIRE sobre direcciones

La Norma de Ejecución del tema de direcciones[3] (y sus correspondientes "Technical Guidelines"[4]) describe una dirección como una entidad con existencia propia que siempre debe tener un localizador (numérico y/o textual) y debe estar georreferenciada a partir de un par de coordenadas. Esta entidad se configura a partir de una serie de componentes que guardan una relación espacial relativamente jerárquica entre ellos y cabe la posibilidad de que se definan direcciones en las que no se consideren todos ellos. Los componentes de dirección son los que se muestran a continuación y las características que se contemplan de ellos son únicamente alfanuméricas (no se consideran las geometrías):
· Nombres de unidades administrativas (AdminUnitName)
· Nombres de unidades territoriales inferiores al municipio, en el caso de España (AddressAreaName)
· Códigos postales (PostalDescriptor)
· Nombres de vías (ThoroughfareName)

Si comparamos desde un punto de vista conceptual el modelo de CartoCiudad y el de la norma europea, analizando el grado de cumplimiento de los requisitos obligatorios que exige INSPIRE y la equivalencia entre componentes de dirección, obtenemos los
siguientes resultados:

Requisitos obligatorios:

CartoCiudad	NE INSPIRE-Direcciones	OK
CartoCiudad contiene en las zona urbanas todos los portales facilitados por la DGC y por los organismos responsables de su recopilación en Navarra (Archivo de Riqueza Territorial) y en País Vasco (EUSTAT), y los puntos kilométricos (Pk) de las vías interurbanas.	Toda dirección debe tener al menos un localizador o elemento intrínseco en la dirección que la define con el mayor grado posible sobre el terreno y al que estarán referidas las coordenadas 2D (bloque, portal, punto kilométrico, etc.).	ok
Ambos tipos de localizadores (portales/Pk)están georreferenciados y vinculados a la red viaria.	Toda dirección debe estar georreferenciada.	ok
Todos los portales/Pk están relacionados con las unidades administrativas de España (CCAA, provincia, municipio).	Toda dirección debe estar definida como mínimo por una unidad administrativa, al menos a nivel de país.	ok

Tabla 1: Comparación de los modelos de CartoCiudad y NE INSPIRE-Direcciones.

Es decir, en el modelo de CartoCiudad todas las direcciones que se recogen se definen a partir de las unidades administrativas a las que pertenece y contienen siempre un localizador (portal o Pk) con coordenadas; sin embargo, el modelo no contempla todos los tipos de localizadores posibles (bloque, entrada, nombre de edificio, etc.) que pueden definir una dirección en España.

Comparación de componentes de dirección:

CartoCiudad

NE INSPIRE-Direcciones

Unidades administrativas
Descripción alfanumèrica
Descripción geomètrica

Red viària (viales)
Descripción alfanumèrica (viales)
Descripción geomètrica

Códigos postales
Descripción alfanumèrica
Descripción geomètrica

Nombres de Unidades administrativas

Nombres de vías

Códigos postales (alfanumèrico)

Nombres de Uni. inferiores municipio

Figura 2. Comparación de componentes de dirección entre CartoCiudad y las NE INSPIRE-Direcciones.

En cuanto a los componentes de dirección, CartoCiudad contiene las unidades administrativas, los viales y los códigos postales con la descripción alfanumérica exigida en INSPIRE y adicionalmente también con su definición geométrica. Sin embargo, el modelo no contempla la relación alfanumérica de las unidades inferiores al municipio como son las entidades colectivas, singulares y los núcleos de población¹ con el resto de fenómenos.

Para completar el modelo de CartoCiudad en lo referente al tema de direcciones de modo que se contemplen todos los tipos de direcciones que INSPIRE recoge, una posible solución podría ser la de la integración del modelo de direcciones de la Administración General del Estado (AGE) sobre el modelo de partida de callejero basado en el de CartoCiudad.

3.2 Modelo de Direcciones de la Administración General del Estado (MDAGE)

Desde la Administración General del Estado, a través de la colaboración de INE, la DGC, la Agencia Estatal de Administración Tributaria (AEAT), Correos y el IGN se ha llevado a cabo la iniciativa de desarrollar un modelo de direcciones georreferenciadas que permita el intercambio efectivo de información entre las Administraciones Públicas interesadas y cuya meta es conseguir una correcta e inequívoca definición de las direcciones de los inmuebles a nivel nacional. El resultado contempla la evolución del modelo clásico de direcciones empleado hasta ahora dentro de la AGE y su adaptación a los requisitos de la Norma de Ejecución de INSPIRE sobre direcciones.

Desde un punto de vista conceptual, en la última versión finalizada recientemente, este modelo contempla los siguientes fenómenos:

Figura 3. Modelo conceptual de direcciones propuesto por la AGE.

Por tanto, integrando estos fenómenos en el modelo de callejero inicial se obtendría

Figura 4. Propuesta de modelo conceptual de callejero tras la integración del MDAGE.

4. Análisis de la documentación de referencia en relación con el tema de redes de transportes

4.1 Norma de Ejecución de INSPIRE sobre redes de transportes

En las Normas de Ejecución se establece una conexión directa entre el tema de direcciones y el de redes de transporte en la sección de redes por carretera: los nombres de las vías que se contemplen en el modelo de direcciones deberán ser los que posteriormente se asignen a las geometrías que definan la red.

El esquema de aplicación correspondiente a redes por carretera recogido en las correspondientes "Technical Guidelines"[5] exige que exista una geometría lineal para la definición de los ejes a la que se le vincularán los nombres de vías recogidos en el tema de direcciones, siendo opcional que se provean los nodos. En cuanto a la segmentación, permite tanto la clásica (cuando varían los atributos del eje se debe crear un nodo y un segmento nuevo) como la dinámica.

Teniendo en cuenta estos requisitos, el modelo de red viaria de CartoCiudad podría ser utilizado como un punto de partida sobre el que implementar el esquema de transportes por carretera de INSPIRE dado que:

considera las vías urbanas e interurbanas y las define a través de geometrías lineales (a partir de un eje central de la vía o uno por cada carril según el tipo de vía).
vincula los nombres de las vías que se emplean en el tema de direcciones a dichos ejes garantizando así la conexión obligatoria entre ambos temas establecida en las Normas de Ejecución.
tramifica los ejes de las vías en función de cómo cambien los atributos de la vía (por ejemplo, acceso libre o de peaje; estado físico en uso, en construcción, abandonado; situación en superficie, túnel, puente, en vado; etc.).

4.2 Especificaciones de la Base Cartográfica Numérica (BTA)

Las especificaciones de la Base Topográfica Armonizada (BTA) fueron acordadas en la Comisión Especializada de Normas Geográficas del Consejo Superior Geográfico[6] y en ellas se establece que dicha base cartográfica "estará compuesta por un conjunto de datos vectoriales de carácter topográfico, formado mediante la armonización de las bases topográficas a escala 1/5.000 y 1/10.000 producidas por las CC.AA y las DD.FF., que cubre todo el territorio español".

Por tanto, a la hora de definir el modelo de callejero sería también interesante analizar el grado de compatibilidad del modelo CartoCiudad con el de BTA en cuanto a los fenómenos relativos a callejero se refiere.

Los elementos que considera BTA en cuanto a redes de transporte son: Camino, Carretera (de calzada única y doble), Carril bici, Senda, Transporte suspendido por cable, Vía pecuaria, Vía urbana, Vía férrea, Punto kilométrico de carretera y Punto kilométrico de ferrocarril. Todos ellos están contemplados en el modelo de datos de CartoCiudad, a excepción de la Vía pecuaria y el Transporte suspendido por cable. El ferrocarril se incluye en CartoCiudad únicamente como línea auxiliar sin topología que completa el fondo cartográfico pero no está incorporado al grafo viario pues realmente no se trata de un fenómeno de red de carreteras; por este mismo motivo no es necesario incluirlo para garantizar la interoperabilidad con el tema de direcciones.

Aunque BTA recoge algún atributo más que CartoCiudad de los fenómenos de red viaria, los principales son comunes: identificador, nombre, situación (si está elevado, en superficie, etc.), competencia de la vía, categoría de las carreteras, estado (si está en uso o abandonada).

En cuanto al tipo de geometría de las vías, en ambos casos se registra el eje como elemento lineal (dos ejes si la calzada está desdoblada); en BTA además se recoge el borde de la vía. En BTA también se capturan las carreteras, caminos y vías pecuarias como elementos superficiales. Al igual que ocurría con el fenómeno de ferrocarril, la geometría superficial tampoco es necesaria para garantizar la interoperabilidad con direcciones.

BTA

CartoCiudad

Camino
Carretera
Carril bici
Senda
Transporte suspendido por cable
Vía pecuaria
Vía urbana
Vía férrea
PK carretera
PK ferrocarril

Camino
Carretera
Carril bici
Senda

Calle, Avenida, etc.
Sólo como referencia
PK

Tabla 2: Tabla resumen de fenómenos.

Por tanto, se puede concluir que los modelos de CartoCiudad y BTA son altamente compatibles en relación a las entidades características de un callejero.

5. Conclusiones

Para garantizar la interoperabilidad durante el proceso de implementación de las Normas de Ejecución de INSPIRE relativas al tema de direcciones y de redes de transporte, parece necesario definir un modelo de callejero que sirva de nexo de unión entre ambas temáticas.

Dada la alta aceptación y difusión del modelo de callejero definido en el proyecto CartoCiudad, el IGN como responsable de dicho proyecto y dada su experiencia y participación en iniciativas de modelado de direcciones (NE INSPIRE-Direcciones, MDAGE) considera que dicho modelo puede ser considerado como un modelo de callejero de partida sobre el que comenzar los trabajos que garanticen la interoperabilidad entre las temáticas de direcciones y redes de transporte por carretera.

Para la integración correcta de los fenómenos propios del tema de direcciones en el modelo de callejero y su cumplimiento con las exigencias de la Directiva INSPIRE, podría considerarse la iniciativa del modelo de direcciones desarrollado recientemente dentro de la AGE. Lo mismo ocurriría con la BTA para el tema de transportes por carretera.

Disponer de un modelo de callejero que garantice la interoperabilidad entre los temas de direcciones y redes de transporte y que, tras el consenso con todas las Administraciones Públicas (AAPP), sea implementado a nivel nacional aporta otros beneficios adicionales realmente importantes como son:

Fiabilidad de la información para la obtención de direcciones y de cálculo de rutas entre dos o más puntos.
Aprovechamiento de los recursos de las AAPP: se genera sólo una vez y se mantiene de forma coordinada.
Adaptación a la Directiva Europea y cumplimiento de la Ley de Infraestructuras y Servicios de Información Geográfica en España LISIGE, aportando un valor añadido.

Notas
1. Recientemente en el proyecto CartoCiudad se han incluido las entidades de núcleo de población con geometría poligonal procedentes del proyecto desarrollado por el IGN "Base de Datos de Entidades de Población (BDEP)", de modo que la relación espacial con portales sí estaría garantizada.

Referencias

[1] DIRECTIVE 2007/2/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:108:0001:0014:ES:PDF
[2] Proyecto CartoCiudad: Especificaciones del proyecto v.10 (2011) Instituto Geográfico Nacional. www.cartociudad.es
http://www.cartociudad.es/portal/pdf/CARTOCIUDAD_Especificaciones.pdf
[3] COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and service
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:323:0011:0102:EN:PDF
[4] INSPIRE Data Specifications on Addresses - Guidelines v 3.0.1 03.05.2010 http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.1.pdf
[5] INSPIRE Data Specification on Transport Networks - Guidelines v 3.1 03.05.2010
http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_TN_v3.1.pdf
[6] Comisión Especializada de Normas Geográficas (Consejo Superior Geográfico)
http://www.csg-cnc.es/web/cnccontent/bta.html

Del visor cartogràfic a l'atles, o com activar la geoinformació i la participació responsable a l'aula

Vinyoli, J. — Wed, 01 Feb 2012 00:00:00 +0100

DEL VISOR CARTOGRÀFIC A L'ATLES, O COM ACTIVAR LA GEOINFORMACIÓ I LA PARTICIPACIÓ RESPONSABLE A L'AULA

Joan Vinyoli

Començant

Quan en motiu del fòrum TIG-SIG del 2007 vaig tenir ocasió de realitzar la ponència "Les TIG a l'ensenyament secundari: anàlisi de la contribució dels recursos i arquitectura IDE" on posava de relleu que l'assignatura pendent en l'educació secundària, en l'àmbit de l'estudi i didàctica de la Geografia, és la incorporació de les tecnologies d'aplicació sobre la IG, sense preveure-ho vaig assentar les bases d'un perfil didàctic aplicable que m'oferiria uns resultats manifestament interessants. En aquesta ponència mantinc també com, les possibilitats que ofereixen les IDE per a utilitzar la IG de manera interactiva, senzilla i estimulant per als estudiants, obren possibilitats encara inexplorades però de molt interès. Els tres pilars de la bastida són el territori, les tecnologies TIG i els recursos humans.

El territori és el fonamental

Un territori que és l'espai que acull i en què en el seu interior s'hi donen els elements de la vida natural i antròpica, així com també una disposició geogràfica dels diversos elements físics i biològics i, aixímateix, on està ubicat el patrimoni arquitectònic i històric, com també on es desenvolupa la vida social i l'activitat humana que és la base de l'estructura socioeconòmica. La plataforma sobre la qual hi ha el passat, el present i el futur de la comunitat que hi viu i que és l'àrea per on els alumnes "funcionen" quotidianament i de referència diària, que es pot circumscriure al municipi o, depenent de la mobilitat, a la Comarca. Hi ha també un territori de referència a una escala de país
Un territori on els mateixos alumnes evidencien una permanent paradoxa a la que està sotmès en les actuals dècades, com a víctima de la globalització i la banalitat: mentre que, per una part és "el subjecte" sobre el qual s'han gestat, a part de les productives, una gran diversitat d'activitats humanes per l'altra, en canvi, mai se l'hi ha atribuït el protagonisme que mereix.

Pel que fa a les tecnologies TIG, dir que per la seva usabilitat, els geoserveis web arrel de la popularització i la "geo-cultura" que ha creat Google, ha comportat que usuaris allunyats del medi professional SIG, estiguin descobrint noves possibilitats. Sobre aquest entorn (Google) és notòria la diversitat d'activitats didàctiques, no obstant, i com comentaré més endavant, altres geoserveis web amb patent catalana s'adeqüen millor a una exigència més versàtil i a una futurible IDE local específica de l'àmbit d'ensenyament secundari. Tampoc preveia que seria aquesta la TIG que millor basculació i transversalitat oferiria a l'aula.

La tecnologia GPS representa una cartografia a temps real que permet la interacció ràpida entre l'alumne, la cartografia i el territori i que tan sols per l'elevada presència en el mon científic, professional i lúdic s'argumenta la seva implementació a l'aula.

I els SIG com eina vertical generadora de decisions que ha permès a persones i organitzacions, per una banda resoldre problemes i conflictes utilitzant informació provinent d'un rang ampli de disciplines com la demografia, la geologia, ecologia, ...

En definitiva, les eines TIG, com a noves tecnologies aplicades a la Ciència Geogràfica, estan possibilitant que les persones, i en aquest cas els alumnes adoptessin un rol d'actors i espectadors actius la qual cosa revertirà, d'una forma transversal, en un augment del coneixement aplicat, de la pròpia ciència i al desenvolupament de moltes de les seves subdisciplines.

Fins ara les bases. A partir d'aquí em calia trobar un espai (en quina assignatura/objectius ?) i un perfil d'alumnes que la seva franja d'edat/formació els hi permetés assimilar la dificultat dels processos.

Els projectes

Quan arrel del treball de recerca (crèdit obligatori pels estudiants de 2n curs de batxillerat) realitzat el 2009 per les alumnes de l'Institut Miquel Bosch i Jover d'Artés, Alba Carol i Judit Barea amb la tutorització de la seva professora de llengua catalana, varem compartir la idea d'aportar-hi una opció d'ús que, de manera molt simple i intuïtiva, el posés a l'abast de la població i a altres persones interessades i es materialitzés en una solució pràctica. Així el resultat final d'aquest laboriós treball, fruit de molta dedicació per part de les alumnes, es va transportar al visor cartogràfic amb la clara intenció de difondre'n el llegat de l'exhaustiu procés de recerca i posterior sistematització de les dades, basat en els objectius del treball, i que les alumnes van establir en: ampliar coneixements sobre el seu poble, elaborar una recopilació dels motius actuals del terme municipal d'Avinyó, classificar gramaticalment i semànticament els noms de les cases, treballar especifica i individualment cada motiu i finalment aprofitar la feina realitzada per aplicar-la i publicar-la en els nous recursos virtuals com és una Infraestructura de Dades Espacials. Recopilar etimologia i altra informació de més de 300 cases del nucli urbà i de l'entorn rural, amb fitxa inclosa sobre el seu estat i altres dades i, sota una direcció acadèmica, és un producte que el mateix Ajuntament d'Avinyó ha volgut divulgar.

Durant el curs 2008-09 amb els alumnes de 4t d'ESO del mateix Institut Miquel Bosch i Jover d'Artés, i en el crèdit de projecte de recerca, d'una hora de dedicació setmanal, desenvolupem un projecte ARIE compartit amb la UAB i el CREAF. En aquest queda formulat el com i de quina manera una eina SIG (en aquest cas MIRAMON) pot constituir un element instrumental estratègic per a potenciar un més precís coneixement del país i interpretació del territori en els alumnes. En resultà ser la 1a experiència a Catalunya en l'àmbit de l'ensenyament secundari i les bases d'observació i d'implementació amb Miramon van ser:

1. Usos del sòl Estudi de l'evolució dels usos del sol al municipi: Cobertes vegetals Inventari i geolocalització de la vegetació més representativa o singular del municipi.
2.Les fonts i els brolladors: Localització en GPS de les conduccions d'aigua i el seu ús en l'agricultura tradicional.
3. Elements de l'arquitectura popular i tradicional
a) Localització en el territori dels sistemes de construccions arquitectòniques antigues i tradicionals del municipi. Localització, també, d'elements desapareguts en l'actualitat.
b) Parets seques
c) Barraques de Vinya
d) Localització dels sistemes de construccions arquitectòniques antigues i tradicionals del municipi. Localització, també, d'elements desapareguts en l'actualitat.
4. Mobilitat. Barreres arquitectòniques urbanes BAU: Ciclabilitat. Minusvalies. Tercera edat i embarassades.

En aquesta posada en escena a l'aula, m'adono com les TIG, en aquest cas el SIG Miramon i la tecnologia GPS representen, no tan sols una eina per acumular coneixement sobre el territori i analitzar-ne els factors incidents, sinó també un estri imprescindible per la comprensió de l'entorn. En va resultar una sistematització molt important de dades i fruit també d'un grau de dedicació i responsabilitat, per part dels alumnes, que mai, amb molts anys a l'ensenyament, no havia tingut ocasió de viure. El territori va ser qui va generar aquest grau de compromís, Miramon va fer la resta. El fruit de tot el treball realitzat es va traslladar i publicar en aquest visor i l'experiència divulgada en aquest seminari europeu de SIG.

És durant el curs 2010-2011 que novament en l'anomenat Projecte de Recerca, els alumnes de 4t d'ESO de l'Institut Miquel Bosch i Jover han desenvolupat uns projectes en grups de dos, basats en motivacions i interessos personals subjectes a aspectes vinculats al seu territori de referència; des d'itineraris esportius, passant per emulacions televisives en el seu propi municipi, a aspectes sociològics, associatius, culturals, etc.

Inicialment l'objecte formal de la recerca era observar i saber copsar qualsevol aspecte o temàtica que tingui una vinculació amb l'entorn de referència diària que condicionés la mobilitat de les persones o la ubicació d'aspectes derivats de l'activitat humana. Una vegada decidit el tema, assolit l'objectiu d'estructurar-lo per donar-lo a conèixer mitjançant les eines (Blogs, vídeos, www, fitxes pdf, CODI QR, etc.) que hi ha a l'abast, s'han abocat en visors cartogràfics i agrupats en un atles digital, entorn que en facilita, ràpida i extraordinàriament, la seva disposició i consulta. Aquest atles digital, creat a partir de recursos lliures, ja se l'ha considerat com el primer (atles digital) elaborat per estudiants, a Catalunya i Espanya i presentat en les JIIDE2011.

La fortuna de poder conduir uns alumnes amb un alt grau de responsabilitat i tenacitat, en uns treballs publicats en visors cartogràfics, posa en evidència una vegada més com uns vincles amb el territori juntament amb la usabilitat d'aquestes tecnologies, crea un producte d'abast i interès social i d'una gran rendibilitat didàctica i acadèmica.

Aquest projecte ha anat acompanyat d'una operativa eficaç i simple. Amb aquesta PRG utilitzada i facilitada novament per l'IDEC, generant els visors cartogràfics i atles corresponents, queda manifest que amb aquestes noves potencialitats ofereixen molts elements de valor superior al popular Google Earth/Maps, destaco a més a més:

La possibilitat d'incorporació de capes, on cada capa pot agrupar un nivell, ontologia o camp.
Es poden interconnectar, si es desitja, totes les ja existents i creuar totes les dades i capes.
Es basen en estàndards.

I a punt de tancar aquest escrit destaco el treball acabat de tutoritzat durant aquest curs 2011-2012 "La ruralitat d'Artés, un present amb passat i futur" , d'aquest mateix perfil i denominador comú del vincle amb el territori, elaborat per l'alumne de 2n de batxillerat, Xavi Roca i Obradors i del qual recomano se'l tingui ben present, tan a prop d'un treball enciclopèdic com d'un assaig sobre la realitat rural del seu entorn; el visor cartogràfic n'és el centre logístic.

Haig de concloure aquest apartat amb l'afirmació segura de què cal atribuir a les generacions actuals la responsabilitat de ser els dipositaris del valor del coneixement del territori de les generacions precedents i que això representi un llegat de futur.

Beneficis

Aquest és el terme que ràpidament es busca allà on es realitza una inversió, en el cas que em porta, i sense "funambulismes pedagògics" destaco:

Es rescata el territori i el paisatge de la trivialitat.
Es promou la integració de les actuals generacions, i de la comunitat en general en el propi territori i la sensibilització envers els paisatges que aquest desprèn. Llengua i coneixement del territori són els dos principals factors que incideixen en la integració social.
Aprendre les eines bàsiques de l'anàlisi per a estudiar i explorar dades geogràfiques i socials mentre que simultàniament poden proporcionar unes dades de gran valor.
Un grau important de coneixement sobre la informació geogràfica i la seva aplicació en la localització i anàlisi del territori.
No hi ha fragmentació ni especialització del coneixement, tot el contrari.
Promou la cultura geogràfica a través de la www !!! Com també per altres mitjans.

I, a partir d'ara, què?

Defenso i intento impulsar de què es vertebri una IDE sectorial a Ensenyament a partir de la producció acadèmica dels alumnes i de la producció intel•lectual dels professors.
Aquesta infraestructura tindria èxit perquè....:

Estaria ben coordinada i utilitzada.
Es faria sobre temes basats en un coneixement sòlid i en una participació informada.
Hi hauria una gran disponibilitat i qualitat de la informació.
Existiria un intercanvi, posada en comú, accés i utilització de dades i de serveis espacials

En el cas d'ensenyament, seria un cas singular on la comunitat d'origen i de destí quedaria doblement lligada i relacionada

Geoportales IDE Local: Un nuevo servicio de la Diputación de Barcelona

Sáez, J. — Mon, 06 Feb 2012 00:00:00 +0100

GEOPORTALES IDE LOCAL: UN NUEVO SERVICIO DE LA DIPUTACIÓN DE BARCELONA

Josefina Sáez
Diputació de Barcelona

1. Introducció

Las administraciones locales tienen entre sus funciones la gestión del territorio al cual representan, lo que implica la necesidad de disponer de información geográfica y herramientas, para facilitar su gestión. Dentro de estas herramientas se encuentran los Sistemas de Información Geográfica (SIG) y las Infraestructuras de Datos Espaciales(IDE).

Pese a las ventajas que supone el uso de este tipo de tecnologías, las dificultades para introducirlas en las administraciones locales con más limitación de recursos, son considerables. El motivo principal redunda en el hecho que muchas de ellas no disponen de la infraestructura, ni del grado de especialización, ni de los recursos (humanos, técnicos, económicos) necesarios para implantarlas.

Conscientes de la necesidad municipal y la escasez de recursos, desde la Diputación de Barcelona se han impulsado varios proyectos para ofrecer servicios a los ayuntamientos, en cumplimiento de sus competencias en materia de soporte municipal. En el marco de estas actuaciones, y con referencia al ámbito de la información geográfica, se encuentran la infraestructura cartográfica armonizada, las herramientas SIG, los recursos IDE y recientemente los geoportales web.

2. La importancia de las IDE

Una IDE es un sistema integrado por un conjunto de recursos informáticos acordes con unas especificaciones, protocolos e interfaces, que garanticen la interoperabilidad, y por una infraestructura cartográfica acorde a ciertas normas y estándares. Dichos recursos se ponen al alcance de los usuarios que los necesiten, a través de Internet, de forma actualizada, eficaz y sencilla. Dicha infraestructura debe dar respuesta a las peticiones procedentes de todos los sectores (administración pública, sector comercial, sector académico, ciudadanos,...) de la forma más eficaz y eficiente posible, minimizando las necesidades de una atención presencial.

Si nos referimos a sus componentes, una IDE está compuesta, como mínimo, por una infraestructura cartográfica (información geográfica de base y temática), unos geoservicios web (para la visualización, descarga, consulta,... de la información geográfica) y unos metadatos que describan dicha información. Cabe destacar la importancia de la homogeneización y/o armonización de la información geográfica para facilitar los estudios territoriales a nivel supramunicipal.

Otro aspecto importante a tener en cuenta en el establecimiento de una IDE se refiere al ámbito organizativo (recursos humanos, estándares y normas, normativa aplicable,...), componente de especial importancia para ordenar, regular, estructurar y armonizar todos los demás.

Las IDE se jerarquizan en diferentes niveles, en función de las estructuras de administración de cada Estado. De acuerdo con las iniciativas recientes, muchas administraciones están desarrollando infraestructuras de datos espaciales que van desde el ámbito local (ayuntamientos, provincias), al regional, nacional, europeo, e incluso global. Cada IDE perteneciente a un nivel debe integrar los conjuntos de datos espaciales que se encuentran en el nivel inmediatamente inferior, con el objetivo de no
duplicar recursos ni esfuerzos.

Concretando en el ámbito local, las IDE locales tienen como objetivo la integración a través de Internet de los datos, metadatos, servicios e información de tipo geográfico de competencia municipal, conforme a sus respectivos marcos legales.

Cabe destacar que la información geográfica es vital para tomar decisiones acertadas a las diferentes escalas. Las soluciones a la planificación urbanística sostenible, la recuperación medioambiental, las valoraciones de terrenos, la recuperación posterior a desastres climatológicos,... son sólo algunos ejemplos de las áreas en las que los responsables de tomar las decisiones, pueden beneficiarse de esta información gracias a los recursos que ofrecen las IDE, especialmente las herramientas utilizadas como sistemas de información de ayuda a la toma de decisiones.

De hecho, ya en la Conferencia de la ONU sobre el Medio Ambiente y el Desarrollo, celebrada en Río de Janeiro en 1992, se aprobó una importante resolución con el fin de alcanzar un desarrollo sostenible y de proteger el medioambiente. En esa Cumbre, la importancia de la información geográfica fue calificada como crítica para la toma de decisiones en todos los ámbitos de la administración.

3. El marco legal de la IDE local

Dentro de los principios comunes que incluye la iniciativa de implantación de una Infraestructura de Datos Espaciales, se encuentra el marco legal, el cual juega un papel muy importante en la implantación y desarrollo de las IDE. Por ello este apartado se dedica a la legislación que afecta al ámbito local.

Gracias a la iniciativa del Consejo Superior Geográfico, como órgano de dirección del Sistema Cartográfico Nacional con dependencia del Ministerio de Fomento, se ha impulsado el acceso a la información geográfica disponible en la administración pública. Este impulso se ha visto apoyado a nivel legislativo por la Directiva europea INSPIRE aprobada en el 2007 y por su transposición a la legislación española con la ley 14/2010, de 5 de julio, sobre las infraestructuras y los servicios de información geográfica en España (LISIGE).

La LISIGE establece que las disposiciones relativas a la organización de los servicios de información geográfica y cartografía serán aplicadas por los diferentes niveles de la administración, entre los cuales se cuenta con la aportación de la administración local. También se especifica que las administraciones y organismos del sector público español deben crear o desarrollar infraestructuras y servicios de información geográfica en el ámbito de su competencia (art. 2).

Con referencia a la producción de la información geográfica y la cartografía oficiales, la LISIGE establece que las entidades locales producirán la cartografía topográfica a escalas mayores que 1:5.000 y cualquier cartografía temática que precisen en el ejercicio de sus competencias, así como la información geográfica equivalente a esas escalas, dentro de sus límites territoriales (art. 18).

En lo que se refiere a las competencias locales, éstas se encuentran reguladas por diferentes marcos normativos. La primera a tener en cuenta es la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local, donde se establecen competencias para los ayuntamientos, entre las que podemos destacar la ordenación, gestión, ejecución y disciplina urbanística; el suministro de agua y alumbrado público; servicios de limpieza viaria, de recogida y tratamiento de residuos, alcantarillado y tratamiento de aguas residuales; el patrimonio histórico-artístico; la protección del medio ambiente o las actividades o instalaciones culturales y deportivas, por nombrar algunas (art. 5).

Otra ley a considerar es la 2/2011, de 4 de marzo, de Economía Sostenible, donde en el apartado referido a la información al servicio de las políticas públicas para un medio urbano sostenible (art.108), establece que para asegurar la obtención, actualización permanente y explotación de la información necesaria para el desarrollo de las políticas y acciones, la administración general del estado, en colaboración con las administraciones locales, definirá y promoverá la aplicación de los criterios y principios básicos que posibiliten la formación y actualización permanente de un sistema informativo general e integrado y comprensivo, al menos, de los siguientes instrumentos: Censos de construcciones; edificios, viviendas y locales desocupados; mapas de ámbitos urbanos obsoletos, desfavorecidos o en dificultades, o un sistema público general e integrado de información sobre suelo y urbanismo, a través del cual los ciudadanos tendrán derecho a obtener, por medios electrónicos, toda la información urbanística proveniente de las distintas administraciones, respecto a la ordenación del territorio llevada a cabo por las mismas.

También cabe destacar el Real Decreto 2612/1996 de 20 de diciembre, por el que se modifica el Reglamento de población y demarcación territorial de las entidades locales, donde en el artículo 75 establece claramente la competencia municipal en la rotulación de las vías públicas y en la georeferenciación de las direcciones postales.

Hasta aquí se han recogido algunas de las normativas que establecen las competencias a nivel municipal y que tienen referencia a la gestión territorial. Con referencia a las actuaciones específicas de la Diputación, comentar que se llevan a cabo en cumplimiento de las competencias que tiene asignadas en materia de soporte a los ayuntamientos, recogidas en el artículo 36 de la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local. Entre dichas competencias cabe destacar la coordinación de los servicios municipales entre sí para la garantía de la prestación integral y adecuada; la asistencia y la cooperación jurídica, económica y técnica a los municipios, especialmente los de menor capacidad económica y de gestión; la prestación de servicios públicos de carácter supramunicipal y en general, el fomento y la administración de los intereses peculiares de la provincia.

De todo lo expuesto se deduce la competencia clara de la administración local (municipal o provincial) en el establecimiento de una IDE y la actuación de soporte en este ámbito que se está llevando a cabo desde las diputaciones, orientada sobretodo a los ayuntamientos con escasez de recursos.

4. Los recursos de la IDEBarcelona

Conscientes de la necesidad municipal en el ámbito de la gestión territorial, desde la Diputación de Barcelona se han impulsado varios proyectos para la puesta en marcha de diferentes recursos IDE a nivel local, que sirvan tanto a nivel interno como a nivel municipal, como herramientas para la mejora de la gestión territorial. Entre estos recursos disponemos de visores de cartografía, herramientas SIG, catálogo de metadatos o geoservicios web estándares.

Entre los recursos IDE disponibles, cabe destacar:
a) Visores de mapas
Entre ellos, disponemos de diferentes visores de servicios estándares WMS, guías referidas a callejeros municipales y también herramientas SIG por Internet. En este último grupo destacamos la nueva versión de SITMUN (proyecto desarrollado en colaboración con diferentes administraciones públicas, en cumplimiento de la Ley 37/2007 sobre la reutilización de la información del sector público).

Figura 1. Visor de mapas WMS.

Figura 2. SITMUN (Sistema de Información Territorial Municipal).

Figura 3.Callejero municipal.

b) Geoservicios web estándares
Un geoservicio es un servicio web específico que devuelve información con componente geográfica, que permite el acceso a la información geográfica ubicada en los servidores de los organismos productores, de forma estándar y a través de cualquier aplicación que permita este tipo de acceso a la información. Para la generación y utilización de los geoservicios se utilizan lenguajes y protocolos estándares definidos por el Open Geospatial Consortium (OGC).

Servicios WMS:

Cartografía topográfica urbana: http://sitmun.diba.cat/wms/servlet/BUE1M
Cartografía topográfica a escala 1:1.000 de diferentes núcleos de la provincia de Barcelona, en su mayoría menores de 20.000 habitantes, que se está elaborando desde el año 2.000, con actualizaciones periódicas. Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.
Cartografía del callejero: http://sitmun.diba.cat/wms/servlet/CAE1M
Cartografía correspondiente a ejes y portales del callejero, a escala 1:1.000, de diferentes municipios de la provincia de Barcelona. A pesar que dicha cartografía en su mayoría se ha obtenido a partir de la cartografía topográfica urbana, su actualización está asegurada a través de una aplicación que permite la gestión online por parte de los ayuntamientos. Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.
Ortofoto histórica de los años 56-57: http://sitmun.diba.cat/wms/servlet/ORA56
Ortofoto de los años 56-57 a escala 1:10.000, elaborada por la Diputación de Barcelona a partir de un vuelo general de España realizado los años 1956-57, propiedad del Estado (Centro Cartográfico y Fotográfico del Ejército del Aire, Ministerio de Defensa)
Cartografía del SITXELL: http://sitmun.diba.cat/wms/servlet/SITXELL
Cartografia de la Red de Espacios Libres de la provincia de Barcelona, elaborada a escala 1:50.000 a partir de la superposición de diferentes capas de información geográfica. Para una correcta interpretación de dicha cartografía se recomienda consultar los metadatos asociados.

Mapa de cubiertas del suelo del año 1956: http://sitmun.diba.cat/wms/servlet/CSA56
El mapa de cubiertas el suelo de 1956 tiene cobertura para la región metropolitana. Este mapa muestra la distribución de las principales cubiertas (forestales, agrícolas, urbanas) y permite analizar su evolución hasta la actualidad.
Inventario de Patrimonio Cultural: http://sitmun.diba.cat/wms/servlet/PCE5M
Cartografía de elementos del patrimonio cultural y natural a escala 1:5.000 de diferentes municipios de la provincia de Barcelona. Su valoración permite el establecimiento de medidas para su protección y conservación. Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.
Censos de Actividades Clasificadas e Inocuas: http://sitmun.diba.cat/wms/servlet/ACE1M
Cartografía de los censos de actividades clasificadas e inocuas a escala 1:1.000 de diferentes municipios de la provincia de Barcelona. Se trata de inventarios de actividades económicas realizado a partir de trabajo de campo y de un vaciado de expedientes de actividad. Las actividades se clasifican según su sector económico (agrícola, ganadero, gestión de residuos, energético-minero, industrial, recreativocomercial-servicios,...). Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.
Ortofoto urbana: http://sitmun.diba.cat/wms/servlet/ORE1M
Ortofoto a escala 1:1.000 de diferentes núcleos de la provincia de Barcelona, producida a partir de los vuelos realizados para elaborar la cartografía topográfica urbana 1:1.000. Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.
Cartografía de los límites de los espacios naturales protegidos: http://sitmun.diba.cat/wms/servlet/XPE50
Cartografía correspondiente a los límites de los espacios naturales protegidos, gestionados por la Diputación de Barcelona, a escala 1:5.000.
Planeamiento urbanístico municipal: http://sitmun.diba.cat/wms/servlet/PUE1M
Cartografía correspondiente al planeamiento urbanístico municipal (clasificación, calificación, sistemas,...) de diferentes municipios de la provincia, donde se ha tomado como base la cartografía topográfica urbana a escala 1:1.000. Con el objetivo de dar a conocer la disponibilidad de dicha información, se ha habilitado una capa temática a nivel provincial que lo indica.

Servicios WPS:

Información de callejeros y direcciones postales: http://sitmun.diba.cat/wps/CAE1M/WebProcessingService
Posibilita la extracción de información alfanumérica y gráfica relacionada con las calles y las direcciones postales. Incluye un proceso para la generación de ficheros municipales acorde a la especificación de datos INSPIRE

c) Metadatos
Una de las herramientas fundamentales para un mejor aprovechamiento y una correcta utilización de la cartografía digital es la documentación de sus características técnicas e identificativas a través de los correspondientes metadatos o fichas documentaesl. Su difusión se lleva a cabo mediante la publicación en catálogos.

Todos estos recursos, dentro del marco competencial de la gestión territorial, están categorizados como recursos IDE (Infraestructura de datos Espaciales), los cuales se aúnan en geoportales web para su difusión.

5. El portal web municipal

Un portal web municipal es un sitio web cuyo principal objetivo es ofrecer al usuario el acceso a una serie de recursos y servicios, de forma fácil e integrada. Está dirigido básicamente a los ciudadanos, pretendiendo servir como lugar de acceso a información municipal y a facilitar la gestión a través de la administración electrónica (en cumplimiento de la Ley de Transparencia y Acceso a la Información Pública).

Actualmente la mayoría de ayuntamientos de la provincia disponen de portales web para ofrecer un servicio de información y gestión al ciudadano, no obstante, en algunas ocasiones resulta relativamente difícil encontrar la información que se está buscando. Este suele ser el caso de la información geográfica. En función del ayuntamiento, dicha información puede estar tipificada como información urbanística, turística, medioambiental, por nombrar algunos de ellos, lo cual dificulta su búsqueda.

Los geoportales web surgen como una iniciativa que permite disponer de un punto de entrada centralizado para toda la información y recursos relacionados con la información territorial.

6. El geoportal IDE Local

Un geoportal IDE local tiene como objetivo la integración a través de Internet de los datos, metadatos, servicios e información de tipo geográfico de competencia municipal, conforme a sus respectivos marcos legales.

Sin duda la incorporación de la tecnología al estudio del territorio ha permitido una capacidad de conocimiento del mismo, insospechado hace tan solo unos años. Pero también es verdad, que junto con las enormes oportunidades que se nos abren, se generan deficiencias para los ayuntamientos de la provincia con menor capacidad técnica y financiera.

Por ello, continuando en la línea de soporte municipal que ofrecemos desde la Diputación de Barcelona, hemos apostado por el desarrollo de un proyecto que facilite la implantación de geoportales IDE local para los ayuntamientos de la provincia con pocos recursos. Se trata de la elaboración de geoportales muy completos ya que no se limitan simplemente a disponer de un visor, sino que incluyen otras herramientas verdaderamente útiles y prácticas para el ciudadano de a pie.

Figura 4. Geoportal IDE local de Abrera (visores).

Figura 5. Geoportal IDE local de Manlleu (geoservicios).

El principal objetivo de esta iniciativa es el de ofrecer a los ayuntamientos un nuevo servicio, que les permita disponer de un punto de entrada a todos los recursos relacionados con la IDE y la información geográfica disponible, entre los que destacan los que ofrece la propia Diputación. Dicho servicio pretende facilitarles el cumplimiento de la legislación vigente en este ámbito.

Otro objetivo de esta iniciativa es el de facilitar la apertura a todas las administraciones públicas, al sector privado y a la ciudadanía, poniendo a su disposición datos, metadatos y servicios geográficos normalizados,.... Estos geoportales están alineados con los principios de las IDE de rango superior y con la iniciativa europea INSPIRE.

Una de las ventajas más importantes que se le puede atribuir a esta actuación, y más en época de crisis económica y restricciones presupuestarias, es el hecho de estar centralizado en la Diputación. Al tratarse de una herramienta de gestión centralizada, permite minimizar el coste de implantación y mantenimiento, y a su vez dar respuesta a objetivos que serían inabordables por cada una de las administraciones locales de manera individual.

CartoBCN: Portal web de descargas de cartografía del Ayuntamiento de Barcelona

Bolívar, M. Á. — Mon, 06 Feb 2012 00:00:00 +0100

CARTOBCN: PORTAL WEB DE DESCARGAS DE CARTOGRAFÍA DEL AYUNTAMIENTO DE BARCELONA

Miguel Ángel Bolívar Leyva
Informació de Base i Cartografia. Institut Municipal d'Informàtica. Ajuntament de Barcelona

1. Introducció

En febrero de 2011 se inaugura el Portal de Descargas del Ayuntamiento de Barcelona (CartoBCN), coincidiendo con la celebración del Salón GlobalGEO en la ciudad de Barcelona.

El objetivo fundamental de este portal es agilizar la difusión y posterior utilización de la cartografía que produce y mantiene el Ayuntamiento por parte de las empresas, colectivos, colegios profesionales y en última instancia los ciudadanos, contribuyendo a una modernización del servicio y redundando en beneficios globales en términos de promoción económica de la ciudad.

Anteriormente, la obtención de productos cartográficos se canalizaba bien a través de pedidos directos al Departamento, a través de las Oficinas de Atención Ciudadana, o en caso de empresas de servicios públicos, colectivos profesionales o empresas colaboradoras, a través de convenios de traspaso de información. El servicio actual a través del portal permite eliminar en su mayor parte los circuitos administrativos "manuales" de gestión y preparación de pedidos, con el consecuente ahorro en tiempo, costes y recursos de operación.

Como factores justificativos para su implantación, aparte de los beneficios ya señalados, cabe destacar tres fundamentalmente: La eliminación de tasas para la obtención de la cartografía municipal, el creciente volumen de la oferta de productos y de su demanda, así como la actual viabilidad tecnológica (internet) para su difusión.

Los objetivos están en consonancia con las políticas que promueven la difusión y dan importancia a la utilidad que la Información Geográfica generada por las Administraciones Públicas tiene para los ciudadanos y para la sociedad de la información (reflejada en la Ley LISIGE (14/2010 [13], 5/7, sobre las infraestructuras y los servicios de información geográfica en España). Así mismo, es de relevante importancia la política de Reutilización de la Información del Sector Público, en la que se promueve la publicación en web de datos y servicios cartográficos (Ley 37/2007 16/11).

Identificamos un gran grupo de interés, constituido por el sector profesional, el cual utiliza principalmente la información obtenida para trámites o proyectos (Arquitectos, Ingenieros, Gestores, Agentes de la Propiedad Inmobiliaria,...), y aquel subconjunto formado por colectivos profesionales o corporativos que utilizan la cartografía dentro de sus flujos de trabajo (departamentos técnicos municipales, compañías de servicios, ámbito universitario, empresas colaboradoras con la administración y ésta misma en general). Otro grupo de interés lo constituyen los propios ciudadanos, incluyendo en este amplio grupo incluso el sector docente.

Así mismo, el portal cuenta con una "Zona Empresas", destinada a los usuarios registrados como profesionales, los cuales disponen de un espacio propio y separado de descarga de productos que están fuera del catálogo público, preparados específicamente según necesidades, previo contacto y/o convenio de obtención de cartografía. Generalmente estos usuarios son empresas de servicios públicos y de mantenimiento, así como diferentes colectivos profesionales.

En todos los casos, la cesión de los datos cartográficos se realiza sin perjuicio de los derechos de autor ni de propiedad intelectual, en este caso del Ayuntamiento de Barcelona, amparándose, según los casos, en diferentes modalidades de Licencia Creative Commons:

CC de Reconocimiento para la mayoría de conjuntos de datos.
CC de Reconocimiento sin Obra Derivada en caso de datos donde pueda haber participación de terceros.

CartoBCN permite obtener la cartografía municipal en tres pasos:

1) Situación en la zona de interés: Localización por coordenada, dirección postal, cruce, barrio, distrito, sección censal, hoja UTM o referencia catastral.
2) Búsqueda y selección del producto: A partir de palabra clave, colección temática o ámbito de distribución geográfica (distritos, hojas UTM,...). Dependiendo del producto, puede seleccionarse el formato que se ajuste mejor a las necesidades (DGN, PDF, DWG,...) y añadirse a la cesta.
3) Identificación y descarga: Una vez el usuario ha cargado su cesta con los productos requeridos, la descarga directamente en un único fichero ZIP.

La utilización del servicio tan sólo requiere el registro de usuario, a través del cual se ha de facilitar el nombre, una dirección de correo electrónico, una clave y alguna otra información con fines estadísticos (código postal, colectivo profesional, etc.).

2. Productos de descarga

El repositorio de productos cartográficos que ofrece el Ayuntamiento de Barcelona al través del Portal de Descargas está en continua ampliación y actualmente está compuesto por siete colecciones:

Divisiones territoriales
Datos de Divisiones Administrativas
Datos de Divisiones Administrativas Históricas
Descripción de los Límites de los Distritos Municipales

Geocodificación y Nomenclátor
DIRECCIONES de calle
Datos del GRAFO VIAL por tramo de calle, CAD

Guía Urbana
Datos de PARCELARIO por MANZANA (no poligonado)
Guía Urbana en formato PDF (con Capas y Georeferenciado)
Guía Urbana escala 1:5.000 en formato CAD
Plano 1:10.000 de Guía Urbana y Barrios de la Ciudad
Plano 1:20.000 de Guía Urbana y Barrios de la Ciudad
Planos 1:5.000 de Guía Urbana y Barrios por DISTRITOS

Parcelario
Datos de PARCELARIO por DISTRITO
Datos de Parcelario por MANZANA (poligonado)

Series cartográficas
Datos de PARCELARIO por HOJAS 1:1.000, CAD
Datos de TOPOGRAFIA por HOJAS 1:1000, CAD
Datos de URBANISMO por HOJAS 1:1.000, CAD
PARCELARIO. Serie de Planos por HOJA 1:1.000
TOPOGRÁFICO. Serie de Planos por HOJA 1:1.000
URBANISMO. Serie de Planos por HOJA 1:1.000
Redes de HOJAS UTM

Temáticos
Mapa temático de Usos del Suelo
Temático de Edificios según Alturas por DISTRITO

Red Topográfica Municipal
Plano 1:20.000 de la RTM de la Ciudad
Reseñas de los Vértices de la RTM de Barcelona

Todos estos productos descargables se encuentran disponibles en diferentes formatos de fichero, dependiendo del caso:
Planos: PDF, PDF con capas georeferenciado
CAD: DGN (v7, v8), DWG, SHP, DXF
Base de datos: XML, CSV, Access
Documento: Docx, PDF
Otros: Mr. SID, ZIP

Adicionalmente, el repositorio cuenta con todos aquellos productos preparados para los colectivos profesionales en su respectivo espacio de "Zona Empresas".

3. Estructura y funcionamiento del Portal de Descargas

El Portal de Descargas CartoBCN se ha diseñado como un cliente web visualizador cartográfico, en el que es posible navegar sobre varios mapas de referencia, permitiendo observar el territorio y seleccionar directamente sobre éste la unidad de distribución geográfica (distrito, hoja UTM, manzana) de la que nos interesa descargar un producto.

Figura 1. Portal CartoBCN.

Se ha intentado que su uso sea lo más sencillo e intuitivo posible, incorporando ayudas contextuales en forma de hints, tooltips, y mensajes al usuario, destinados a buscar, seleccionar productos y llenar la "cesta de la compra", que será posible descargar en forma de archivo .ZIP con los productos cartográficos requeridos.

Así mismo se ofrece la opción de presentación multilingüe (Catalán, Castellano, Inglés) y acceso al Manual de Usuario en cada una de las lenguas.

La aplicación CartoBCN permite obtener la cartografía completando los tres pasos: Navegación/Localización, Búsqueda y selección de producto/s, Identificación y descarga de la cesta.

3.1 Navegación y localización
La navegación sobre el mapa de referencia permite situarse en la zona de interés a través de las herramientas estándar de zoom y desplazamiento. Este posicionamiento en el territorio también es posible a partir de otras opciones de localización, como son la ubicación por coordenadas UTM, por dirección postal, cruce de calles, barrio, distrito, sección censal, hoja UTM o incluso por Referencia Catastral.

Figura 2. Ejemplos de opciones de posicionamiento geográfico - Geolocalización.

3.2 Búsqueda y selección de productos
En la operativa de trabajo, diferenciamos tres formas o criterios posibles de buscar los productos:

Búsqueda por distribución geográfica del producto (ámbito geográfico)
La búsqueda de productos por distribución o ámbito geográfico nos permite realizar un filtro de productos por la extensión geográfica con la que se clasifica cada uno de éstos.
Cada producto tiene una división geográfica que lo caracteriza, por ejemplo, el producto "Temático de Edificios según Alturas, CAD" está organizado por extensiones geográficas a nivel de Distritos, otro ejemplo sería "Datos de Parcelario por manzana", que se clasificaría con la distribución geográfica de Manzanas. También existen otros productos cuya extensión es toda la Ciudad, como por ejemplo "Guía Urbana", o incluso divisiones por hojas UTM.
Una vez seleccionada la distribución geográfica por la que se filtra, se seleccionarían sobre el mapa los ítems que nos interesan (ej. distrito 6) y a partir de allí se nos mostrará la lista de productos que podemos escoger.

Figura 3. Búsqueda de productos por ámbito geográfico. Selección.

Búsqueda por colección
Como se ha visto en la sección 2, los productos están clasificados por colecciones de acuerdo a la familia o tipología de datos cartográficos que los componen. La selección de una colección muestra todos los productos que la forman, pudiendo seleccionar el requerido.
La selección de un producto automáticamente activa de forma gráfica la distribución geográfica asociada a éste, de tal forma que el usuario puede marcar las porciones geográficas que necesite, como se muestra en el siguiente ejemplo.

Figura 4. Búsqueda de productos por colección. Selección.

Búsqueda por palabra clave
Si el usuario no tiene un criterio inicial de búsqueda que se enmarque dentro de una colección o distribución geográfica determinada, lo más sencillo es realizar una consulta de los productos simplemente usando una palabra.
Cada uno de los productos tiene asociadas varias palabras clave en sus metadatos, relacionadas con su contenido, origen de los datos, o cualquier otra característica relevante del tipo de información que aporta, y que son susceptibles de utilizarse como palabra de búsqueda.

Figura 5. Búsqueda de productos por palabra clave. Selección.

3.3 Esquema de la secuencia de trabajo
En el siguiente esquema se muestra el flujo de trabajo, desde la búsqueda hasta la carga de los productos en la cesta:

Figura 6. Secuencia de trabajo.

4. Obtención de los productos
La secuencia de trabajo finaliza cuando el usuario ya ha llenado su cesta con los productos requeridos, en la cual en cualquier momento ha podido añadir o quitar productos, así como revisar su contenido. En el momento de efectuar la descarga de la cesta, se requiere en primer lugar la identificación del usuario, a través de su correo electrónico y su contraseña para CartoBCN.

El usuario debe estar registrado previamente, o bien se le permite registrar en ese mismo momento. Este proceso consiste en facilitar el nombre, apellidos, una dirección de correo electrónico, una clave y alguna otra información con fines estadísticos (código postal, colectivo profesional, empresa,...), así como aceptar las condiciones de uso que se le muestran. Inmediatamente, el proceso de registro le envía un correo al usuario con un enlace de confirmación y activación que deberá abrir (correo de activación de cuenta).

Figura 7. Descarga de la cesta de productos.

Identificado el usuario, se le mostrará un listado detallado de los productos que formarán la descarga y como último paso se le solicitará escoger de una lista el uso que le dará a la información que se descarga, igualmente con fines estadísticos.

El usuario obtiene directamente un archivo comprimido .ZIP que contendrá una estructura de directorios con los ficheros correspondientes a los productos que seleccionó, así como un documento PDF descriptivo por cada uno de ellos con sus metadatos, la estructura de la información (capas, formato de registros, etc.) y sus condiciones de uso.

5. Otros recursos del Portal

Noticias: CartoBCN cuenta con una sección de noticias destinada a ofrecer a los usuarios información sobre las últimas incorporaciones o actualización de sus contenidos, pudiendo ofrecer imágenes de muestra de éstos.

Trámites: Esta sección pretende incorporar paulatinamente una lista con la descripción de los trámites relacionados con la cartografía que gestiona el Departamento de Información de Base y Cartografía así como documentación sobre procesos administrativos relacionados (certificados de numeración, procedimientos para la obtención de cartografía específica, etc.). En el caso de que exista el trámite en línea correspondiente, incorporará un enlace a éste.

Enlaces: Desde esta sección se muestran accesos a otros recursos de interés relacionados, tanto internos como externos.

Zona Empresas: Se trata del espacio disponible para la obtención de productos específicos que están fuera del catálogo público, preparados específicamente según necesidades de la empresa o colectivo que lo necesita, previo contacto o convenio de obtención de cartografía. El acceso cada una de las carteras de productos es restringido y precisa que el correspondiente usuario haya solicitado ser habilitado como profesional.

Sugerencias: El portal habilita un canal para realizar consultas o sugerencias, tanto referentes al propio funcionamiento del sitio web como referente a sus contenidos. Dicho canal se integra dentro del Sistema Municipal IRIS (Incidències, Reclamacions I Suggeriments), servicio por el cual el Ayuntamiento permite hacer llegarle y poder gestionar reclamaciones, consultas y sugerencias sobre el funcionamiento de la ciudad o sobre los servicios municipales.

6. Conclusiones

La difusión de la cartografía que produce y mantiene el Ayuntamiento hacia las empresas, colectivos, colegios profesionales y en última instancia los ciudadanos, contribuye a una modernización del servicio actual y pretende redundar en beneficios globales en términos de promoción económica de la ciudad.
La eliminación de tasas para la obtención de la cartografía municipal, el creciente volumen de la oferta de productos y de su demanda, así como la actual viabilidad tecnológica (internet) para su difusión permiten liberar gran parte de la producción cartográfica del Departamento responsable.
El Portal de Descargas de Cartografía complementa la oferta actual de servicios en línea que ofrece el Ayuntamiento de Barcelona para la difusión de la información territorial: Geoportal, Portal OpenData, Guía del Ciudadano y el Plano de Información Urbanística.
CartoBCN, tras un periodo inicial de rodaje y evaluación, pretende crecer incorporando nuevos productos y aportando nuevas y mejoradas funcionalidades, ayudándose para ello de la experiencia adquirida y de las aportaciones obtenidas de los usuarios del sistema, quienes conforman el escenario real, con necesidades prácticas reales.

Referencias

Integración de modelos medioambientales en infraestructuras de datos espaciales: Un caso de uso en predicción de incendios

Trilles, S.*, Juan, P.**, Díaz, L.*, Huerta, J.* — Mon, 06 Feb 2012 00:00:00 +0100

INTEGRACIÓN DE MODELOS MEDIOAMBIENTALES EN INFRAESTRUCTURAS DE DATOS ESPACIALES: UN CASO DE USO EN PREDICCIÓN DE INCENDIOS

Sergio Trilles¹, Pablo Juan Verdoy², Laura Díaz¹, Joaquín Huerta¹

¹ Institute of New Imaging Technologies
² Departament de Matemàtiques
Universitat Jaume I

1. Introducción

Hoy en día los incendios forestales son unas de las principales amenazas medioambientales más crecientes a las que nos exponemos[2].Esto produce la pérdida de bienes humanos y lo que es peor, la destrucción de la parte boscosa que nos rodea.

Hoy en día es común utilizar herramientas informáticas en la mayoría de las áreas de trabajo.El campo de los incendios forestales no es la excepción. Tal vez, las herramientas más comunesy más utilizadas son los simuladores, los cuales tratan de imitar el comportamiento del fuegodurante un incendio forestal (donde el tipo de combustible a incendiar se considera continuo y uniforme[3]). Estas herramientas pueden ser utilizadas tanto para la toma de decisiones duranteun incendio como para el estudio de cómo se propagaría el fuego en un determinado lugar yasí poder mejorar las medidas preventivas [4], etc.

Por otra parte, otro objetivo de este proyecto es compartir dichos modelosmedioambientales. Esto enriquecerá las tareas de prevención de incendios que se desarrollan en un futuro.

En [1] se definen los modelos medioambientales de predicción de riesgos de incendios en los que este sistema será capaz de ejecutar. Dichos modelos son ejecutados en R¹ [21], programa estadístico, esto hace que el sistema tenga la capacidad de ejecutar dichos modelos de forma totalmente desacoplada al entorno R.

2. Estado del arte

Actualmente, son muchos los trabajos relacionados con la temática de incendios.Esto se debe en gran medida a que hoy en día es un campo de estudio latente ya que no se ha conseguido resultados definitivospara la predicción y simulación de incendios. Según [5] esta temática se divide en dos principales ramas:

Simulación de incendios: mejorar la efectividad de la lucha contra el frente del fuego durante un incendio.
Análisis de Riesgo o Predicción: obtener mapas de riesgo que obtienen el peligro de incendio de distintas regiones basándose en condiciones meteorológicas y en factores humanos. Como nuestro estudio se encuentra dentro de este grupo a continuación detallaremos los trabajos realizados.

Son muchos los trabajos realizados para obtener las tasas de riesgo de incendio. Los parámetrosque se suelen utilizar para estos modelos, son parámetros conocidos y controlados por agentesforestales como es la densidad del arbolado, composición de especies o el uso del suelo. La utilización de estas variables es debido a que se ha demostrado que tiene ciertarelación de producirse un incendio [6] [7] [8] [9] [10].Otro factor tenido en cuenta son las condiciones climáticas, ya que se ha estudiado que está directamente relacionado [11].

El cambio en el clima también parece estar influyendo directamente en el comportamientodel fuego [11]. También es influyente la estacionalidad de los incendios, bien sea por causasnaturales [12] o por prácticas socioeconómicas [13], dándose la circunstancia de quemuchas áreas son castigadas por el fuego por debajo del periodo de rotación de la zona,concentrándose los mayores fuegos en zonas específicas.

Así pues, la probabilidad de incendio depende de dos factores complejos como son:

Condiciones climáticas [14] [15] [16].
Tipo y estructura de la vegetación [17] que en algunos casos favorece y en otros casos parece frenar su avance [18] y que en las zonas de referencia están totalmente relacionadas con las condiciones socioeconómicas [19] [20].

La existencia de correlaciones entre variables climáticas y parámetros de posición tales como longitud, latitud, altitud, pendiente y orientación implica que estos parámetros pueden sustituir a las variables climáticas en la elaboración de modelos.

Para nuestro trabajo hemos utilizado el estándar WPS (Web Processing Service), estos fueron diseñados para estandarizar la forma de ofrecer cálculos GIS a través de Internet. Este estándar proporciona reglas para describir cualquier cálculo (proceso), así como la forma de realizar peticiones al servicio y la respuesta que ofrece. La especificación de los WPS fue publicada por OGC en 2004 y en 2007 la versión 1.0.0 [21].

Un WPS proporciona acceso a operaciones o cálculos de datos geoespaciales, de distinta complejidad, mediante Servicios Web como interfaces. Puede contener operaciones para tratar tanto datos vectoriales como matriciales, provenientes de la red o del propio servidor.

3. Modelos medioambientales

El objetivo del código de predicción es utilizar la metodología estadística desarrollada en procesos espaciales [1] para analizar y modelar el comportamiento de cualquier incendio. Si a cada incendio asociamos sus coordenadas espaciales longitud y latitud del centroide de la zona quemada, junto con otras variables como la pendiente, contorno de la zona a analizar, la orientación, la elevación o usos, controlando la temporalidad de los incendios, podemos identificar el conjunto de incendios forestarles mediante un proceso estocástico espaciotemporal.

Estos procesos llamados procesos puntuales espaciales son un modelo estocástico que genera un número infinito de eventos {x_i, i = 1... n} en un conjunto X. Si estos eventos tienen asociadas medidas o marcas tenemos un proceso puntual con marcas.

Para este trabajo, hemos utilizado dos tipos de procesos puntuales, Poisson inhomogeneo y Area Interaction.

4. Diseño e implementación de un servicio de procesamiento para la predicción de riesgo de incendio

Como propuesta hemos diseñado un servicio web que implementa una interfaz basada en la especificación de estándar Web Processing Service (WPS) de OGC. Se ha demostrado que esta interfaz mejora la interoperabilidad del procesamiento en infraestructuras de datos espaciales basadas en estándares internacionales [22] [23]. De las implementaciones de código abierto exitentes del estándar hemos reutilizado la ofrecida por 52North².

El primer paso para describir el proyecto son las entradas al sistema. Si analizamos los modelos medioambientales vemos que sus entradas y salidas no son estándares en el mundo SIG, ya que éstetiene como entrada ficheros de texto con las diferentes entradas y salidas.

Se ha definido que las entradas al WPS no sean los ficheros de texto no estructurado por ser más sensible a error, los datos espaciales de entrada están codificados en uno de los formatos espaciales más extendidos como es el ESRI shapefile³. La última entrada al sistema, números de modelos, nos indica el número de los algoritmos que se quieran ejecutar. Estos números corresponden con cada uno de los modelos definidos previamente (Tabla 1).

De esta forma las entradas del WPS quedarán como muestra la Figura 1. Por otra parte los parámetros de salida de los modelospreviamente devueltos como ficheros de texto, serán devueltos en un formato estándar para incrementar su interoperabilidad con diferente software GIS. El formato elegido para devolver la predicción de riesgo obtenida para cada método es KML⁴. Además también se tendrá como salida la gráfica obtenida para cada modelo aplicado.

Figura 1. Entradas y salidas del sistema.

Núm.	Modelo
1	Poisson con polinomio X Y
2	Poisson con polinomio X Y 2
3	Poisson con la covariable elevación
4	Poisson con la covariable usos
5	Poisson con todas las covariables
6	Area Interaction con polinomio X Y
7	Area Interaction con elevación
8	Area Interaction con usos
9	Area Interaction con todas las covariables

Tabla 1. Modelos de predicción de riesgo de incendios definidos.

A continuación hablaremos de cuáles son los pasos que realiza el WPS una vez ejecutado. La Figura 2 muestra estos pasos.

El primer paso, ya dentro de nuestro algoritmo, es comprobar que todas las entradas son correctas. Para no tener más problemas de incompatibilidad de momento todas las
entradas son obligatorias.

Figura 2. Principales pasos del WPS.

El segundo paso es lanzar la rutina de eliminación de carpetas temporales de otras ejecuciones anteriores. Se ha previsto esta rutina para tener siempre limpio el servidor, aunque se eliminen los ficheros que no son necesarios, las salidas continúan en la carpeta temporal. Con esta rutina lo que se pretende es eliminar las carpetas que hayan sido creadas hace ciertos días y mantener limpio el servidor.

El tercer paso, es la descompresión de los shapefiles y el tratamiento de ellos para generar lostxt de entrada al proceso de R. Es un proceso algo costoso ya que la información geográfica suele tener mucho tamaño.

El cuarto paso es llamar al proceso de R para su ejecución. Éste está previsto en varios sistemas operativos tanto en Windows como en Unix siempre que tengan las librerías necesarias. Como ya se ha comentado anteriormente los modelos de predicción de incendios están implementados en R, más concretamente tienen que ejecutarse en la versión 2.9.2. Se han de instalar las librerías splancs y spatstat de R. Además también es necesario el paquete de ghostscript para la generación de imágenes desde el propio R. De esta forma es necesario ejecutar desde el WPS unproceso con R, obteniéndose con el comando Rscript. Éste nos permite ejecutar una especie de scripts pero de R.

Además el proceso se llama con argumentos. El primero de ellos es la ruta de dentro del servidor de donde está el fichero kinhom2.txt necesario para la ejecución del proceso; Otro argumento es la ruta de donde está la carpeta temporal con los ficheros de texto generados en el proceso anterior; Finalmente, la última son los números de los modelos que hay que ejecutar en R. Por lo tanto el número de argumentos puede ser variable.

En el quinto paso, una vez terminado el proceso de R, realizaremos la lectura de los ficheros de texto generados para cada método y generaremos el KML. Además también se genera la cadena con las rutas de las gráficas.

Finalmente, se devuelve el flujo al WPS indicándole las salidas para que éste las muestre.

5. Experimentación

Para poder realizar la experimentación, se ha tomado la información geográfica necesaria, para cada una de las entradas al WPS. Para las pruebas se ha tomado la información únicamente de la provincia de Castellón, ya que se adapta a los requisitos y su tratamiento tiene un coste computacional y temporal medio.

La primera entrada es el contorno de la provincia de Castellón. Esta información se ha guardado en shapefilecon cada uno de los puntos que forman la provincia.

La segunda entrada son los centroides de los incendios producidos en los últimos cinco años en la provincia de Castellón. Esta información también son puntos que tienen asociada toda la información del incendio, guardándose también en un shapefile.

Las siguientes entradas son las covariables, que irán separadas con diferentes shapefile. Cada shapefile forma una malla con puntos formando una cuadrícula y cada punto tendrá asociado un valor dependiendo de la covariable. Son cuatro las covariables que se permiten: elevación, pendiente, orientación y uso del suelo. Cabe destacar que cada punto de la malla estará a una distancia de 200 metros.

El último parámetro de entrada son el número de los algoritmos a ejecutar. En este caso ejecutaremos todos los algoritmos para ver su resultado.

EL WPS genera dos salidas, una el KML con la predicción de riesgo y las gráficas para cada modelo. El KML generado tiene para cada punto asociado un extendedData con los valores para cada uno de los modelos en que se ha ejecutado el proceso (Figura 3).

Figura 3. Representación visual del contenido de un punto del KML.

A continuación mostraremos un ejemplo de los mapas de predicción de riesgo obtenidos para un modelo ejecutado. Para la generación de estos mapas, los resultados de predicción se han dividido en 20 clases utilizando como modo de división por cuantiles, ya que se obtiene un resultado más representativo. En este caso hemos elegido el modelo Area Interaction con todas las covariables (Figura 4).

Figura 4. Mapa de predicción de riesgo del método Area Interaction con todas las covariables.

A continuación, mediante la tabla (Tabla 2) desglosaremos los resultados para cada uno de los modelos de R que hemos habilitado para este trabajo.

Núm.	Modelo	Tiempo
1	Poisson con polinomio X Y	42 s
2	Poisson con polinomio X Y 2	42 s
3	Poisson con la covariable elevación	1 m 31 s
4	Poisson con la covariable usos	1 m 29 s
5	Poisson con todas las covariables	1 m 31 s
6	Area Interaction con polinomio X Y	4h 51 m 55 s
7	Area Interaction con elevación	2h 13 m 30 s
8	Area Interaction con usos	2h 20 m 15 s
9	Area Interaction con todas las covariables	2h 20 m 38 s

Tabla 2. Tiempos para cada modelo definido.

6. Conclusiones
Se ha realizado un servicio de procesamiento que mejora la interoperabilidad implementando el interfaz estándar OGC WPS que pone al alcance de todo el mundo unos modelos de predicción de riesgo de incendios y lo hace mediante Web. Estos modelos, son modelos realmente costosos y de muchos cálculos.Esto hace que no obtengamos resultados en cuestión de minutos sino de horas. Pero esto no es culpa del WPS implementado, sino todo lo contrario, la parte de preparación y recolección de datos del proceso R, lo hace realmente rápido, en medida de lo posible, ya que no hay que olvidar que con los datos que se trabaja de entrada son realmente grandes. También hay que mencionar que estos cálculos también dependen del equipo en que se ejecuten.

Por otra parte, se ha decidido probar el sistema con los datos de la provincia de Castellón, por el motivo de que la provincia de Castellón tiene un tamaño adecuado para las prestaciones del equipo de prueba.

Esta aproximación para la integración de modelos científicos en geoprocesamiento distribuido, facilita su despliegue en infraestructuras de datos espaciales ayudando a que podamos compartir dichos modelos y facilitar el uso a gente interesada.

Agradecimientos. A la Fundación Bancaja y la Universitat Jaume I por la financiación de este proyecto.

Notas
1. The R Project for Statistical Computing. http://www.r-project.org/
2. http://52north.org/maven/project-sites/wps/52n-wps-webapp/
3. http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
4. http://www.opengeospatial.org/standards/kml

Referencias

[1] Serra, L., Juan, P., Varga, D., Mateu, J., Saez, M.:Spatio-temporal pattern modelling of wildfires in Spain.
[2] De La Cita,F.J., Lerner, M., Robla, E., Vallejo, R.: El mapa forestal de españa a escala 1:50.000 (1998-2007): Resumen y resultados de un proyecto. 5º CongresoForestalNacional, 2009.
[3] Rothermel, R. C.: How to predict the sperad and intensity of forest and range fires. Department of Agriculture, Forest Service, Intermountain Forest and Range Experiment Station, pages 1-5, 1983.
[4] Bianchini, G.: Sistema de ayuda a la decisión para la gestión de incendiosforestales. Memoria del trabajo experimental dentro del programa de Doctoradoen Informática (Arquitectura de Computadores y Procesamiento Paralelo, 2004.
[5] Bianchini,G.:Wildland fire prediction based on statistical analysis of multiple solutions. Tesis Doctoral. Universidad Autónoma de Barcelona, 2006.
[6] Van Wagner, C.E.: Conditions for the start and spread of crown fire. Canadian Journal of Forest Research, pages 23-24, 1977.
[7] Finney, M.A.: Modeling the spread and behavior of prescribed natural fires. 12th Conf. Fire and Forest Meteorology, page 138U143, 1994.
[8] Moreira, F.C.,Rego, F., Ferreira, P.G.: Temporal (1958-1995) pattern of change in a cultural landscape of northwestern portugal: implications for fire occurrence. Landscape Ecology, pages 557-567, 2001.
[9] Pollet, J.,Omi, P.N.: Effect of thinning and prescribed burning on crown fireseverity in ponderosa pine forests. International Journal of Wildland Fire, page 1-10, 2002.
[10] González, J.R., and Pukkala, T.:Characterization of forest fires in catalonia (northeast spain). European Journal of Forest Research, pages 421-429, 2007.
[11] Vázquez, A., Moreno, J.M.:Spatial distribution of forest fires in sierra de gredos (central spain). Forest Ecology and Management, pages 55-65, 2001.
[12] Teensma, P.D.A.: Fire history and fire regimes of the central western cascades of oregon. Ph.D. Dissertation. University of Oregon, 1987.
[13] Calvo, E., Pons, X., Lloret, F., Díaz-Delgado, R.:Wildfires and landscape patterns in the eastern iberian peninsula. Landscape Ecology, pages 745 759, 2002.
[14] Andrews, P.L.: Behave: Fire behavior prediction and fuel modeling system-burn subsystem. US Department of Agriculture, Forest Service, Intermountain Research Station, page 130, 1986.
[15] Van Wagner, C.E.: Development and structure of the canadian forest fire weather index system. Canadian Forest Service, pages 209-223, 2003.
[16] John, W., Prather, J.W.,Yaguang, X.,Haydee, M., Hampton, H.M.,Aumack, E.N., Dickson, B.G., Sisk, T.D.: Mapping the probability of large fire occurrencein northern arizona, usa. Landscape Ecology, page 747U761, 2006.
[17] Kitzberger, T.,Mermoz, M., Veblen, T.T.: Landscape influences on occurrence and spread of wildfires in patagonian forests and shrublands. Landscape Ecology, pages 2705-2715, 2005.
[18] Dasgupta, J.M.C.,Alldredge, N.,Nunes, R.J.,Vasconcelos, M.C.S., Pereira, M.J.,Rego, F.C.:Land cover type and fire in portugal: do fires burn land cover selectively? Landscape Ecology, pages 661-673, 2005.
[19] Chas, M.; Forest fires in galicia (spain): Threats and challenges for the future.Journal of Forest Economics, page 1U5, 2007.
[20] Marey, M.F., Rodríguez, V., Crecente, R.: Using gis to measure changes in the temporal and spatial dynamics of forestland: experiences from north-west spain. Forestry Vol. 79, pages 409-423, 2006.
[21] Schudt, P.:OpenGIS Web Processing Service Version 1.0.0, OpenGeospatial Consortium.http://www.opengeospatial.org/standards/wps (accessed 4 Sep. 2008)
[22] Díaz L., Granell C., Gould M., Pascual V., Guimet J.:Resultados del proyecto AWARE: Reutilización de procesos científicos en una IDE. In Actas de las V Jornadas Técnicas de la Infraestructura de Datos Espaciales de España (JIDEE 2008). Costa Adeje, Tenerife, Nov 2008.
[23] Granell C., Díaz L., Gould M.. Service-oriented applications for environmental models: Reusable geospatial services. Environmental Modelling and Software, 25(2): 182-198, 2010. ISSN: 1364-8152.

Generación de una capa Astronómica para la IDE Arqueológica. Arqueastronomía en el Sur de Portugal

Gómez, J.*, Mejuto, J.**, Rodríguez, G.*** — Mon, 06 Feb 2012 00:00:00 +0100

GENERACIÓN DE UNA CAPA ASTRONÓMICA PARA LA IDE ARQUEOLÓGICA. ARQUEOASTRONOMÍA EN EL SUR DE PORTUGAL

José Gómez¹, Javier Mejuto², Gracia Rodríguez³

1. Dirección de Gestión de Red e Innovacíón. ADIF
2. Departamento de Matemática Aplicada. Facultad de Matemáticas. UCM
3.Sección Departamental de Astronomía y Geodesia. Facultad de Matemáticas. UCM

1. Arqueoastronomía

Desde el principio, la Arqueoastronomía ha sido desarrollada por especialistas de diferentes disciplinas. Esto, junto al hecho de que es una rama desarrollada recientemente, ha causado cierto desorden conceptual y metodológico. Se puede ver, por ejemplo, en la variedad de definiciones existentes para Arqueoastronomía: "Disciplina que estudia la forma en que las sociedades antiguas se conectan con el cosmos, teniendo en cuenta datos arqueológicos e históricos".[1]. "Disciplina que estudia el grado de conocimiento astronómico de las sociedades antiguas, en conexión con su visión del cosmos" [2], y "Disciplina que estudia el desarrollo de la astronomía de las sociedades prehistóricas en su contexto cultural" [3]. De acuerdo a esto, quizás la mejor definición sería la Ciencia que estudia el escenario celeste en el pasado, teniendo en cuenta cualquier fuente de datos como la arqueología, antropología, etnografía, datos históricos y otros.

Para llegar a entender la situación actual deberíamos echar la vista atrás a los inicios. Los comienzos de esta disciplina se llevaron a cabo por algunas personas interesada en la orientación de varios monumentos megalíticos. Estos estudios se hicieron en el siglo XVIII por el arquitecto JohnWood [4] y el anticuario William Stukeley [5] relacionadas con Stonehenge, Callanish, el Castillo de Rigg y el Círculo Sarsen. Con estos dos primeros estudios comienzan también dos tendencias que siguen estando vigentes hasta hoy día. La primera de ellas es la predominante, destacando la importancia de los estudios megalíticos de Arqueoastronomía en contra de cualquier otra época arqueológica. La segunda tendencia está relacionado con el papel principal que los investigadores británicos tuvieron en este tipo de obras.

Después de Wood y las contribuciones de Stukeley, el notable trabajo siguiente fue hecho a partir del cambio de siglo por otro anticuario, A. L. Lewis. Era una recopilación de sitios arqueológicos con cierto significado astronómico, que fue utilizado y ampliado por el capitán del ejército británico H.B. Sommerville y Sir Joseph Norman Lockyer [6]. Alexander Thom es considerado como el padre de la Arqueoastronomía moderna. Sus publicaciones más importantes "The solar observatories of Megalithic Man" [7], y "Megalithic sites in Britain"[8] , son obras esenciales en la bibliografía. La principal contribución de este ingeniero es la aplicación de técnicas topográficas y matemáticas al estudio de los diferentes yacimientos arqueológicos. Thom no solo basó sus investigaciones en yacimientos tradicionales, sino que dirigió sus estudios hacia los megalíticos.

Con esta nueva aproximación, la disciplina llegó a la década de los años 80 del siglo XX. En este periodo, la Arqueoastronomía se desarrolló en muchos paises europeos de la mano de investigadores como Michael Hoskin y Carlos Jascheck, quien fundó en 1992 la SEAC (Sociétè Européenne pour l'Astronomie dans la Culture/European Society for Astronomy in Culture) con el objetivo de estimular nuevos conceptos y métodos que sirvieran para entender de una forma nueva las profundas interacciones que existen entre astronomía y cultura. Este fue casi el único esfuerzo para llevar a cabo trabajos interdisciplinares en Arqueoastronomía, en contra de lo que tradicionalmente se venía haciendo por parte de los arqueólogos.

1.1 Arqueoastronomía y Arqueología
La enorme brecha existente entre ciencias sociales y naturales ha sido un problema que ha afectado tradicionalmente a la investigación arqueoastronómica. A menudo esto ha producido una reacción negativa entre los arqueólogos y en muchos casos ha llevado al rechazo de conclusiones astronómicas. Afortunadamente parece, al menos en los últimos años, que se está produciendo un cambio con la aparición de nuevos proyectos bien diseñados que tienen en cuenta cuestiones interdisciplinares.

La Arqueoastronomía puede verse como otra arqueometría. La aplicación de las ciencias naturales al análisis del contexto arqueológico. En este caso, la Arqueoastronomía puede manejar registros arqueológicos inmateriales, creencias y rituales que no tendrían una interpretación desde otro punto de vista. El arqueólogo necesitará de un especialista para interpretar un registro astronómico. Pero, obviamente, las interpretaciones culturales necesitan un arqueólogo que discernirá entre las posibles interpretaciones astronómicas. De esta manera, ambos aspectos son necesarios y esenciales.

En cualquier otro caso, las interpretaciones arqueoastronómicas serían inexactas o falsas; medidas sin sentido o mal interpretadas en un contexto arqueológico.

Por lo tanto, necesitamos proyectos interdisciplinarios e investigaciones que se retroalimenten entre sí para evitar esta situación.

1.2 IDEs en Arqueología y aprovechamiento de datos astronómicos
Desde hace algún tiempo cada vez con mayor frecuencia, de forma sistemática sobre cada yacimiento, se lleva a cabo una labor de reconstrucción topográfica usando técnicas GIS bien conocidas. Esta consiste en hacer un inventario de todos los elementos que aparecen en el yacimiento, junto con la ubicación que ocupa cada uno. El uso de una IDE, permite publicar este inventario digital de la información, a partir de formatos estándares, permite que se puedan compartir.

Dentro de la IDEE ya existe un Grupo de Trabajo, el SGT12, dedicado a Patrimonio Histórico, que está llevando a cabo diversas iniciativas para normalizar y aprovechar al máximo esta nueva vía de intercambio de información. [9].

Toda la IDE está disponible a través de internet, lo que permite que diversos grupos de trabajo, puedan acceder a la información. ¿Cómo aplicar esto en común con datos astronómicos?. La solución proviene de utilizar los datos publicados por medio de la IDE arqueológica, por medio de clientes.

Los servicios más útiles son el WMS y el WFS. Los daos astronómicos, los podemos publicar en dos formatos. Lo más sencillo es ofrecerlos en formato GML o geoRSS. Este es un estándar consistente en un XML en el que cada elemento está asociado a su posición geográfica. Esta opción es la mejor a la hora de quererlos utilizar en un cliente ligero, como OpenLayers o Google Maps. Lo más representable en este caso, son elementos aislados, como la línea del orto helíaco de una estrella o si queremos combinar nuestra capa arqueológica con otros capas procedentes de otros IDE, por ejemplo las de geología, modelo de elevaciones, etc.

La otra opción es generar una capa cartográfica completa, que se pude almacenar en la base de datos y es publicada como una capa más dentro de la IDE. Esta solución es válida para representar líneas como la de los límites norte y sur de un eclipse de sol o la zona de visibilidad de un tránsito.

Como objetivo de utilizar la IDE para la distribución de este tipo de información nos hemos planteado los siguientes:

Proporcionar una forma sencilla de acceder a información astronómica
Encapsular la complejidad de los cálculos astronómicos
Proporcionar una capa de información adicional para los estudios arqueológicos

2. Datos arqueológicos. El yacimiento de recintos en el sur de Portugal

Los datos utilizados en este trabajo se han obtenido en el contexto del proyecto "Ditched Enclosures plans and Neolithic Cosmologies: A Landscape, Archaeoastronomical and Geophysical Point of View". Este fue fundado por la Fundación Calouste Gulbenkian y científicamente liderado por Antonio C. Valera, desde Era Arqueología. La parte geofísica fué llevada a cabo por Helmut Becker, de Becker Archaeological Prospections. La parte arqueoastronómica fue comenzada por los autores (Valera & Becker, 2010; 2011).

El trabajo recorre los periodos Neolítico y Calcolítico, los cuales son muy interesantes tanto desde un punto de visto arqueológico como arqueoastronómico. El Neolítico es un periodo de cambios, muy profundos e importantes en muchos casos, como la transición a poblaciones sedentarias y el desarrollo de la agricultura. Fue también una época de revolución tecnológica y mental. El ritualismo, simbolismo y complejidad social, aparecen con fuerza.

Recintos de fosos son monumentos con una tendencia circular en su forma con varios recintos concéntricos, desde unos pocos de metros a varios centenares de diámetro. Los primeros descubrimientos se distribuyen a lo largo de una gran parte de Europa (especialmente en Alemania, Austria, y sur de Gran Bretaña), pero en la actualidad tenemos un incremento de este tipo de monumentos a lo largo de la Península Ibérica, generalmente porque las obras civiles las dejan al descubierto y por el aumento de investigaciones.

Tomaremos como ejemplo el yacimiento de Moreiros localizado en Arronches, Évora, con varias de estas construcciones, algunas de ellas llamadas recintos ondulados. Generalmente, las explicaciones de este tipo de yacimientos se han referido más a la gestión de la identidad grupal o a la distribución mundo simbólico, poniendo énfasis en el proceso de construcción en sí mismo, como un estimulante social. Otros han visto en estos yacimientos un reflejo de los asentamientos de grupos sedentarios en el que nos habla de su jerarquía en el territorio.

3. Datos astronómicos a representar

Una vez hecho un breve repaso a la situación actual de la Arqueoastronomía y su relación con la arqueología, vamos centrarnos en los datos astronómicos que tenemos disponibles y cuáles son susceptibles de ser útiles en estudios históricos En una primera aproximación, los datos más utilizados son:

Orto Helíaco de las estrellas brillantes y los planetas, para la determinación de coincidencias con las alineaciones presentes en la cartografía.
Datos de las circunstancias locales en eclipses de sol y luna, para la datación de fenómenos históricos
Azimut sobre el horizonte de orto, ocaso y paso por el meridiano del Sol durante los Solsticios y Equinoccios

Vamos a detenernos en cada uno de ellos y cómo hemos desarrollado una metodología de trabajo que nos permite obtener los datos astronómicos que son útiles al arqueólogo.

3.1 Ortos Helíacos
Este fenómeno consiste en la primera aparición de un objeto, una estrella brillante por ejemplo, por el horizonte este, después de su periodo de invisibilidad por haber estado cercano al Sol y el brillo de este no permite verlo. En el caso de los Ortos Helíacos, hemos tenido en cuenta la geometría descrita por Robert Purrington[11].

Figura 1. Geometría de la salida de un objeto celeste sobre el horizonte.

Como punto de partida, necesitamos tener cierto conocimiento sobre el perfil que se observa desde una posición determinada, en nuestro caso, el yacimiento. Para
reconstruirlo, hemos utilizado un Modelo Digital de Elevaciones (MDE) como base de la topografía. Para España estamos utilizando los productos MDT25 y MDT50 del IGN, y para el ejemplo que nos ocupa en este trabajo, la zona sur de Portugal, utilizamos el producto SRTM de la NASA [12]. Este proporciona modelos para todo el planeta, y se acaba de publicar hace unos días, la versión 2 del mismo. Ambos productos proporcionan libre acceso a sus datos. A partir de estos modelos, se reconstruye el horizonte visible desde el lugar del yacimiento usando software como gvSIG junto a la extensión SEXTANTE. Para corregir este perfil geométrico debido a la distancia al observador e integrar los datos astronómicos, hemos desarrollado varios programas auxiliares.

El siguiente paso consiste en determinar los puntos de salida y puesta del astro objeto de estudio. Esto implica a todos los cálculos astronómicos por lo que se hemos seguido el siguiente procedimiento:

Aplicar la corrección por movimiento propio de la estrella. Las estrellas tienen un movimiento en el cielo
Aplicar una corrección por precesión de la estrella. La precesión es debida al movimiento de cabeceo de la Tierra debido al fenómeno de Precesión de los Equinoccios, con un periodo de unos 25000 años. Este movimiento introduce variaciones en la posición de las estrellas, en función del momento de la observación.
Determinar el momento del Orto Heliaco. Esto teniendo en cuenta el brillo de la estrella, su distancia angular al Sol
Aplicar una corrección debida a la refracción atmosférica. Se produce un desplazamiento de la posición observada respecto a la real, debido a las condiciones atmosféricas del lugar. Estas no son conocidas en épocas remotas, pero se puede hacer una estimación aproximada.
Calcular el Azimut del punto calculado.

Para implementar este procedimiento de forma que sea posible llevar a cabo los cálculos astronómicos y representar estos puntos sobre un mapa, hemos desarrollado un conjunto de librería de software. Estas permiten llevar a cabo cálculos para fechas remotas, hasta el 5000 a.c., con una precisión cercana 1 minuto de arco, más que suficiente para contrastarlo con observaciones visuales, que son las que podemos esperar en esas épocas.

Para los cálculos de precesión, hemos aplicado el procedimiento descrito por Gómez 2006, y los posteriormente descritos por Vondrák et al., 2011 [13]. Para las correcciones por refracción hemos utilizado el método descrito en Explanatory Supplement [14]. Como referencia para las posiciones estelares y movimientos propios, hemos utilizado el catálogo FK5 [15]. También se puede utilizar el Bright Star Catalogue [16], para posiciones referidas al sistema de referencia J2000.0.

Hay ocasiones en las que los objetos no son estrellas, sino planetas. En estos casos la forma más sencilla de tener efemérides con alta precisión, es el programa JPL Horizons, que tiene una versión onĺine. Nosotros en este momento hemos pasado a desarrollar programas propios utilizando la teoría planetaria DE406. Esta nos permite obtener resultados referidos al International Celestial Reference Frame [17] y cubre el periodo desde el año 3000 a.c. Al 3000 d.c. Con la precisión suficiente descrita arriba.

Por último, se calcula la posición geocéntrica del objeto, se transforma en posición horizontal, para obtener el azimut del punto sobre el horizonte. En el caso del Sol, además de determinan los instantes de los equinoccios y solsticios, ya que estos han sido utilizados por diferentes culturas como marcadores de ciertos eventos en sus tradiciones.

Los programas devuelven, por lo general, datos tabulares, pero para nuestro trabajo necesitamos que estos tuvieran una traducción en la vertiente geográfica. Para ello hemos desarrollado un procedimiento para generar ficheros un gráfico que muestre tanto el horizonte del terreno como los puntos de orto y ocaso. Además generan un fichero Shapefile con las geometrías de los puntos y orientaciones de estos. Estos ficheros son los que utilizamos como capa astronómica y superponerlos a la información arqueológica.

3.2 Alineamientos
Una vez conseguida las efemérides que proporcionan el azimut de un orto u ocaso para diferentes objetos, y en varias épocas, se pueden llevar a cabo comparaciones entre estas y posibles alineaciones de las edificaciones entre sí o entre estas y elementos del horizonte.

Esto se lleva a cabo superponiendo la capa astronómica generada con el resto de capas creadas a partir de la información recogida en el yacimiento. Superponiendo las capas en la IDE, las líneas pueden ser alineadas y encontrar coincidencias.

3.3 Eclipses
Otro fenómeno astronómico de gran interés son los eclipses. Se han utilizado tradicionalmente en la datación de eventos históricos en los que se narraba la observación de estos fenómenos.

Para obtener las circunstancias locales de observación de un eclipse, instantes de comienzo y fin así como de su magnitud, utilizamos los Elementos Besselianos publicados para cada eclipse. Una solución más sencilla es utilizar cualquiera de los programas disponibles o el catálogo de Spenak y Meeus [18]

4. Uso de los datos astronómicos en una IDE Arqueológica

En este punto queda claro que la principal ventaja de utilizar esta herramienta es encapsular la complejidad del los cálculos astronómicos, proporcionando al arqueólogo la información útil que necesita. La comunidad arqueológica puede acceder a ellos integrándola como una capa más dentro de su IDE. Esto la convierte en un conjunto de datos fácil de usar, proporcionando datos de gran exactitud.

Como resumen, recogemos los pasos a llevar a cabo para integrar esta capa:

6. Calcular posiciones de objetos utilizando el software descrito, teniendo en cuenta factores astronómicos como la precesion, para diferentes épocas. La generación de efemérides puede ser bajo demanda en tiempo real, o almacenándolas. Estas efemérides son independientes del yacimiento al que se quieran aplicar.
7. A partir de la localización del yacimiento se hacen las correcciones incluyendo factores como la refracción atmosférica, calculándose así las circunstancias locales
8. Las circunstancias locales son realmente líneas, polilíneas o polígonos que se almacenen en ficheros shapefile o bases de datos espaciales.
9. A partir de estos repositorios espaciales se genera una capa completa que se pone disposición mediante un servicio WMS (Web Map Service) o WFS (Web Feature Service), servicios OGC interoperables. También es posible servirlas en formato GML, geoRSS o GeoJSON.

El arqueólogo solo tiene que incluir este servicio en su IDE para tener acceso a la capa concerniente a su yacimiento. Esta hará sido generada para la época y lugar elegidos y para los objetos astronómicos que se deseen incluir en el estudio.

Como resultado de la aplicación de estas nuevas capas a las ya existentes, arqueológicas y astronómicas, disponemos de una nueva herramienta para el análisis de los hallazgos en yacimientos arqueológicos, disponiendo de una línea de conocimiento acerca de la cultura de sus habitantes y su relación con el medio.

5. Arqueoastronomía en el Sur de Portugal

Como ejemplo práctico de generación de esta nueva capa con información astronómica, hemos elegido el proyecto que la Fundación Gulbenkian está llevando a cabo en algunos yacimientos del sur de Portugal, y que han sido descritos en el apartado 2.

Concretamente al yacimiento de Moreiros, localizado en Arronches, Évora, donde se encuentran construcciones cerradas con muros de forma ondulada. La metodología seguida ha unido técnicas GIS tradicionales, con mediciones sobre el terreno durante el mes de Agosto de 2011, junto a una prospección geofísica realizada con anterioridad, a la que hemos añadido la parte arqueoastronómica. Los elementos geofísicos fueron descritos en Mejuto et al, 2011[19].

Figura 2. Ubicación de Moreiros.

La primera peculiaridad de este proyecto reside en que el yacimiento no ha sido excavado, con lo que las estructuras no pueden ser orientadas sobre el terreno. Para conocer su disposición nos hemos referido a la prospección geofísica. Hemos obtenidos medidas GPS muy precisas para poder ubicarlo sobre la cartografía. A partir de estas mediciones obtuvimos las coordenadas geográficas y UTM ( EPSG: 25829). Para el modelo de elevaciones hemos utilizado el proporcionado por el SRTM para la zona.

Como mapa base de la zona se ha utilizado la cartografía proporcionada por el Instituto Geográfico Portugués, que ofrece servicios OGC para ello.

En paralelo a la toma de datos sobre el terreno se eligió estudiar el orto y ocaso solar durante los solsticios y equinoccios, para compararlo con alguna posible alineación. La fecha de referencia elegida fue el 4000 a.c.

Una vez generada la capa arqueológica a partir de la información geofísica y las posiciones GPS, se procedió al levantamiento del perfil del horizonte. Para ello se desarrollaron los programas necesarios para implementar la metodología descrita en los apartados 3 y 4. Por último se obtuvieron los gráficos de perfil de horizonte y capa shapefile con las líneas sobre el terreno con la orientación de los puntos.

Figura 3. Perfil del horizonte y posiciones del sol.

Figura 4. Capa Arqueoastronomía sobre planta arqueológica.

Como se puede ver en la figura 4, se han representado en rojo las líneas que indican los puntos de orto (a la derecha) y ocaso (a la izquierda), para los momentos de los equinoccios de primavera y otoño (puntos superiores e inferiores), y los solsticios (centrales), para el año 4000 a.c.. Las flechas verdes indican la ubicación de las puertas del recinto, que coinciden con algunos de estos puntos, para un observador situado en el centro del mismo. Esto lleva a pensar que fueron construidas en esa posición con cierta intención.

Como trabajo final, se publica la capa arqueoastronómica por medio de un servidor Geoserver en una intranet, para permitir a los investigadores el acceso a la información.

6. Conlusión

La aplicación de la Arqueoastronomía a los yacimientos arqueológicos supone una nueva herramienta de gran valor, al verse de forma palpable la relación entre fenómenos astronómicos y elementos de la cultura estudiada. Queremos destacar la oportunidad que ofrece la IDE como medio para la publicación de este tipo de información, permitiendo el uso de los complejos cálculos astronómicos dentro de un ámbito arqueológico.

Como trabajo futuro se abre la posibilidad de empezar a ofrecer este servicio en Internet, y pasar de efemérides calculadas para un lugar en concreto a cálculos bajo demanda y capas integrables en tiempo real en cualquier cliente IDE. Se está trabajando para crear un servicio WPS que cumpla con el estándar OGC.

Referencias

[1] Cerdeño, M. L., Rodríguez, G., Moya, P. R., Ibarra, A. & Herrero, S. Los estudios de Arqueoastronomía en España, estado de la cuestión, Trabajos de Prehistoria 63(2): 13-34. (2006)
[2] Belmonte, J. A. Arqueoastronomía Hispánica. Prácticas astronómicas en la Prehistoria de la Península Ibérica y los archipiélagos balear y canario, Equipo Sirius. (2000)
[3] Esteban, C. La Arqueoastronomía en España, Anuario del Observatorio Astronómico pp. 309-322. (2003)
[4] Wood, J. Choir Gaure, Vulgarly called Stonehenge, on Salisbury Plain.(1747)
[5] Stukeley,W. Stonehenge, a temple restor'd to the British Druids.(1740)
[6] Lockyer, J. N. (1909). Stonehenge and other British Stone monuments astronomically considered, Macmillan and Co., Limited. (1909)
[7] Thom, A. (1954). The solar observatories of megalithic man, Journal of the British Astronomical Association 64: 396-404.(1954)
[8] Thom, A. Megalithic sites in Britain, Oxford University Press. (1967)
[9] http://www.idearqueologia.org/GTT_PAH/?q=taxonomy/term/3
[10] Valera, A. & Becker, H. (2010). Arqueoastronomía, geofísica e recintos de fosos da prehistória recente no sul de portugal, Actas do 8 Encontro de Arqueología do Algarve.
[11] Purrington, R. Heliacal rising and setting: Quantitative aspects, Archaeoastronomy 12(1988)
[12] http://www2.jpl.nasa.gov/srtm/
[13] Vondrák, Capitane &Wallace New precession expresions, valid for long time intervals, Astronomy & Astrophysics manuscript . (2011)
[14] USNO . Explanatory Supplement to the Astronomical Almanac, University Science Books.(1992)
[15] Fricke, W., et al Fifth fundamental catalogue (FK5). part 1. the basic fundamental stars, Astronomisches Rechen-Institut 32.(1991)
[16] Hoffleit, D. & Warren Jr, W. . The Bright Star Catalogue, 5th Revised, Astronomical Data Center, NSSDC/ADC. (1991)
[17] C. Ma, et al "The International Celestial Reference Frame as Realized by Very Long Baseline Interferometry ", The Astronomical Journal 116 , p.516 (1998)
[18] Spenak, F. & Meeus, J.. Five millenium catalog of solar eclipses -1999 to +3000, JPL-NASA.(2009)
[19] Mejuto, J., Valera, A., Gómez Castaño, J., Rodríguez-Caderot, G. & Becker, H. (2011). Ditched enclosures in southern portugal: an archaeoastronomical point of view of Portuguese neolithic and chalcolithic, Stars and Stones: Voyages in archaeoastronomy and Cultural Astronomy - A meeting of different worlds.

Agradecimientos

Este trabajo ha sido desarrollado dentro del UCM910596 Research Group: "Grupo de estudios ionosféricos y técnicas de posicionamiento global por satélite (GNSS)" en el marco del proyecto Aplicación de la Interferometría Radar Satélite y los Sistemas Globales de Navegación por Satélites en Estudios sobre Control de Deformaciones de la Cordillera Bética (AYA2010-15501 (subprogram ESP)).

The Delft Report: Linked Data and the challenges for geographic information standardization

Tue, 07 Feb 2012 00:00:00 +0100

THE DELFT REPORT: LINKED DATA AND THE CHALLENGES FOR GEOGRAPHIC INFORMATION STANDARDIZATION

Francisco J. López-Pellicer¹, Luis M. Vilches-Blázquez², F. Javier Zarazaga-Soria¹, Pedro R. Muro-Medrano¹, Oscar Corcho²

1. Sistemas de Información Avanzados. Departamento de Informática e Ingeniería de Sistemas. Universidad de Zaragoza
2. Ontology Engineering Group. Departamento Inteligencia Artificial, Facultad de Informática. Universidad Politécnica de Madrid

1. Introduction

The resolution 532 of the 31st ISO/TC 211 plenary in Canberra mandated the creation of an ad-hoc group of experts to investigate whether to address the Web of Data and related issues, in particular Linked Data, in the geographic information standardization, and, if that is the case, to make recommendations for action. The group included experts from Australia, Canada, Germany, Italy, Finland, France, Korea, Spain, United Kingdom and USA. The first report of this group was presented to the 32nd ISO/TC 211 plenary held in Delft, Netherlands, on May 2011, hereafter the Delft Report [1]. The most significant recommendation of that report is to proceed with the use of Linked Data in geographic information standardization.

The addition of Linked Data to the geographic standards may produce effective cost savings in spatial data production and use by improving some issues relevant to Spatial Data Infrastructures (SDI), such as cross domain data sharing or spatial data discovery. The Delft Report's recommendations are the first step in that direction. This paper presents those recommendations in context, and evaluates their potential impact in SDIs.

2. The Web of Data

The Web is a system of interlinked hyperlinked documents build on top of the Internet. The Web of Data is a natural extension of the Web based on the W3C standards and best practices related to Semantic Web where structured data are interlinked in the same way as documents are linked on the Web.

2.1. The Semantic Web
The Web is based in three essential technologies: a system of globally unique identifiers known as URIs, the markup language for documents HTML (Hypertext Markup Language) and the networking protocol HTTP (Hypertext Transfer Protocol). The origin of the Web backs to the work of Berners-Lee and Cailliau in the 1990 at CERN. Eleven years later, Berners-Lee and colleagues proposed an extension oriented towards machine processable data: the Semantic Web [2]. The Semantic Web was initially focused on developing a single data interchange model named Resource Description Framework (RDF) with multiple serializations (RDF/XML, N3, Turtle, RDFa, etc.), a RDF query language (SPARQL) and notations for defining taxonomies (RDFS), ontologies (OWL) and rules (RIF) (see Table 1 for a complete overview).

The RDF data model is based on the idea of making statements about resources. These statements take the form of subject-predicate-object expression or triples. The subject is the name of a thing about which something is asserted. The predicate is a named property that expresses the relationship between the subject and the object. The object is a value or a resource associated to the subject by the predicate. Taxonomies, ontologies and rules can define classes and properties that help the understanding of statements. In turn, taxonomies, ontologies and rules can be related each other through statements that lead to discover additional knowledge. The statements can be stored in a repository of RDF data. These repositories are known as triplestores and can be built on top of a database or a file system. The content of those repositories can be exposed with a Web endpoint that implements the SPARQL Protocol, which enables the use of the SPARQL query language for querying the remote triplestore.

RDF	Resource Description Framework: a model based on subjectpredicate- object statements for data interchange.
OWL	Web Ontology Language: a family of languages for the encoding of ontologies (i.e. formal representation of knowledge).
SPARQL	SPARQL Protocol And RDF Query Language: a Web protocol for querying remote RDF stores and a RDF query language.
RDFa	RDF Annotations: a collection of attributes and processing rules for extending markup languages to embed RDF data.
SKOS	Simple Knowledge Organization System: a common data model for sharing and linking knowledge organization systems.
RDFS	RDF Schema: a language for the encoding of taxonomies (i.e. hierarchical classification scheme).
GRDDL	Gleaning Resource Descriptions from Dialects of Languages: a markup for declaring that an XML document embeds RDF data and for linking to algorithms for extracting this data.
POWDER	Protocol for Web Description Resources: a mechanism to discovery and describe Web resources.
RIF	Rule Interchange Format: a family of languages for the encoding of rules.
SAWSDL	Semantic Annotations for WSDL: a mechanism to enable semantic annotation of Web services descriptions in WSDL.

Table 1. The W3C Semantic Web standards.

2.2. Linked Data
In 2006, Berners-Lee proposed the idea of Linked Data [3]: a Web of Data that has almost the same properties of the Web where a data interchange model (RDF) replaces HTML. This means that data (its Web representation) can contains links to data located elsewhere on the Web. Moreover, he proposes to adhere to the REST [4] architectural style that governs the Web: request and responses are built around the transfer of representation of resources using the existing HTTP capabilities (e.g. authentication, caching, content type negotiation) and verbs (GET, POST, PUT, DELETE). This approach differs from other approaches, such as SOAP, where developers are encouraged to design arbitrary features disregarding those offered by HTTP. As a result, Linked Data enables large-scale integration of data over the Web because is aligned with the Web architecture. Additionally, as Linked Data is based on RDF, Semantic Web languages with strong logical foundations, such as OWL, allow modelling what data mean.

Figure 1. Linked Data rules are expectations of behaviour of agents and data publishers
required to make data interconnected on the Web.

Linked Data addresses identifier syntax, data access and data model, and proposes a data integration approach. Linked Data is often summarized in four principles (see Figure 1):

1. Use URIs as names for things. Not just any kind of URI. Only those URIs compatible with specifications of the Semantic Web can be used.
2. Use HTTP URIs so people can look up those names on the Web. That is, if a publisher uses a different schema¹, it tells people those names cannot be looked up.
3. Use dereferenceable HTTP URIs. When someone looks up a URI, provide useful information using the Semantic Web standards. That is, return a Web resource that is either a RDF data serialization (e.g. a static file, a SPARQL response), a Web resource with embedded RDF data (e.g. XHTML+RDFa), or a Web resource with a standardized transformation to RDF data (e.g. XML+GRDDL).
4. Include links to other URIs, so they can discover more things. Most of the links should be RDF links, that is, URIs that provide useful information. Links that provide alternate representations are also advised. For example, a RDF document that describes a geographic resource can provide a link to an ISO metadata document that describes the same resource. Other links can be deduced with the help of ontologies and rules.

The links introduced in the latter point are known as RDF links. They enable to navigate from a data item (e.g. a metadata record) within one data source (e.g. a catalogue) to related data items (e.g. a term) within other sources (e.g. a thesaurus) using a Web agent (e.g. a Web browser in the simplest scenario). RDF links can also be followed by the crawlers of general purpose and Semantic Web search engines. Linked Data is indexable. Therefore, Linked Data datasets are searcheable by means of simple (e.g. Google, Bing) or semantic-aware (e.g. Sindice) search engines. In addition, as RDF is serialized in a structured format (e.g. XML, JSON) it can be consumed by applications.

3. Linked Data for the ISO/TC 211

3.1. The Semantic Web at the ISO/TC 211 and liaised organizations
The ISO/TC 211 tasked a group in 2006 to investigate how Semantic Web approaches can benefit in the development of interoperable geospatial information. That group recommended in 2009 the revision of the TC/211 reference model and the development of rules for the development of notifies based on Semantic Web languages, among other recommendations. New projects have been initiated as consequence of those recommendations, such as the Project 19150-2 for developing ontologies with OWL. In relation to Linked Data, the 31st ISO plenary (2010) mandated the creation of an ad-hoc group to investigate that notion and its consequences for geographic information standardization. The recommendations of that group are discussed in this paper.

The most notable ISO/TC 211 liaised organization is the international industrial consortium OGC. The OGC has developed several Web standards that have been standardized by ISO/TC 211. The OGC Working Groups Geosemantics (2007) and GeoSPARQL Standard (2010) concentrate the work related to the Semantic Web. The mission of the Geosemantics group is to establish a semantic framework for representing and mediating the geospatial knowledge. The goal of the GeoSPARQL group is to define a vocabulary for representing geospatial data in RDF, and a function library for SPARQL that enables spatial queries.

It is remarkable that ISO/TC 211 and W3C, which maintains the Semantic Web standards, have no liaison agreement although W3C is liaised with other ISO technical committees, in particular ISO/IEC JTC 1 - Information Technology Standards and ISO TC 68 - Financial Services. Identical situation happens between OGC and W3C, which are only liaised for the standardization of SVG.

3.2. Linked Data in geographic information standards: benefits and potential pitfalls
Linked Data and geographic information standards share the same basic principle: to make data easier to discover and use. The Delft Report examines several potential benefits of Linked Data that have been acknowledged by other authors [5-8]:

Domain independence. ISO/TC 211 models are built on domain pillars, such as the General Feature Model [9]. Liked Data is domain agnostic and provides a common approach for the description of things. Moreover, Linked Data allows applying different perspectives and uses on the same data.
Data reuse. ISO/TC 211 standards do not address the integration of different kinds of data. Linked Data integrates data in a uniform manner delegating technical issues to the Internet and the HTTP protocol. Hence, spatial data and metadata can be discovered and reused by users of other domains.
Commons tools. ISO/TC 211 encodings (e.g. ISO 19139) require domain tools for processing and understanding. Linked Data uses common tools, where the treatment of domain data is delegated to specialized modules.

However, the report fails to examine potential pitfalls. For example, the report does not take into account that the hardware and software infrastructure required to process geo Linked Data is not mature yet.

3.3. Areas of concern
The Delft Report suggests some key areas of concern for ISO/TC 211:

Standards management. All or part of standards and specification content should be available as Linked Data. Conformance classes, tests, code lists, etc. should have their own dereferenceable HTTP URI.
Geographic data and metadata. Structured geographic data (e.g. features, sensors, coverages, metadata) should be identified with HTTP URIs and be available as RDF documents containing RDF links to related data.
XML encoding reuse. RDF provides for XML content as possible literal value. Hence, Linked Data community can reuse XML documents defined by XML schemas for encoding geographic information as XML literals. This feature opens new and unsuspected possibilities.
Liaisons. As it was said above, W3C and OGC are developing industrial standards related to Linked Data technologies and geographic information. Standardization work should be liaised with W3C and OGC.
Quality. RDF links raises concerns about data quality. The RDF model allows merging easily datasets of different provenance and characteristics. If this process is done without care, the quality may suffer.

3.4. Challenges
There are several challenges related to the adoption of Linked Data. The most relevant are described below. Some of them have been already tackled by the Project team 19150 Geographic Information - Ontology.

Identification. ISO/TC 211 standards should be revised to consider the use of HTTP URIs to identify things, such as concepts, features or metadata records. Moreover, as those URIs require stability and durability, the governance of URIs should be also considered. Well-defined rules shall govern the creation of new URIs.
Dereferencing identifications. HTTP URIs shall be dereferenceable at least to a RDF document, and it should be clear what an agent should expect to retrieve. For example, ISO/TC 211 shall maintain a Linked Data front end that dereferences identifications (e.g. GM_Point URI, MD_Metadata URI, FC_FeatureType) to the corresponding specification containing their definitions. Content negotiation may be used for selecting the format (e.g. RDF document, HTML page, PDF document).
Model transformation. ISO/TC 211 shall define vocabularies that support the description in RDF of geographic data and metadata, and a methodology for the transformation of existing models to RDF data, and vice versa. Ontologies (OWL) and rules (RIF) provide the necessary constructs for the transformations.
Data types. Data types provided by RDF or OWL are used for the representation of primitive values, such as integers, floats and strings. The support of user defined data types, such as geometries, is an open issue with different approaches. ISO/TC 211 shall define domain data types, such as point, polygon or geometry, and schemes of integration with the formal semantics of different semantic languages.

4. The Delft Report's recommendations

The Delft Report on Linked Data was presented to the 32nd ISO/TC 211 plenary held in Delft, Netherlands, on May 2011. The report addressed many of the issues discussed in previous sections and contained a number of recommendations. The recommendations to the ISO/TC 211 can be summarized in the following list:

1. Proceed to use of Linked Data in the standardization of geographic information.
2. Develop RDF vocabularies for different aspects of geographic information (e.g. terminology register, harmonized model).
3. Set up a well-defined Linked Data frontend for ISO/TC 211 concepts.
4. Review XML encodings to support their use as XML literals in RDF datasets.
5. Establish guidelines for the support of the use Linked Data liaised with W3C and OGC.

5. Linked Spatial Data Infrastructures

As mentioned before, Linked Data and SDIs share the same basic principle: (1) to provide a common approach for all kinds of data, and (2) to make data easier to discover, connect and use. Linked Data adds, for example, the possibility to crossdomain barriers enabling the linkage with other domain data (e.g. health, transport). Hence, there is an important cost saving recognition by publishing once and reusing multiple times.

Figure 2. Technologies and standards involved in a Linked Spatial Data.

Some authors consider that Linked Data can leverage discovery and use goals of SDIs [8, 10]. The more important aspect is that Linked Data allows SDI to integrate geographic information by lowering the barrier to reuse geographic and location data by third parties. A good example is the Linking Open Data (LOD) project². This project is an initiative originated in the W3C Semantic Web Education and Outreach interest group in 2007. The goal of the project is the creation of a data commons by publishing various open datasets based on the principles of Linked Data. As of September 2011, the Linking Open Data (LOD) project includes 295 data sets and consists of over 31 billion RDF triples, which are interlinked by around 504 million RDF links. The most notable of the LOD initiative is that it has attracted significant spatial data producers (e.g. Ordnance Survey - UK, National Geographic Institute - Spain, NASA). These producers have published their datasets as Linked Data enabling third parties to make RDF links to the contents of these datasets to assert the location of resources. In addition, large crowd-sourced geospatial databases (e.g. OpenStreetMap, GeoNames) have been published as Linked Data with links to the LOD datasets.

Figure 2 presents different strategies that can be considered for publishing data as Linked Data in a SDI. Structured data (e.g. sensor data, coverage data, feature data, metadata) can be exposed as RDF using one or several strategies depending on their amount and nature. For example, if the data is available through an API or exposed with and OGC Web service, it is possible to use a wrapper to expose the data as Linked Data. In some scenarios, where data is embedded in text (e.g. legacy metadata), entities can be retrieved with information retrieval tools and then structured and merged with existing RDF data. The ISO/TC 211 shall provide vocabularies, rules and guidelines for ensuring interoperability and consistent semantics across different SDIs.

6. Conclusions

The 32nd ISO/TC 211 plenary has requested the ad hoc group continue their work and report to the next plenary [11]. The work programme is to liaise with the ongoing work of OGC, in particular for the definition of shared vocabularies and the URI governance, to review XML encodings to determine potential conflicts with their use as XML literals in RDF, and to look about guidelines on the publication of standard geospatial information as Linked Data.

Linked Data will not replace existing service oriented solutions based on existing ISO/TC 211 standards. In fact, it is rather a disruptive technology for data reuse. That is, Linked Data would complement existing service oriented approaches by providing a Web-oriented infrastructure for broadcasting geospatial data and theirs semantics out of the geospatial community.

Acknowledgements. This work has been partially supported by the Spanish Government (CENIT 2008-1030, TIN 2009-10971, TIN 2010-10811-E), the Centro Nacional de Información Geográfica (CNIG) and the National Geographic Institute (IGN).

Bibliography
[1] Brodeur, J. (Chair): Linked Data - Report to 32nd ISO/TC 211 plenary, Delft, The Netherlands, May 26, 2011. Technical Report. ISO/TC 211 Ad hoc group on Linked Data. Delft, The Netherlands (2011)
[2] Berners-Lee, T., Hendler, J., and Lassila, O.: The Semantic Web. Scientific American 284(5): 34-43 (2001)
[3] Berners-Lee, T.: Linked Data - Design Issues, (2007). http://www.w3.org/DesignIssues/LinkedData.html
[4] Fielding, R. and Taylor, R.: Principled design of the modern Web architecture. ACM Trans. Internet Technol. 2(2): 115-150 (2002)
[5] Smits, P.: Linked Open Data and Spatial Data Infrastructures. EcoInformatics Linked Open Data workshop (2010). http://tinyurl.com/28poe5d
[6] Murray, K., Sheridan, J., Hart, G., Tennison, J., Goodwin, J., Davidson, P., et al.: Linked Data and INSPIRE - extending the benefits of data . INSPIRE Conference 2010 - INSPIRE as a Framework for cooperation, Krakow, Poland (2010)
[7] Lopez-Pellicer, F.J, Silva, M.J., Chaves, M., Zarazaga-Soria, F.J., and Muro-Medrano, P.R.: Geo Linked Data. Database and Expert Systems Applications, 21st International Conference, DEXA 2010, Bilbao, Spain, August/September 2010, Proceedings, Part I. Lecture Notes in Computer Science, 6261: 495-502 (2010)
[8] Hjelmager, J., Moellering, H., Delgado, T., Cooper, A., Rajabifard, A., Rapant, P., et al.: An initial formal model for a Spatial Data Infrastructure. International Journal of Geographical Information Science. 22(11/12), 1295-1309 (2008)
[9] Kresse, W., Fadaie, K.: ISO Standards for Geographic Information. Springer, Berlin (2004)
[10] Cox, S., Schade, S., and Portele, C.: Linked Data in SDI. INSPIRE Conference 2010 - INSPIRE as a Framework for cooperation, Krakow, Poland (2010)
[11] ISO/TC 211 plenary: Resolutions from the 32nd ISO/TC 211 plenary meeting in Delft, The Netherlands, 2011-05-26/27, Resolutions, ISO/TC 211, Delft, The Netherlands (2011) http://www.isotc211.org/opendoc/211n3148/

Notes

1. The OGC uses the urn schema for naming persistent resources. See http://www.opengeospatial.org/ogcna
2. http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

La aportación española en el proyecto EuroGEOSS: Hacia un sistema de observación ambiental de la Tierra

Tue, 07 Feb 2012 00:00:00 +0100

LA APORTACIÓN ESPAÑOLA EN EL PROYECTO EUROGEOSS: HACIA UN SISTEMA DE OBSERVACIÓN AMBIENTAL DE LA TIERRA

Carolina de Carvalho Cantergiani¹, José Miguel Rubio², Cristina Zamorano¹, Laura Díaz³, Miguel Ángel Latre⁴, Javier Nogueras⁴, Rogelio Galván⁵

1. Observatorio de Sostenibilidad de España
2. Instituto Geográfico Nacional
3. Instituto de Nuevas Tecnologías de la Imagen. Universitat Jaume I
4. Grupo de Sistemas de Información Avanzados. Universidad de Zaragoza
5. Confederación Hidrográfica del Ebro

1. Introducción. ¿Qué es EuroGEOSS?

EuroGEOSS es un proyecto del 7.º Programa Marco de la Comisión Europea cuyo objetivo es la creación de un Sistema de Observación Ambiental de la Tierra que se desarrollará en las áreas temáticas de Cubierta Forestal, Sequía y Biodiversidad. Este proyecto cumplirá los requisitos de INSPIRE y SEIS, y las normas que aseguran la coherencia entre GEOSS (Global Earth Observation System of Systems), INSPIRE (Infraestructure for Spatial Information in Europe) y GMES (Global Monitoring for Environment and Security) y se desarrollará en base a sistemas, recursos y servicios ya existentes o que tengan previsto su lanzamiento en breve en Europa. El proyecto persigue la interoperabilidad multidisciplinar, es decir, que la información de diferentes disciplinas sea comparable y compatible, facilitando la toma de decisiones.

Así, en el contexto del proyecto se establece una Capacidad Operativa Inicial (IOC - Initial Operating Capacity) en estas tres áreas, que debe evolucionar hacia una Capacidad Operativa Avanzada (AOC - Advanced Operating Capacity). Esta AOC reflejará como resultado la interoperabilidad multidisciplinar entre las tres áreas implicadas, que debe permitir el acceso no sólo a datos sino también a modelos analíticos que puedan ser empleados por científicos de diferentes ámbitos. Entre otros, la AOC contempla el uso de lenguaje natural, estrategias avanzadas de búsqueda y conceptos web 2.0.

Este proyecto tiene más de seis millones de euros de presupuesto y en él participan 22 organismos de 10 países distintos. Los socios españoles son la Universidad de Zaragoza, la Universitat Jaume I de Castellón, el Instituto Geográfico Nacional a través del CNIG, la Confederación Hidrográfica del Ebro, el CSIC a través del Instituto Pirenaico de Ecología y el Observatorio de la Sostenibilidad de España. Está estructurado en siete paquetes de trabajo: además de los tres temáticos, hay otros cuatro grupos dedicados a coordinación, interoperabilidad multidisciplinar, evaluación de beneficios y diseminación (figura 1). Lanzado oficialmente en mayo de 2009, su finalización está prevista para abril de 2012.

Figura 1: Estructura general del proyecto EuroGEOSS.

2. Interoperabilidad multidisciplinar

La creciente preocupación por un desarrollo sostenible hace cada vez más necesaria una monitorización exhaustiva del estado de nuestro planeta para estudiar el medioambiente desde un punto de vista multidisciplinar [1] [2].

Científicos y expertos necesitan datos y herramientas disponibles de forma global. En este sentido, las Infraestructuras de Datos Espaciales (IDE) se han convertido en herramientas necesarias para trabajar con información medioambiental proporcionando un marco para el análisis multidisciplinar [3]. En este contexto, la interoperabilidad debe ser garantizada por una serie de esfuerzos en el uso de estándares como las normas ISO / TC211 y OGC [4] y otros marcos de interoperabilidad como INSPIRE y GEOSS.

EuroGEOSS aborda el concepto de interoperabilidad multidisciplinar investigando la extensión de las IDE con componentes estandarizados e interoperables que aporten capacidades operacionales avanzadas como servicios de datos multi-escala, modelos medioambientales desplegados como cadenas de servicio de geo-procesamiento, estrategias de búsqueda avanzada e interfaces de lenguaje natural e integración de recursos Web 2.0, con el fin de mejorar la interacción de recursos multidisciplinares.

En particular, el objetivo del paquete de trabajo dos (WP2, ver Figura 1) es garantizar la interoperabilidad multidisciplinar entre las tres áreas temáticas. La figura 2 muestra el punto de partida (cajas redondeadas), tareas (en azul claro) y las dependencias con otros paquetes de trabajo (azul oscuro).

Figure 2. Paquete de trabajo sobre Interoperabilidad

Empezando con la definición de requisitos, en cooperación con los expertos en las áreas temáticas, EuroGEOSS desarrollará la IOC para la interoperabilidad multidisciplinar. La infraestructura basada en el marco desarrollado por GEOSS, tomará como requisitos también desarrollos relacionados con INSPIRE y otras iniciativas Europeas (GMES, SEIS) a través de la información obtenida del proyecto GIGAS.

Otras tareas de este paquete de trabajo desarrollan componentes interoperables y multidisciplinares para la evolución de la capacidad inicial a una capacidad avanzada, como son el modelado de flujos de trabajo avanzado y el procesamiento distribuido, el modelado integrado de recursos multi-escala, un módulo de lenguaje natural que incluye un modulo de extensión y mejora de la semántica de las consultas a través de la definición de ontologías avanzadas en los dominios pertinentes, así como la investigación y desarrollo de mecanismos de búsqueda alternativos y la integración de recursos Web 2.0 en el contexto de las IDE.

Este paquete liderado por el Consiglio Nazionale delle Ricerche (CNR) ofrece unos componentes software en su mayoría integrados en lo que se ha llamado el enfoque Broker. Su principal protagonista, el EuroGEOSS Discovery Broker, es un componente que ofreciendo diferentes interfaces basadas en especificaciones estándar permite la búsqueda de recursos previamente registrados y disponibles a través de servicios de descubrimiento y de datos. De este modo, en el resto de paquetes de trabajo, los sistemas existentes han registrado sus servicios y datos en una instancia de este componente para estar accesibles en sus propios sistemas, para el resto de sistemas de EuroGEOSS y, en general para los usuarios de GEOSS. Además, se ha diseñado también el Web 2.0 Broker [5] para facilitar a usuarios del EuroGEOSS Discovery Broker el acceso a recursos web 2.0 aportando el componente social de eventos medioambientales. En la línea de acercar el mundo IDE al ciudadano, en este caso, reduciendo la complejidad para la publicación de datos y el mantenimiento de las IDE, se ha trabajado en el GEOSS Service Factory (GSF) [6] como un servicio de publicación desplegado en infraestructuras compatibles con GEOSS e INSPIRE.

3. Capacidad Operativa en Cubiertas Forestales

La disponibilidad y el acceso a datos y servicios relativos a la cubierta forestal es esencial no sólo para la monitorización del medio ambiente sino también para la gestión de recursos energéticos, el análisis del impacto del cambio climático, el estudio de la biodiversidad, el control de incendios, el impacto de la deforestación y en general la gestión del territorio.

Pese a la existencia de una gran variedad de conjuntos de datos relativos a cubiertas forestales, a menudo es difícil acceder a ellos y utilizarlos debido a la falta de conexión entre los sistemas y los datos que existen a nivel local, regional y global. Por ello, y para satisfacer la demanda de una mayor interoperabilidad entre los sistemas existentes, EuroGEOSS ha trabajado en extender las capacidades de datos y servicios locales, regionales y globales para convertirlos en una base de datos global y distribuida de recursos forestales.

Para el desarrollo y testeo del sistema se han identificado hasta 40 servicios y conjuntos de datos locales de diversas organizaciones españolas, los prototipos del Centro Europeo de Datos Forestales (European Forest Data Centre - EFDAC) y del Observatorio para las Cubiertas Forestales del África Central (Observatory for Central African Forests - OFAC) así como los datos a escala global del proyecto TREES y de la FAO. Estos recursos serán integrados en un sistema que desarrolle la IOC, en la que se han implementado herramientas estándar y de web 2.0 para el análisis, visualización y modelado de datos en la temática forestal. Siguiendo el enfoque del EuroGEOSS Discovery Broker (ver sección 2), estos recursos se han integrado en el mismo con el fin de estar disponibles a través de una interfaz de búsqueda interoperable, para ofrecer acceso no solo dentro de esta área temática.

En una primera fase del proyecto se ha desarrollado un geoportal con un visualizador de mapas (EuroGEOSS Forest Map Viewer) que permite acceder y superponer una gran variedad de servicios estándar WMS y WFS de datos forestales y de biodiversidad.

Figura 3. Visualizador de Mapas de la Componente Forestal de EuroGEOSS
(http://193.126.113.48/eurogeoss_forest.html)

Para facilitar la búsqueda y descubrimiento de recursos de esta temática se ha implementado un catálogo de metadatos, basado en el software Open Source de GeoNetwork, que contiene los registros correspondientes al EFDAC así como los referentes a datos forestales existentes en los catálogos CSW de datos y servicios de la IDEE [7]. El catálogo de metadatos y el geoportal están integrados de modo que un usuario puede visualizar recursos desde el propio catálogo, siempre que los metadatos de servicio incluyan la información necesaria para el enlace al servicio web OWS.

Para dotar de capacidades avanzadas al sistema, constituyendo una AOC, se ha desarrollado un servicio web de procesamiento (WPS) que facilita el análisis geoespacial de información geográfica con herramientas tales como la generación de buffers, reproyección de datos vectoriales y ráster, cálculo de punto en polígono, intersección, unión y disolución. Este servicio a su vez utiliza otros componentes de software como GRASS-GIS, GDAL/OGR o R-Statistics.

La implementación del WPS de cubiertas forestales se llevó a cabo teniendo en cuenta los requerimientos establecidos en los distintos escenarios de uso (ej. cálculo de superficie quemada en áreas protegidas, por tipo de cubierta o por especie de árbol, cálculo de ganancia y pérdidas, cálculo de correlación entre índices de sequía y el FWI (Forest Weather Index y tendencias).

Finalmente y para demostrar el valor añadido que proporciona la información geográfica voluntaria (Volunteered Geographic Information - VGI), en concreto en el escenario de uso de incendios forestales, se han integrado servicios y recursos web 2.0 tales como OpenStreetMap, YouTube, RSS o Twitter, como mecanismos complementarios para asistir en la detección temprana de incendios forestales, el seguimiento en tiempo real de la evolución del incendio o la monitorización posterior al evento.

4. Capacidad Operativa en Biodiversidad

Las áreas protegidas juegan un papel esencial en los programas de conservación y en el uso sostenible de los recursos naturales. Las capacidades operativas en biodiversidad de EuroGEOSS se centran en la Herramienta de Evaluación de Áreas Protegidas en África (APAAT - African Protected Areas Assessment Tool), que es un sistema de información online que permite evaluar el estado de las áreas protegidas.

La base de datos disponible en este eje temático cuenta con información sobre 741 áreas protegidas de 50 países, con información de más de 1600 especies y un amplio rango de datos climáticos, ambientales y socioeconómicos.

La IOC de este paquete de trabajo se alcanzó por el desarrollo de una serie de catálogos de metadatos y servicios, integrados en el EuroGEOSS Discovery Broker. Se destaca el desarrollo del catálogo de metadatos para el GBIF (Global Biodiversity Information Facility) con el uso del Ecological Metadata Language para suplir las necesidades de la comunidad, especialmente en cuanto a las bases de datos de nombres de especies y colecciones de historia natural.

En paralelo, se desarrolló el Observatorio Digital para Áreas Protegidas (DOPA - Digital Observatory for Protected Areas), una herramienta con enfoque en África, pero con alcance global como parte de la red de observación GEOBON. El DOPA es una herramienta basada en los conceptos de APAAT, y permite la monitorización de áreas protegidas a través del procesamiento de datos obtenidos de varios servicios web, aglutinando una variedad de sensores, bases de datos y sistemas. También está concebido como un conjunto de bases de datos distribuidas y sistemas web abiertos e interoperables.

Figura 4. DOPA - Digital Observatory for Protected Areas

Otro producto importante de este paquete de trabajo es el desarrollo del WPS eHabitat, que es un generador del Habitat irReplaceability Indicator (HRI) para cada área protegida, representada en forma de mapas asociados a cada una de las 741 áreas protegidas africanas. Dicho WPS refuerza la interoperabilidad multidisciplinar con los demás paquetes de trabajo, facilitando la derivación de nuevas bases de datos a partir de datos existentes y modelos científicos [8].

5. Capacidad Operativa en Sequías

Los principales objetivos del área temática de sequías son:

explorar y definir acuerdos de interoperabilidad para los sistemas de información sobre sequías de Europa
establecer mecanismos de interoperabilidad entre el Observatorio Europeo de la Sequía (European Drought Observatory, EDO) y la información sobre sequías a niveles nacional y regional
contribuir en la investigación multidisciplinar con otras áreas temáticas de EuroGEOSS
facilitar el acceso a la información europea sobre sequías a través de GEOSS.

Para alcanzar estos objetivos ha sido necesario establecer una IOC en la que se ha requerido identificar conjuntos de datos relacionados con sequías, desplegar un conjunto de servicios para su visualización (WMS) y acceso (WFS, WCS), poner en marcha un catálogo de metadatos (y un conjunto de aplicaciones asociadas al mismo), y construir un portal para facilitar el acceso integrado a esta capacidad operativa.

En cuanto a la información, se han identificado aproximadamente unos 210 conjuntos de datos a nivel regional (CHE, DMCSEE), nacional (OSE-MARM) y europeo (JRC EDO). Respecto al despliegue de servicios, se ha facilitado el acceso a 22 servicios de visualización (WMS) y acceso (WFS, WCS). En relación a los servicios de mapas, merece la pena destacar el esfuerzo realizado en la internacionalización gracias al uso de conectores especializados. Estos conectores6, desarrollados por el BRGM para el proyecto OneGeology, extienden las capacidades de los servicios web de OGC con funcionalidad para dar soporte a varios idiomas y para realizar conversiones entre diferentes modelos de representación de la información en GML.

En relación a la puesta en marcha de un catálogo de metadatos [9] y las aplicaciones asociadas al mismo que faciliten la anotación y búsqueda de recursos de sequías, se han abordado los siguientes componentes:

La adaptación del editor de metadatos CatMDEdit para la anotación de datos y servicios conforme a las reglas de implementación de INSPIRE y a la norma ISO 19115. En el curso del proyecto, el CatMDEdit ha sido mejorado para incluir la anotación automática de servicios de OGC y actualizado con un vocabulario especializado en sequías (EuroGEOSS Drought Vocabulary) [10] y los dos vocabularios generales utilizados en el proyecto: GEMET y la compilación de categorías y subcategorías de las Áreas de Beneficio Social de GEOSS (Societal Benefit Areas - SBA).
La implementación de un servicio de catálogo de metadatos conforme con la especificación Catalogue Services for the Web (OGC CSW v.2.0.2) de OGC y su perfil ISO 19115/19119. Para ello se ha utilizado CatalogCube, software Open Source que pertenece a la iniciativa SpatiumCube¹. Esta tecnología ha sido mejorada para su integración con el broker de búsqueda de EuroGEOSS y el cumplimiento de las recomendaciones de INSPIRE relativas a la búsqueda de servicios.
El desarrollo de una aplicación web para la búsqueda y actualización de los contenidos del catálogo de metadatos [11]. Siguiendo los requisitos de GEOSS para la búsqueda en su infraestructura común, esta aplicación web permite realizar búsquedas basadas en localización, texto, categorías y subcategorías SBA y parámetros temporales. También puede buscarse por tipo de recurso (datos o servicio) y se existe la posibilidad, en el caso de servicios y de datos cuyos metadatos contienen información acerca de servicios que los visualizan, de acceder directamente a la página del visualizador de mapas del EDO para su visualización.

Figura 5. Portal del Observatorio Europeo de Sequía (EDO)

Finalmente, se ha desarrollado un portal Web para facilitar un acceso integrado a todos los componentes de esta capacidad operativa. Se ha probado que esta infraestructura técnica permite la integración de observatorios de sequía regionales y nacionales con el prototipo del Observatorio Europeo de Sequías [12].

6. Conclusiones: impacto de EuroGEOSS y trabajo futuro

Aunque el proyecto está todavía en marcha, los resultados producidos hasta el momento constituyen una importante aportación europea a GEOSS y un destacado avance en la interoperabilidad temática y multidisciplinar en las tres áreas temáticas de Cubierta Forestal, Sequía y Biodiversidad.

El trabajo coordinado en el proyecto entre miembros de diferentes administraciones públicas, potenciales usuarios, investigadores en las tres áreas temáticas y centros de investigación en ingeniería del software ha permitido un importante avance tanto en la interoperabilidad entre sistemas y componentes, como en la interoperabilidad semántica tanto dentro del ámbito de cada área temática como entre ellas.

A través del EuroGEOSS Discovery Broker es posible acceder a todo el conjunto de servicios y datos de las tres áreas temáticas así como recursos Web 2.0, utilizando también vocabularios y ontologías que permiten, semánticamente, avanzar en la consecución de la interoperabilidad multidisciplinar, principal objetivo de este proyecto.

Por todo ello, los avances en el proyecto EuroGEOSS constituyen una aportación importante a la Infraestructura de Datos Espaciales Europea en el campo de la interoperabilidad multidisciplinar, conforme a INSPIRE, GEOSS, ISO y OGC. EuroGEOSS representa una de las primeras propuestas de materialización en el proyecto GEOSS, consolidando el desarrollo de esta iniciativa a nivel internacional.

De cara a la difusión de los resultados del proyecto, y con la intención de servir de foro para otros proyectos europeos relacionados con las Ciencias de la Tierra, está prevista la celebración de una Conferencia llamada "EuroGEOSS: Advancing the vision for GEOSS". Debido al importante peso de los socios españoles en el consorcio, este evento tendrá lugar en las instalaciones del Centro de Ciencias Humanas y Sociales del CSIC en Madrid, en enero de 2012.

Nota

1. http://sourceforge.net/projects/exows/

Agradecimientos. Estos trabajos han sido cofinanciados por la Comisión Europea FP7-ENV2008 a través del proyecto EuroGEOSS - FP7 Project nº 226487.

Referencias

[1] Goodchild, M.F.: Geographic information science: the grand challenges. In: Wilson, J.P., Fotheringham, A.S. (eds.) The Handbook of Geographic Information Science. Malden, MA, Blackwell, pp. 596--608 (2008)
[2] Craglia, M., Goodchild, M.F., Annoni, A., Câmara, G., Gould, M., Kuhn, W., Mark, D.M., Masser, I., Maguire, D.J., Liang, S., Parsons, E.: Next generation Digital Earth. A position paper from the Vespucci Initiative for the Advancement of Geographic Information Science. International Journal of Spatial Data Infrastructure Research. 3, pp. 146--167 (2008)
[3] Ramamurthy, M.K.: A new generation of cyberinfrastructure and data services for earth system science education and research. Advances in Geo Science (2006)
[4] Bernard, L., Einspanier, U., Lutz, M., Portele, C.: Interoperability in GI Service Chains The Way Forward. In: Gould, M., Laurini, R., Coulondre, S. (eds) 6th AGILE Conference on Geographic Information Science. Lyon, pp. 179--188 (2003)
[5] Núñez-Redó, M., Díaz, L., Gil, J., González, D., Huerta, J.: Discovery and Integration of Web 2.0 Content into Geospatial Information Infrastructures: A Use Case in Wild Fire Monitoring First international Conference on Massive Information Sharing and Integration. In: Lecture Notes in Computer Science. 6908 - Availability, Reliability and Security for Business, Enterprise and Health Information Systems, pp. 50--68 (2011)
[6] Díaz, L., Schade, S.: GEOSS Service Factory: Assisted Publication of Geospatial Content. In: Lecture Notes in Geoinformation and Cartography. 1, Vol.1 - Advancing Geoinformation Science for a Changing World, Part 6, pp. 423--442 (2011)
[7] IDEE - Infraestructura de Datos Espaciales de España, http://www.idee.es
[8] Wheeler, T.: Collaborative Multidiscipline/Multiscale Analysis, Modeling, Simulation and Integration in Complex Systems: System Biology. In: Computational Science and Its Applications-ICCSA, pp. 654--664 (2006)
[9] EuroGEOSS: D.5.2. Metadata catalogue for drought information (2010), http://www.eurogeoss.eu/Documents/EuroGEOSS_D_5_2.pdf
[10] Latre, M.Á., Hofer, B., Lacasta, J., Nogueras-Iso, J.: The development and interlinkage of a drought vocabulary in the EuroGEOSS interoperable infrastructure. In: International Journal of Spatial Data Infrastructures Research (IJSDIR) (en revisión)
[11] UNIZAR: Catálogo de Metadatos, http://eurogeoss.unizar.es/Search/Search.html
[12] Observatorio Europeo de Sequías, http://edo.jrc.ec.europa.eu

Hacia la integración de gestión documental e información espacial

Moreno, R., Quintanilla, A., Sánchez, J. — Tue, 07 Feb 2012 00:00:00 +0100

HACIA LA INTEGRACIÓN DE GESTIÓN DOCUMENTAL E INFORMACIÓN ESPACIAL

Raúl Moreno, Antonio Quintanilla, Javier Sánchez
Instituto de Desarrollo Regional. Universidad de Castilla-la Mancha

1. Introducción

De manera similar a cómo una Infraestructura de Datos Espaciales (IDE) proporciona un paradigma de organización y acceso respecto de la información geográfica, la Gestión de Contenido Empresarial (ECM, por su sigla en inglés) proporciona lo propio respecto de documentos e información general. La ECM es un conjunto formado tanto por prácticas metodológicas (e. g. la digitalización de documentos en papel) como por herramientas (eventualmente agrupadas en un único paquete software). De entre estas últimas una herramienta esencial se corresponde con el gestor de documentación (DMS, por su sigla en inglés), i. e. con el software que se encarga de controlar el almacenamiento en repositorio, el acceso, el flujo de trabajo, y el versionado asociados a cualquiera de los documentos de interés para la entidad administrativa o empresarial involucrada.

En la actualidad existen varias opciones DMS, ya sea en forma de productos exclusivamente dedicados a ese rol, como por ejemplo DSpace, o en forma de productos ECM que lo incluyen, como por ejemplo OpenText Suite. La mayoría de tales opciones conllevan licencias económicamente costosas u ofrecen licencias gratuitas pero no las funcionalidades requeridas para un DMS de garantías. Sin embargo, una excepción la constituye Alfresco Community Edition [1], que supone una licencia gratuita sin perjuicio alguno de las funcionalidades necesarias; este producto es comúnmente aceptado como uno de los mejores software ECM de código abierto y ha sido evaluado favorablemente por varios autores, siendo Nijman [2] una muestra.

La consideración de datos espaciales dentro de la ECM, en general, y dentro de la gestión documental, en particular, significa una mejora ostensible de los beneficios aportados por éstas a la entidad sobre la que se instauran. Nótese que implica posibilitar enlazar con localizaciones geográficas (con geometrías, en la práctica) los documentos gestionados, consiguiendo de ese modo abrir un nuevo abanico de interesantes aplicaciones para los usuarios finales. Así, un usuario puede consultar las localizaciones asociadas a un documento y análogamente los documentos asociados a una localización. Ejemplos de áreas de aplicación son el turismo (e. g. acceder a la carta de un restaurante al seleccionarlo sobre el mapa), la seguridad pública (e. g. ver en el mapa el lugar de los hechos al seleccionar un documento relativo a una denuncia) o el mundo empresarial (e. g. obtener documentos pertenecientes a las sedes corporativas que estén situadas en una región seleccionada sobre el mapa), existiendo otras muchas como señala Sherman [3].

No obstante, la integración ECM/SIG no queda exenta de desafíos; entre ellos destaca el criterio a emplear para la indexación espacial de los documentos, la comunicación entre los distintos componentes software implicados, la interacción de los usuarios con el sistema final resultante y la adecuada modificación/extensión del DMS empleado.

Proponemos una infraestructura que integre sistema de información geográfica (SIG) y DMS con un coste económico de implantación significativamente bajo. Hemos elegido Alfresco como DMS a emplear y adicionalmente hemos implementado un módulo de extensión para incluir como documentos gestionados en este DMS capas en formato vectorial; a pesar de que en el tratamiento interno existan diferencias respecto de los documentos convencionales, el usuario puede acceder a ellas e incluso modificarlas mediante programas SIG sin percibir estas diferencias y abstrayéndose de la complejidad inherente a ellas.

El resto de este artículo se estructura como sigue. La sección 2 pone de manifiesto una revisión de la literatura referente a la integración DMS/SIG. En la sección 3 se describe la arquitectura general de la infraestructura que nos planteamos materializar, así como se analiza someramente cada uno de los componentes implicados. La sección 4 describe el mecanismo que hemos llevado a cabo para conseguir la adecuada inclusión de capas vectoriales en el repositorio del gestor. Finalmente, en la sección 5 quedan indicadas las conclusiones derivadas.

2. Trabajos relacionados

En los últimos años se han llevado a cabo varios esfuerzos relacionados con crear arquitecturas que incorporen información espacial en la gestión documental y/o en la ECM. Asimismo, existe constancia de la implementación de varios sistemas al uso.

Hasta donde conocemos, el trabajo de Swenson [4] es la primera aproximación importante al problema. En ella se describe la creación de un sistema para facilitar el trabajo de la División de Permisos de la ciudad de Indianapolis (EE.UU.). Plantea emplear la localización geográfica de los documentos relativos a permisos de construcción, en la indexación de éstos y por ende posibilita su acceso vía mapa. Deja patente el beneficio que esto supone gracias al análisis de las situaciones más usuales a las que se enfrentan los funcionarios en relación con dichos permisos. Gracias a esta temprana experiencia se pueden vislumbrar algunas vicisitudes que pueden surgir en la integración que nos ocupa; no obstante, la solución de Swenson está sesgada hacia el escenario de aplicación y el gestor de documentación considerado resulta harto primitivo.

Algo más sofisticado que el anterior es el tipo de DMS considerado por Crosswell en [5], donde se exponen teóricamente los desafíos a los que la instauración de un DMS se puede enfrentar, inclusive la integración con un SIG. En la misma línea se sitúa el trabajo de Nordheimet al. [6], en el cual toda una serie de datos empíricos relativos a distintas soluciones ECM son empleados para extraer (entre otros hechos) que la integración con SIG es requerida a menudo.

Algunas experiencias más actuales de implantación de sistemas reales que integren gestión documental e información espacial son revisadas a continuación. Para facilitar la revisión hemos optado por agruparlas según el tipo de aplicación al que queden orientadas, considerando los siguientes: aplicaciones de información patrimonial, aplicaciones de turismo, aplicaciones de gestión urbana, y aplicaciones genéricas.

Con respecto a la información patrimonial, el sistema de Hosse et al. [7] es probablemente uno de los acercamientos pioneros. Fue desarrollado por la Universidad Tecnológica de Múnich para el estado federado de Baviera (Alemania) y no emplea un DMS sino que maneja independientemente los documentos geo-referenciados. La descripción de un sistema similar es realizada por Gaio et al. [8]; tampoco se emplea un DMS, en su lugar un corpus sin operaciones (i. e. un repositorio estático) es utilizado. Por último, en [9] se puede acceder al Sistema de Información Patrimonial creado por el Consorcio de Santiago de Compostela. Tal sistema emplea OpenText Content Server para la gestión documental y ArcGIS para la parte SIG.

Con respecto a los sistemas orientados a turismo, hasta donde conocemos todos efectúan la integración con un Sistema de Gestión de Contenidos (CMS, por su sigla en inglés); ninguno la efectúa con un DMS. Nótese que la utilización de CMS impide, entre otras funcionalidades, mantener un control de versiones de los documentos geo-referenciados. A modo ilustrativo de trabajos que realizan integraciones en ese sentido valga comentar los llevados a cabo por Ahlers et al. [10], por Rioja et al. [11] y por Rojas-Sola et al. [12]. El primero está enfocado hacia dispositivos móviles y su objetivo es proporcionar al usuario información geo-localizada relativa a distintos lugares de interés turístico de la región de Montafon (Austria), pudiendo tratarse tanto de información en texto como de información multimedia (narraciones sobre el lugar). El segundo se refiere a GeoSistur, que consiste en una plataforma web de información turística; una de sus características más destacables queda ligada a la capacidad del usuario de consultar contenidos cercanos a una localización ordenados por distancias. El tercero concierne a la obtención de una herramienta para museos virtuales; utiliza Joomla como CMS y resulta destacable que permite al usuario interactuar con realidad virtual aumentada.

Con respecto a la gestión urbana, han sido realizados bastantes sistemas similares al de la primigenia experiencia de Indianapolis. Por ejemplo, Gharaibeh et al. presentan en [13] un sistema de apoyo a la gestión del drenaje de aguas pluviales de la ciudad de El Paso (EE.UU.). El mismo aborda entre otras cuestiones la geo-localización de documentos asociados a las diferentes estructuras de drenaje. Está centrado en la parte SIG y no utiliza DMS alguno sino que los documentos son gestionados en un repositorio propio creado a propósito. Otro ejemplo en esta línea de aplicación es el realizado por Hale et al. [14] y queda destinado a la gestión de peticiones/quejas al Buro de Aguas y Aguas Residuales del Departamento de Trabajos Públicos de la ciudad de Baltimore (EE.UU.). En tal trabajo se contempla la integración SIG con ECM al completo (i. e. incluyendo la gestión documental, el control de flujos de trabajo, etc.); para cada parte se utiliza respectivamente ArcGIS Server y el gestor OnBase. Sin tener en cuenta los casos de uso y el ámbito de aplicación y considerando los aspectos meramente tecnológicos, la anterior es posiblemente la propuesta más pintiparada a la nuestra.

Con respecto a los sistemas genéricos no orientados a aplicaciones específicas, uno de los primeros se corresponde con desarrollado por Bain [15]. Utiliza ArcIMS para la parte SIG y por ende permite la interacción vía web. Un importante aspecto positivo es que soporta varios DMSs, en concreto Sharepoint Portal Server, Documentum 5 y FileNET. Un importante aspecto negativo es que no permite realizar búsquedas espaciales de documentos; en otras palabras, el usuario sólo puede obtener los documentos asociados explícitamente a una geometría, e. g. no puede indicar un bounding box y obtener los documentos contenidos en éste. El tener que asociar explícitamente las geometrías implica un problema al actualizar las referencias cruzadas tal y como su propio autor reconoce. Por otro lado, las compañías ESRI, Documentum, EMC, Nirvana, MetaCarta y GTI ofrecen de forma conjunta una solución [16] para integrar SIG/ECM, pero sólo puede ser utilizada si la organización destinataria dispone del respectivo producto de cada compañía implicada. Del mismo modo, la compañía docSTAR ofrece MapConnect [17], un módulo adicional para el DMS comerciado por la misma. Finalmente, en Strötgen et al. proponen TimeTrails [18], cuya característica más definitoria consiste en que no sólo considera la localización de los documentos en el espacio sino también en el tiempo. Emplea el paquete PostGIS y no contempla DMS interno; utiliza fuentes de documentos externas.

3. Infraestructura propuesta

En aras de acometer los desafíos señalados en la sección 1, resulta necesario identificar el conjunto de aquellas entidades tales que la unión de sus funciones a través de unos determinados protocolos de comunicación pueda dar como resultado una infraestructura que cumpla con la funcionalidad global esperada. Como respuesta a la posibilidad de implantar la propuesta en una IDE ya existente y/o en una organización con una ECM ya implantada, se ha diseñado un sistema completamente modular que permite tanto un despliegue conjunto de sus componentes desde cero como el acoplamiento individual de cualquiera de éstos en una infraestructura desplegada a priori.

3.1 Visión general
Establecemos que son necesarias las siguientes entidades debidamente enlazadas: un DMS, un módulo espacial para éste, un servidor de mapas, y una interfaz de usuario. Nuestro cometido consiste en enlazar adecuadamente tales entidades y en desarrollar una interfaz web de demostración y el módulo espacial. En adición nos proponemos incluir un geo-localizador para asociar geometrías a los documentos y un buscador semántico espacial. La figura 1 muestra la arquitectura presumible para el sistema final, incluyendo los protocolos y/o librerías necesarios para garantizar la comunicación.

Figura 1. Arquitectura del sistema propuesto.

3.2 Aplicación web
La interfaz de usuario ha de posibilitar tanto la interacción habitual con el DMS, i.e. exploración del repositorio, búsqueda de documentos según propiedades y/o contenido, etc., como la interacción con un visor SIG. Esta última consiste principalmente en visualizar las geometrías asociadas a un documento seleccionado y en indicar como criterio de búsqueda de documentos un elemento de la capa mostrada, un conjunto de elementos, o un bounding box. Nótese que a diferencia de otras propuestas, e. g. la de Bain, en nuestro caso se pueden realizar búsquedas por regiones no enlazadas directamente a los documentos.

Para materializar una interfaz de las características indicas hemos elegido implementar una aplicación web que se comunique mediante protocolos estándar con el resto de componentes del sistema; por tal razón otras aplicaciones web desarrolladas por terceras partes pueden ser fácilmente integradas. Tenemos en cuenta la existencia de editores así como de usuarios que sólo puedan leer.

3.3 Gestor de documentación
Como componente DMS hemos elegido Alfresco Comunity Edition. Al ser éste un producto de código abierto, nuestra propuesta goza de una doble ventaja respecto de otras como por ejemplo la de Hale et al. o la de Bain. Por una parte, la organización destinataria se ahorra coste de licencia. Por la otra, existe la posibilidad de extender el código del gestor para hacerlo más eficiente a propósito de la gestión espacial.

De hecho, nuestra propuesta incluye dos módulos de extensión para Alfresco. Uno de ellos queda destinado a las cuestiones relativas a la comunicación con el servidor de mapas, así como a las relativas al almacenamiento de capas, de sus estilos de visualización y de geo-referencias de documentos; en el caso de las capas se contempla aplicar el algoritmo de simplificación Ramer-Douglas-Peucker [19] antes del almacenamiento. El otro queda destinado a conseguir que Alfresco sea capaz de gestionar adecuadamente capas en formato vectorial (véase sección 4).

3.4 Servidor de mapas
El servidor de mapas escogido ha sido MapServer, que es comúnmente reconocido como la mejor opción gratuita para servir a dicho fin. Su misión en nuestro sistema consiste en atender peticiones realizadas tanto por Alfresco como por la propia aplicación web.

3.5 Módulos adicionales
Consideramos integrar un geolocalizador externo para permitir al usuario conocer la geometría correspondiente a una determinada dirección postal; de este modo se facilita al editor el geo-referenciar los documentos del repositorio. Asimismo, consideramos integrar un buscador semántico externo para facilitar al usuario las búsquedas espaciales.

4. Gestión de capas en repositorio

Si bien en el sistema que proponemos las capas vectoriales son almacenadas en una base de datos espacial (concretamente PostGIS) y esto habilita el correcto funcionamiento de toda la infraestructura, también resulta posible mantenerlas almacenadas en el repositorio nativo de Alfresco. Si se opta por la segunda opción entonces es necesario que Alfresco sea capaz de trabajar con ellas como si fueran documentos típicos (aplicables versionado, control de flujo, etc.) y que, al mismo tiempo, mantenga al usuario abstraído de características tales como la naturaleza multi-archivo de una capa Shapefile. Por esta causa, hemos desarrollado una extensión modular que habilite Alfresco para dicho cometido. También hemos creado una interfaz web para interactuar con los documentos del repositorio, inclusive las capas; la comunicación entra la una y el otro se lleva a cabo vía REST. Una captura de la esta interfaz puede verse en la figura 2.

Nótese que el usuario sólo vislumbra un archivo (.shp) por capa a pesar de que el formato Shapefile implica como mínimo tres; el resto de archivos de cada capa permanecen en el repositorio asociados en todo momento al mostrado pero salvaguardados de la manipulación directa.

Alfresco posibilita interactuar con sus documentos creando una unidad de red enlazada al repositorio vía protocolo CIFS. Es especialmente interesante en nuestro caso pues los usuarios pueden utilizar programas SIG de escritorio, e. g. ArcView, para editar capas del repositorio como si éstas estuvieran en disco local. La figura 3 muestra una captura de una unidad de red enlazada a un repositorio Alfresco que contiene varias capas Shapefile. En este tipo de acceso la abstracción de ficheros auxiliares (.dbf, .shx, etc.) y los eventuales permisos de usuario se mantienen.

Por su parte, para que Alfresco sea capaz de gestionar capas vectoriales son necesarias toda una suerte de modificaciones que extiendan su proceso habitual de gestión de documentos, el cual queda destinado a documentos lógicos asociados a un único archivo físico. La base del nuevo proceso que hemos desarrollado queda expuesta en la figura 4.

Figura 2. Interfaz web creada para el gestor documental.

Figura 3. Interacción con shapefiles del repositorio vía unidad de red.

Figura 4. Mecanismo base empleado en la gestión de capas vectoriales.

5. Conclusiones

Bajo determinados contextos, poder acceder a un documento a partir de una localización geográfica brinda a los usuarios de un gestor documental con una considerable mejora respecto de la eficiencia en la exploración. Análogamente, poder recuperar las localizaciones vinculadas a un documento aumenta la capacidad de trabajo de estos mismos usuarios. Para lograr que un gestor de documentación sea capaz de otorgar las capacidades anteriores, es necesario integrarlo con un sistema de información geográfica y en similar medida modificar/extender el modelo de datos de su repositorio.

Si bien en la literatura se pueden encontrar varias propuestas al respecto, la mayoría están basadas en productos software propietarios y por ende suponen un coste elevado para la organización destino. En este artículo se ha abordado el problema proponiendo una infraestructura que en su conjunto cumpla las funcionalidades indicadas pero con un coste económico mínimo. Adicionalmente, se ha presentado un módulo desarrollado a fin de proporcionar al gestor Alfresco la habilidad de trabajar con capas en formato vectorial, de manera análoga a documentos de cualquier otro tipo. Como cuestión futura queda completar la implementación de la infraestructura de tal modo que se pueda realizar una demostración funcional.

Agradecimientos. Este trabajo es fruto de una de las líneas de I+D que viene realizando el IDR dentro del proyecto "RED DE INTELIGENCIA E INNOVACIÓN DE TURISMO", financiado por el Ministerio de Ciencia e Innovación, Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica. Subprograma IMPACTO.

Referencias

[1] Alfresco Coummunity Edition, http://www.alfresco.com/community/
[2] Nijman, A.S.: A Proposal and Selection of a Document Management System for Staatsolie Suriname. M.S. thesis, Delft University of Technology, Netherlands (2009)
[3] Sherman, S.: GIS and Document Management Integration. In: Proceedings of the 27th Annual Esri International User Conference. ESRI, San Diego (2007)
[4] Swenson, A.D.: Mapping your documents: issues integrating GIS with document management. In: Sailing, M.J. (ed.) URISA Annual Conference Proceedings, pp. 210-218. Orlando (2000)
[5] Crosswell, P.: Concepts and Project Design Considerations for Electronic Document Management System Implementation. In: Sailing, M.J. (ed.) URISA Annual Conference Proceedings, pp. 556-568. Long Beach (2001)
[6] Nordheim, S., Päivärinta, T.: Customization of Enterprise Content Management Systems: An Exploratory Case Study. In: Proceedings of the Proceedings of the 37th Annual Hawaii International Conference on System Sciences. HICSS '04, vol. 4, pp. 1-9. IEEE Computer Society, Washington (2004)
[7] Hosse, K., Schilcher, M.: Temporal GIS for Analysis and Visualization of Cultural Heritage. In: Proceedings of CIPA XIX international Symposium. Antalya (2003)
[8] Gaio, M., Sallaberry, C., Etcheverry, P., Marquesuzaa, C., Lesbegueries, J.: A global process to access documents' contents from a geographical point of view. J. Vis. Lang. Comput. 19, 3-23 (2008)
[9] Sistema de Información Patrimonial de Santiago de Compostela, http://sip.consorciodesantiago.org/SIPWeb/
[10] Ahlers, D., Boll, S., Wichmann, D.: Virtual Signposts for Location-based Story-telling. In: Proceedings of the International GI Days Conference. GI Days, Münster (2008)
[11]Rioja, R. et al.: GeoSistur: integración de componentes tecnológicos IDE en un CMS para la construcción de geoportales turísticos. In: Actas de las I Jornadas Ibéricas de Infraestructuras de Datos Espaciales. JIIDE'2010, Lisboa (2010)
[12] Rojas-Sola, J.I., Castro-García, M., Carranza-Cañadas, M.P.: Content management system incorporated in a virtual museum hosting. J. Cult. Herit. 12, 74-81 (2011)
[13] Gharaibeh, N., Camacho, G., Elgendy, M., Ramirez, I.: Geographic Information System Framework for Stormwater Drainage Asset Management. J. Transp. Resrch. Brd. 2121, 1-12 (2009)
[14] Hale, H.E., DeShields, J., Reichert, C., Beck, S.: Implementing a GIS/ECM Based Public Utility CSR Tracking System. In: Proceedings of the 30th Annual Esri International User Conference. ESRI, San Diego (2010)
[15] Bain, A.: Documents and GIS: A Marriage Built to Last. In: Proceedings of the 23th Annual Esri International User Conference. ESRI, San Diego (2003)
[16] White paper: Integration and management of geospatial data and related documents in collaborative environments. EMC® & Nirvana®.
[17] docSTAR^TM MapConnect, http://www.docstar.com/gis-document-management
[18] Strötgen, J., Gertz, M.: TimeTrails: A System for Exploring Spatio-Temporal Information in Documents. In: Bertino, E., Atzeni, P., Lee, K., Chen, Y., Tay, Y. C. (eds.) VLDB 2010. The Proceedings of the VLDB, vol. 3, pp. 1569-1572. VLDB Endowment (2010)
[19] Douglas, D. H., Peucker, T.K.: Algorithms for the reduction of the number of points required to represent a digitzed line or its caricature. J. Canad. Cart. 10, 112-122 (1973)

Descubrimiento y geoprocesado de información espacial utilizando un buscador semántico

Márquez, J., Cifuentes, D., Córcoles, J. E., Quintanilla, A. — Tue, 07 Feb 2012 00:00:00 +0100

DESCUBRIMIENTO Y GEOPROCESADO DE INFORMACIÓN ESPACIAL UTILIZANDO UN BUSCADOR SEMÁNTICO

Javier Márquez, David Cifuentes, J. E. Córcoles, Antonio Quintanilla
Universidad de Castilla-la Mancha

1. Introducción

Muchos de los esfuerzos en el desarrollo de la Web se basan en la llamada Web Semántica. Dentro de la Web Semántica, un dominio que requiere especial atención es la Web Semántica Geoespacial. La enorme variedad de codificación semántica hace que sea especialmente difícil de tramitar las solicitudes de información geoespacial. En un futuro próximo, la Web Semántica Geoespacial permitirá recuperar servicios y/o recursos espaciales y no espaciales mediante consultas sencillas. Para ello es necesario incorporar semántica a la información espacial y la definición de estructuras que puedan llevar a cabo consultas eficientes. Con el fin de hacer esto posible, la solución se enmarca en dos áreas: Recuperación de Información -Information Retrieval - (IR) y el descubrimiento de servicios geoespaciales (DSG) [1] de forma automática en Internet.

El sistema que planteamos gestiona consultas con el patrón <qué, operador, donde>, tales como "Ríos que cruzan Londres". La mejora de rendimiento del sistema se ha reforzado con la agregación de relaciones semánticas entre conceptos (sinónimos, hiperónimos, hipónimos, etc.) utilizando ontologías, la indexación de los contenidos para acelerar los tiempos de respuesta, el soporte de operadores topológicos, y un geoparser para conocer el ámbito geográfico.

2. Descripción del sistema

El sistema propuesto tiene una estructura típica de motor de búsqueda Web, es decir, el cliente envía peticiones a un servidor, que generará respuestas adecuadas. Las peticiones serán del tipo <capas i/o features, qué, operador, donde>. Ejemplo, "Capas con ríos y carreteras en Madrid", mientras que las respuestas tienen la forma <capa, servidor> para consultas de capas y <nombre, geometría, URL> para features. La URL puede estar relacionada con una ontología RDF o una respuesta DescribeFeature de un servicio WFS. La arquitectura del sistema se basa en el diseño conceptual [5] que se ha refinado después de explorar varias alternativas de implementación. La arquitectura del servidor es la parte más compleja de nuestra arquitectura. Se han construido los siguientes módulos:

Crawler: Busca enlaces correspondientes a servicios geoespaciales estandarizados por el OGC a través de Internet de una manera similar a [1]. Cuando se encuentra un servicio válido, se obtienen los metadatos mediante solicitudes GetCapabilities. Por último, el crawler (rastreador) registra los metadatos del servicio disponible (servidores y capas de información) en un sistema de información (base de datos).

Inference engine (IR): Analiza los metadatos del servicio para calcular el área geográfica. Un algoritmo se ejecuta teniendo en cuenta los topónimos y las coordenadas encontradas en los metadatos del servicio. El motor de inferencia también analiza los títulos de las capas con el fin de descubrir la verdadera semántica de la información. Esto se realiza haciendo peticiones a ontologías disponibles en Internet mediante SPARQL.

Módulo de indexación: Este subsistema maneja la estructura de indexación de contenidos. Esta estructura se compone de una cuadricula (grid) que cubre todo el área geográfica del buscador. Además, existen dos ficheros invertidos asociados a cada celda de la cuadrícula: uno de ellos se utiliza para la indexación de capas obtenidas de WMS (ráster) y otro para servicios WFS (vector), que se utiliza para la indexación de las features individuales obtenidas a partir de los WFS. Un fichero invertido es una estructura de datos indexados que guarda una correspondencia entre el contenido, tales como palabras o números, y sus ubicaciones en un sistema de información.

Figura 2. Estructura de Indexación. El grid abarca el área geográfica. Cada celda contiene dos ficheros invertidos.

El módulo de indexación actualiza los ficheros invertidos asociados a las celdas de la cuadricula cuyo bounding box de capa intersecte o contenga el bounding box de la capa. Los nuevos registros indexados en el fichero invertido f tienen la forma {c: l_i, s_i}, donde c es un concepto representado por una o más palabras; l_i es el identificador de una capa cuyo título contiene el concepto c, también puede que c no tenga contenido el título de la capa l_i, pero sí una relación semántica con otro concepto en el título; y finalmente, si es una puntuación, cuyo rango es [0, 1], que mide el nivel de fiabilidad por la que la capa l_i contiene información sobre el concepto c.

En cuanto a los ficheros invertidos para la indexación de features por cada capa WFS encontrada por el crawler, se envía una petición GetFeature para la recuperación de sus características, indexando sólo la información que interesa en este caso; topónimo y geometría de cada feature.

La actualización se produce en los ficheros invertidos que afecta a las celdas obtenidas del cruce geométrico. Los nuevos registros indexados f tiene la forma {c: f_i, l_i, s_i, r_i}, donde c es un concepto representado por una o más palabras; f_i es un identificador interno de feature, l_i es el identificador de capa que ofrece la feature f_i, y cuyo título contiene el concepto c, o por el contrario, una relación semántica con otro concepto del título de la capa. s_i es la puntuación de las capas indexadas. Y por último, r_i es una URL que puede obtener más información de la feature f_i. La URL puede ser una ontología en Internet construida sobre RDF o una solicitud DescribeFeature de WFS. El topónimo y la geometría de cada feature se almacenan en la base de datos.

Query parser (analizador de consultas): Es capaz de navegar por la estructura de índice con el fin de responder apropiadamente a las consultas de usuario. Las respuestas tienen un conjunto de resultados que se ordenan utilizando las puntuaciones s_i previamente calculadas. El analizador de consultas accede a los datos del sistema de información por cada capa l_i, obteniendo datos sobre (título, escala máxima y mínima, bounding box, etc.) y/o servicios (propietario, URL, forma de respuesta, etc.). El modulo gestiona los operadores topológicos contenidos en las consultas, lo que permite obtener características geográficas, lista de topónimos de features, geometrías y URLs.

Figura 1. Arquitectura del sistema. Comunicación entre los diferentes módulos.

3. Proceso de actualización de la estructura de indexación

En el apartado anterior se ha visto la estructura de indexación, que consiste en una cuadrícula que cubre el ámbito geográfico del motor de búsqueda. Este ámbito puede ser la Tierra, un continente, país o cualquier zona, en función de las necesidades de la aplicación. Asociados a cada celda de la cuadrícula, hay dos ficheros invertidos: uno de ellas para indexar las capas (WMS) que ofrece los servicios OGC y otro para la indexación de features obtenidas a partir de servicios WFS (Figura 2). El número total de ficheros invertidos es dos por celda. Esta arquitectura reduce el cálculo de operaciones topológicas en tiempo de consulta, ya que el análisis se centra en las celdas afectadas del ámbito. Además, la razón por la cual se necesita dos ficheros invertidos por celda, es debido a que la información indexada es diferente para capas (WMS) y features (WFS).

El proceso de actualización de la estructura de índice se lleva a cabo en tiempo de indexación, por lo que los usuarios finales no son conscientes de ello. Este proceso se inicia después de encontrar un nuevo servicio WMS o WFS. El proceso se divide en las siguientes partes: indexación de capas (WMS) y/o de features si se trata de un servicio WFS, expansión semántica de los ficheros invertidos utilizando ontologías externas y asignación de puntuación para el ranking de resultados.

3.1 Indexación de Capas
La primera parte del algoritmo es la actualización de la estructura de índices. En él se actualizan los ficheros invertidos una vez ha sido analizada la respuesta "GetCapabilities" del servicio (WMS o WFS indistintamente). Los siguientes pasos se realizan para cada capa l_i del servicio.

1 Obtener las celdas del grid que intersectan entre el bounding box de la.
2 Obtener conceptos bien conocidos de ontologías externas a partir de metadatos del título de capa.
3 Cada palabra del título de la capa que no haya sido reconocida por las ontologías, se indexa en todos los ficheros invertidos asociados a esas celdas {palabra_i: l_i; 1:00} y además tendrá la puntuación máxima 1.00. Por ejemplo, una capa llamada "Estados de la UE", donde "UE" no es reconocido por la ontología como "Unión Europea".
4 Las palabras del título reconocidas como conceptos bien conocidos por la ontologías, serán indexadas en todos los ficheros invertidos asociados a sus celdas: {palabra_i: l_i; 1:00}. Por ejemplo, "Estado" en una capa llamada "Estados de la UE".
5 Si un conjunto de palabras consecutivas del título de capa (palabra_i, palabra_i+1...,palabra_i+n) son reconocidas por la ontología como un sólo concepto, se registran como palabras conjuntas {palabra_ipalabra_i+1...palabra_i+n: l_i; 1:00}. Por ejemplo, "Carretera secundaria" en una capa llamada "Carreteras secundarias del Reino Unido".

3.2 Indexación de Features
Esta parte del algoritmo sólo se realiza si se ha descubierto un nuevo servicio WFS, actualizando los ficheros invertidos para la indexación de features. Los pasos se ejecutan por cada capa l_i de WFS:

1. Se realizan peticiones "GetFeature" al servicio WFS para recuperar todas las features f_i de las capas l_i. Si la respuesta es demasiado compleja, es posible realizar varias peticiones a áreas más pequeñas - divisiones de igual tamaño- (tiles).
2. Se recuperan dos de los campos del servicio: topónimo (nombre descriptivo) y geometría. Para conocer los campos del conjunto se realiza peticiones "DescribeFeatureType" al servicio WFS para obtener los tipos de la entidad analizada. Los tipos de campo dan una idea implícita de la información semántica.
Los topónimos se incluyen normalmente con etiquetas: gml:name, propiedades gml: AbstractFeatureType o xsd: string. La geometría por lo general utilizan la etiqueta gml: GeometryPropertyType. Sin embargo, este enfoque puede no ser suficiente ya que puede que haya más de un etiqueta con este tipo, por lo que debe realizarse una selección manual. Se podría dar una solución más real al problema semántico de servicios WFS, pero no hay una solución para dicho problema en este artículo. Otras
soluciones hacen uso de perfiles que asocian campos con su significado semántico de forma manual [4, 6].
3. Obtener las celdas para cada capa a través de la intersección entre el bounding box de la capa l_i y la cuadrícula. Este paso fue realizado en la primera parte del algoritmo.
4. Peticiones a las ontologías externas con el fin de obtener conceptos bien conocidos de los metadatos del título de capa (previamente se aplica un proceso de reducción de la palabra a su raíz - stemming-).
5. Cada palabra del título de la capa que no ha sido reconocida como un concepto bien conocido por las ontologías, es indexada en todos los ficheros invertidos asociados a sus celdas {palabra_i: f_i; l_i; 1:00; r_i}. El proceso se repite para cada f_i.
6. Las palabras del título que hayan sido reconocidos como conceptos bien conocidos por las ontologías, serán indexadas en todos los ficheros invertidos asociados a sus celdas: {palabra_i: f_i, l_i; 1:00; r_i}. Este proceso se repite para cada f_i.
7. Si un conjunto de palabras consecutivas (palabra_i,palabra_i+1.. palabra_i+n) del título de capa, ha sido reconocido como un sólo concepto, se registra como un único concepto en cada una de sus celdas {palabra_ipalabra_i+1..palabra_i+n: f_i; l_i; 1:00; r_i} Este proceso se repite para cada f_i.

3.3 Expansión semántica
La tercera parte del algoritmo añade nuevos conceptos a los ficheros invertidos de capas y features. Estos conceptos no están explícitamente en el título de la capa pero, en cambio, son conceptos relacionados semánticamente. Otros trabajos relacionados con IR y los servicios OGC hacen uso de la expansión semántica, ampliando el título original mediante sinónimos, hiperónimos,.., obtenidos de Servicios de Ontología Web (SOW)[3]. Por ejemplopara una capa titulada "Autopistas en Madrid", sus términos ampliados serán algo así como "autopistas, carreteras, red de carreteras". Estos términos estarán indexados de tal manera que para consultas "carreteras en Madrid", la capa será recuperada. Nuestra propuesta es la separación de la indexación y puntuación de acuerdo a la similitud semántica.

El sistema recupera los resultados con expansión semántica como un motor de búsqueda tradicional, además de ordenarlos de acuerdo a criterios semánticos. Otros autores hacen uso de la expansión en tiempo de consulta de usuario y no en tiempo de indexación. La decisión de emplear la expansión en la indexación, es debido a que los requisitos de almacenamiento como título de capa no son exigentes y el rendimiento del motor de búsqueda es mejorado, ya que es transparente al usuario. Sostenemos que si una capa proporciona información sobre "ríos", también tiene que ser recuperada para la consulta "Hidrografía" y viceversa. El nuevo enfoque añade información semántica basada en la recuperación de información clasificada [2]. La explicación es la siguiente:

Si son relaciones semánticas (ej: hipónimos, hiperónimos, sinónimos, merónimos,...); w_i es el peso de un relación r_i; t_i es un árbol construido con conceptos relacionados con r_i (ej: "rio" sería hijo en un árbol de hiperónimos de "corrientes de agua"). K(i)_a,b es el número de niveles del árbol entre el concepto a y b, por tanto, un nuevo registro {c: l_i; s_i} donde c es un concepto que no está explícito en el título de capa, semánticamente está relacionado por ri con el concepto del título de capa (C_title), tendrá la siguiente puntuación:

si(c) = w_i^k(i)c,ctitle

Es posible manipular el orden de resultados de la consulta de usuario sólo ajustando w_i. Por ejemplo, la capa l_i "Parques de Madrid" debe ser recuperada como "Zonas verdes de Madrid" de los primeros resultados ya que "Zonas verdes" es considerado un sinónimo de "Parque" (semánticamente son iguales). Por otra parte, las r_i como hiperónimo, debe tener un valor w_i por debajo de su máxima.

Por último, es necesario poner un punto final en el proceso de cálculo de los nuevos conceptos que se relacionan semánticamente con otros contenidos, mediante peticiones recursivas a ontologías en tiempo de indexación. Estas ontologías suelen tener recursos mediante propiedades RDFS como "subClassOf" o "isSubClassOf", que son útiles para inferir las relaciones de hiponimia e hiperonimia. Otras propiedades RDFS como "label" se pueden utilizar para obtener sinónimos. Todas estas solicitudes pueden hacerse a través de lenguajes de consulta como SPARQL.

4. Procesado de consultas

En esta sección, se describe el proceso interno de búsqueda de la consulta, desde el momento en que un usuario introduce un texto hasta la respuesta obtenida. Para ello se mostrarán un par de ejemplos:

Ejemplo 1 - "Autopistas que cruzan Francia": La primera tarea es distinguir en la consulta que corresponde al "qué", y al "dónde". Para ello, necesitaremos un geoparser. El geoparser podría ser externo (ej: GoogleMaps o GeoNames), el problema es que sólo proporcionan puntos y es necesario la geometría completa. Una solución puede ser el uso de topónimos y de geometrías a partir de servicios WFS. Además, cada registro del geoparser debe tener un campo con las celdas del grid -ver estructura de indexación- que contienen la geometría. Permitiendo centrarse en el área geográfica de interés y descartar los ficheros invertidos a celdas lejanas.El geoparser es una lista de registros {topónimo: geometría, celdas}. Obviamente, "Francia" será encontrado por el geoparser; como el "dónde", y el resto de la consulta el "qué" ("Autopistas"). En caso de que el geoparser encuentra múltiples resultados, el usuario tendrá que desambiguar. En ocasiones, la vista actual del mapa se utiliza para resolverlo de forma automática.

La segunda tarea es acceder a los ficheros invertidos para recuperar "autopistas"en los ficheros invertidos. El operador topológico "cruzan" obtendrá las celdas a consultar. La tercera tarea es filtrar los elementos preseleccionados, en el ejemplo "crucen" con Francia. La estructura de grid permite descartar los elementos que no comparten celdas con Francia. Tanto la geometría de capas (bounding box) y de features pueden ser leídas desde la base de datos. La última tarea es ordenar todos los elementos válidos por su puntuación s_i, aquellos resultados que son semánticamente más cercanos "autopista" deben colocarse en primer lugar. Lo aconsejable definir un umbral inferior de puntuación para aquellos elementos que no vayan a ser recuperados. Esto dependerá del tipo aplicación, metadatos u otros datos de capas y/o features disponibles en la base de datos.

Ejemplo 2 - "Ríos al norte de Londres": Este ejemplo presenta la principal diferencia en el operador topológico con respecto al Ejemplo 1. En este caso, las celdas correctas son aquellas que cortan o contienen la geometría de Londres, y también las celdas adyacentes al norte, porque son los candidatos para contener los ríos del norte de Londres. Por lo tanto, la única diferencia cuando se cambia el operador topológico, es el conjunto de celdas y de ficheros invertidos a tener en cuenta. El resto de
tareas siguen siendo las mismas.

5. Pruebas

Los experimentos tienen por objeto medir el rendimiento del motor de búsqueda a través de ratios de recuperación de información y tiempos de respuesta. Se han utilizado dos conjuntos de consultas:

1 - Pruebas para estudiar los ratios de recuperación de información y clasificación de resultados (sub-secciones 5.1 y 5.2) basadas en consultas a capas WMS con el operador - contiene -
2- El otro estudio está basado en consultas más complejas para analizar el comportamiento del motor (sub-sección 5.3) en el descubrimiento de features.

5.1 Análisis de los ratios de recuperación de información
El rendimiento del sistema se ha comparado con un motores de búsqueda tradicionales basado en palabras clave. Se han indexado casi un centenar de capas, a las que un subconjunto de 19 preguntas de la forma <lo que, en, dónde> comparan el rendimiento del motor (Figura 4).


Figura 3. Evaluación de consultas al sistema. Testeo utilizado entre un buscador clásico y el sistema definido.	Figura 4. Comparación de precisión y recuperación. El sistema obtiene mejores resultados en ambos indicadores.

Se ha evaluado la precisión - fracción de documentos relevantes recuperados en la búsqueda- y la recuperación - fracción de consultas relevantes que son recuperadas con éxito- .

El sistema realiza una mejora del 10% gracias a los conceptos relacionados, la recuperación es muy alta y la precisión es suficientemente alta. Debido a las limitaciones de espacio del artículo no se ha podido mostrar un análisis más profundo de las pruebas.

5.2 Clasificación de resultados
Se han comprobado los resultados que aparecen en las primeras posiciones, son igual o mejor a los motores de búsqueda tradicional. Aquellas consultas cuyos conceptos tienen una relación semántica (ej: consulta 6 y 11) obtienen mejores resultados. Los motores tradicionales no son eficientes para clasificar capas. Muchos de los algoritmos IR se basan en factores que no son significativos para este tipo de consultas, demostrando un mejor enfoque a la importancia semántica de la información y las coberturas geográficas.

5.3 Búsqueda de Features basado en Grid
Este estudio se centra en la medición de tiempos de respuesta para consultas de la forma <qué, operador, dónde> para búsqueda de features. El banco de pruebas consiste en 20 preguntas complejas con diferentes operadores (Figura 5).

Figura 5. Banco de pruebas utilizadas para analizar el rendimiento.

Resultados tras analizar los tiempos de respuesta:
Celdas afectadas: celdas del grid tenidas en cuenta en una consulta. El número es directamente proporcional a la superficie de las features que forman parte del "dónde". Ejemplo, "Provincias contenidas en España", las celdas afectadas son mayor que "Provincias contenidas en Madrid" (Madrid es una región de España), las celdas afectadas serían menor. A mayor número de celdas afectadas, mayor número de a ficheros invertidos.

Features afectadas: Son las features indexadas en las celdas afectadas y son utilizadas en las operaciones topológicas.

Operador: consultas con el mismo"qué" y "dónde" (celdas afectadas) obtienen tiempos diferentes de respuesta para diferentes operadores. Los costes computacionales de operadores son diferentes.

6. Conclusión

La nueva arquitectura presentada para el descubrimiento de capas y features que ofrecen los servicios OGC en Internet, tiene un alcance diferente a los catálogos de servicios (CSW) disponibles en las IDE. Como se ha demostrado, por lo que se refiere a los servicios geoespaciales, los resultados pre-calculados asociados a capas, teniendo en cuenta aspectos semánticos y geográficos, mejoran los resultados de consultas por ranking basadas en palabras claves. Además, se ha demostrado que el
uso de ontologías de dominio junto con los metadatos del servicio es una buena manera de mejorar la precisión y recuperación de información. Además, el el rendimiento en la búsqueda de features con una estructura de indexación basada en grid con ficheros invertidos para la gestión geográfica / textual es prometedor para ciertas condiciones, aunque existen otras estructuras como los R-tree o los grid multinivel que son más eficaces. En futuros trabajos se probarán éstas otras estructuras.

Agradecimientos. Este trabajo es fruto de una de las líneas de I+D prioritarias del IDR y de SIGTEL Geomática S.L., la cual cuenta con financiación del Ministerio de Ciencia e Innovación, Subprograma IMPACTO (proyecto "RED DE INTELIGENCIA E INNOVACIÓN DE TURISMO") y Subprograma Torres Quevedo.

Referencias

[1] N. Chen, J. Gong, and Z. Chen. A high precision ogc web map service retrieval based on capability aware spatial search engine. In Proceedings of the 2nd international conference on Advances in computation and intelligence, ISICA'07, pages 558-567, Berlin, Heidelberg, 2007. Springer-Verlag.
[2] K. Janowicz, M. Schwarz, and M. Wilkes. Implementation and evaluation of a semantics-based user interface for web gazetteers. In Visual Interfaces to the Social and the Semantic Web (VISSW 2009) Workshop in conjunction with the International Conference on Intelligent User Interfaces (IUI 2009), Sanibel Island, Florida, 2009.
[3] J. Lacasta, J. Nogueras-Iso, R. Béjar, P. R. Muro-Medrano, and F. J. Zarazaga-Soria. A web ontology service to facilitate interoperability within a spatial data infrastructure: Applicability to discovery. Data Knowl. Eng., 63:947{971, December 2007.
[4] M. Lutz, U. Einspanier, E. Klien, and S. Huebner. An Architecture for Ontology-based GI Discovery and Retrieval of Geographic Information. In Ontology-based Discovery and Composition of Geographic Information Services (SWSDN2004), pages 179{188, 2004.
[5] J. Márquez, J. E. Corcoles, and A. Quintanilla. A semantic index structure for integrating ogc services in a spatial search engine. In IEEE International Conference On Open Systems, Kuala Lumpur, Malaysia, 2010, 2010.
[6] M. Paul and S. K. Ghosh. An approach for service oriented discovery and retrieval of spatial data. In Proceedings of the 2006 international workshop on Service-oriented software engineering, SOSE '06, pages 88-94, New York, NY, USA, 2006. ACM.

IDEC_Litoral, la infraestructura de Dades Espacials del litoral de Catalunya

Cuesta, L., Giménez, P. — Tue, 07 Feb 2012 00:00:00 +0100

IDEC-LITORAL, LA INFRAESTRUCTURA DE DADES ESPACIALS DEL LITORAL DE CATALUNYA

Lucia Cuesta, Patrícia Giménez
Àrea de Medi Ambient. Consorci El Far

1. IDEC-Litoral: una perspectiva sectorial

El litoral és un medi dinàmic i complex, i en el cas de Catalunya és, a més, un espai altament intervingut amb multitud de pressions i impactes associats. La importància estratègica de la seva gestió ha estat abordada des de diferents àmbits, per exemple a través del Pla Director Urbanístic del Sistema Costaner o la Llei del Paisatge entre altres. Tanmateix, tot i existir una gran quantitat de dades i informació al respecte, una característica intrínseca a aquesta informació és la seva dispersió. Fet que no es d'estranyar si tenim en compte la diversificació administrativa, competencial i legal existent, com també la gran quantitat d'agents que hi intervenen directa o indirectament. La idiosincràsia del litoral català freqüentment tendeix a dificultar actuacions sota una òptica integrada de territori costaner o de Gestió Integrada de Zones Costaneres (GIZC).

En aquest sentit i en el mac de la Directiva 2007/2/CE, de 14 de març de 2007, de creació d'una Infraestructura de Dades Espacials a Europa (INSPIRE) [1] i de la normativa associada a nivell estatal i català es crea la Infraestructura de Dades Espacials de Catalunya (IDEC¹). En el cas català, l'estratègia pel desenvolupament de la IDEC s'ha basat en la promoció de IDEs temàtiques o especialitzades en dominis concrets, de manera que mantenint una identitat i uns serveis propis aportessin els seus recursos a la IDEC, engrandint la xarxa global de proveïdors de geodades i serveis, tot i presentant al seu usuari final la visió concreta, sectorial i especialitzada que necessita [2]. Els beneficis d'aquesta estratègia són múltiples, com són la participació dels agents, la divulgació i ús de la IDEC, l'intercanvi d'informació, l'impuls de tecnologies d'interoperabilitat i la seva incorporació en nous projectes.

En aquest context és on s'emmarca la Infraestructura de Dades Espacials del litoral de Catalunya (IDEC-Litoral), una iniciativa d'IDE sectorial de la costa Catalana integrada en la xarxa IDEC que s'impulsa amb l'objectiu de millorar i incrementar l'accés a la informació existent per a tota la comunitat d'usuaris, de forma que la seva participació en la gestió de la costa pugui ser més activa i documentada. Es tracta d'una eina que permet conèixer i accedir a la informació relativa a la costa.

2. El Geoportal IDEC-Litoral

L'IDEC-Litoral presenta a través d'un geoportal creat com a un espai on trobar i aportar la informació de referència del litoral català, tant a nivell de continguts i enllaços amb els principals agents del sector, com de visualització de geoinformació de l'àmbit costaner, www.geoportalidec.net/idecostes/index.jsp. La informació que es facilita procedeix de les diferents administracions públiques com la Generalitat de Catalunya, el govern estatal i entitats locals, així com d'altres institucions públiques i privades de Catalunya.

Figura 1. Geoportal IDEC-Litoral.

El geoportal ha estat creat per l'Institut Cartogràfic de Catalunya (ICC) en col·laboració amb el projecte europeu Eurosion [3], una iniciativa europea finançada per la Direcció General de Medi Ambient de la Comissió Europea. El projecte Eurosion va introduir dades costaneres georeferenciades en relació a la costa catalana i a la seva erosió suposant el punt de partida a nivell de continguts específics de mar d'aquest geoportal (Eurosion, 2004). Actualment el geoportal es gestiona de forma conjunta per l'ICC i el Consorci El Far a través d'un conveni de col·laboració formalitzat a principis de 2011 i que té per objecte desenvolupar i mantenir el geoportal, tot i que el treball conjunt es va
iniciar amb anterioritat.

A nivell de gestió cada una d'aquestes entitats aporta una experiència prèvia i s'encarrega de diferents aspectes del geoportal.

Concretament l'ICC gestiona el Centre de Suport IDEC, ens promotor de la Infraestructura de Dades Espacials de Catalunya, acollint diferents IDE's temàtiques i gestionant els seus recursos. L'ICC a través del Centre de Suport IDEC, desenvolupa i manté la pàgina Web del Geoportal, inclou un Catàleg de Metadades (adaptació del Catàleg IDEC), un Visualitzador de Mapes-Client WMS, i diferents geoserveis (adaptació dels que s'ofereixen a través del Geoportal IDEC). Així mateix hostatja la web i els serveis
corresponents, i dona suport tècnic a les necessitats del Consorci relacionades amb la utilització del Geoportal.

D'altra banda, El Consorci El Far, és una entitat pública² que té com a finalitat promoure i desenvolupar els valors associats al mar i al litoral, té com a línies d'actuació el foment i difusió dels valors socials, econòmics, ambientals i culturals del mar i el litoral en el marc de la sostenibilitat, la formació professional en els oficis del mar i promoció del sector nàutic. El Consorci El Far desenvolupa la seva activitat a través de diferents àrees de treball i serveis que tenen com a objectiu generar projectes i potenciar el treball en xarxa amb altres institucions i entitats. D'aquesta manera, el Consorci El Far dóna recolzament a les polítiques d'actuació impulsades per les institucions que l'integren, en el que és el seu àmbit d'actuació: el mar i el litoral. Un dels àmbits de treball de l'Àrea de Medi Ambient del Consorci El Far és l'impuls a la gestió integrada del litoral, aportant experiència en el sector a través de la col·laboració en diferents projectes litorals, com el Pla Estratègic litoral de la RMB o el desenvolupament d'una bateria d'indicadors pel litoral català, i a través del seu treball en xarxa amb els agents que hi intervenen.

L'Àrea de Medi Ambient d'aquesta entitat és l'encarregada del desenvolupament i actualització de l'IDEC-Litoral enriquint els continguts del geoportal (documentació, projectes i informes disponibles, enllaços, xarxes de referència, etc.), així com de realitzar la difusió del geoportal entre tots els agents. Subministra els continguts a publicar i realitza el seu manteniment, alhora que comunica l'ICC totes les incidències detectades durant l'ús dels serveis, proposant millores, si s'escau, en els seus continguts o programes.

2.1 L'estructura i els serveis que ofereix
Un geoportal és per definició un conjunt de components que dóna accés als diferents recursos disponibles, en aquest cas en l'àmbit del litoral de Catalunya (informació geogràfica, notícies, articles, eines d'edició de metadades, serveis de geoprocessament i enllaços). L'estructura del geoportal IDEC-Litoral està dissenyat per tal de oferir:

Informació litoral de referència: normativa, plans i programes existents al litoral, documentació de GIZC i temàtica de referència (platges, aigua, ocupació del sòl, ports, erosió, turisme, pesca, etc), així com publicacions científiques i revistes especialitzades. També ofereix un diccionari terminològic en l'àmbit de la GIZC i de les IDE.
Enllaços: a nivell de costes (entitats oficials internacionals i mediterrànies, administració estatal, autonòmica i local amb competències directes, agents implicats, associacions, ONGs i empreses consultores, universitats i centres de recerca especialitzats) i d'indrets en els que es pot aconseguir informació geogràfica de Catalunya.
Una primera aproximació a les Metadades: concepte, enllaços, perfil IDEC i accés directe a la descarrega de MetaD.
Geoserveis: Catàleg de metadades i visor de mapes.

El catàleg de metadades és un punt d'accés a un servidor web, que es pot consultar a través d'internet, i que emmagatzema les descripcions de la informació geogràfica (metadades) i dels serveis. El catàleg ajuda als usuaris a trobar les dades existents en altres servidors, mitjançant la informació que aporten les metadades. Les consultes es poden fer mitjançant camps diversos (per títol, paraula clau, per nom de l'organització, per coordenades, entre d'altres).

El visor de mapes (Visualitzador- Client WMS). Aplicació client que permet consultar la cartografia procedent de diferents servidors de mapes independentment de la seva arquitectura (sempre que aquests servidors tinguin implementat algun connector estàndard WFS o WMS d'OpenGis), combinar diferents capes de diferents servidors i crear
mapes útils per l'usuari.

Figura 2. Visor de mapes amb capes d'informació del litoral català.

3. Els primers resultats dels treballs d'actualització i difusió del Geoportal IDEC-Litoral

L'actualització i ampliació dels continguts, pel que fa a la informació del litoral, es realitza de forma continua a través dels diferents canals d'informació del que disposa l'equip de treball (normativa, plans i programes, etc), així com a través de la xarxa d'agents del sector que aporten informació i MetaD (administracions públiques amb competències al litoral, principalment). El correcte funcionament de geoserveis també es comprova cada cert temps, alhora que es realitzen propostes per tal detectar aspectes en els que caldria disposar de major informació.

D'altra banda, l'actualització dels enllaços es realitza de forma periòdica, amb revisions extraordinàries en cas de produir-se canvis polítics ja que amb freqüència van acompanyats de modificacions en les adreces i enllaços associats.

Un dels aspectes clau del geoportal és la seva difusió a través de diferents vies, tan per donar a conèixer tota la informació recopilada, com per donar la oportunitat als diferents agents per tal que utilitzin i aportin dades i geodades. En aquest sentit s'ha realitzat diverses actuacions:

Participació o assistència en jornades del sector i reunions de treball. La iniciativa es va presentar a nivell Europeu per primera vegada en una reunió oberta a totes les regions europees marítimes a través del grup de treball Aquamarina A day for cartographic systems to manage coastal zones, Brussel·les, 2009. Des de llavors s'ha assistit de forma continua en jornades com és cas del X Fòrum TIG-SIG, Barcelona, 2011 organitzat per l'ACTIG i l'ICC o la jornada Coast GIS 2011. De cara a 2012 està previst participar en un curs de SIG a les zones costaneres on es parlarà de l'IDEC-Litoral.
Contacte i reunions amb els principals agents del sector.
Elaboració d'un banner de l'IDEC-Litoral a les pàgines web de les entitats com a eina de difusió.
Difusió en diferents mitjans de comunicació (butlletí de l'ICC o radio nàutica 360).
Servei d'atenció personalitzada per atendre els usuaris del geoportal.

Figura 3. Banner de difusió.

El retorn de totes les accions de difusió no només permet donar a conèixer el geoportal, sinó també nodrir-lo de les noves iniciatives del sector i ampliar la xarxa d'agents, així com establir sinèrgies amb els mateixos. Arrel de les reunions a nivell europeu es pot observar com totes les regions, a diferents nivells, estan treballant en la línia que marca la Directiva Inspire. Es constata que encara cal fer feina per harmonitzar la informació i sobretot per obtenir més recursos econòmics per dur a terme la feina o bé per mantenir-la [4]. A una escala més local i regional el geoportal té un gran potencial pel que fa al seu ús i aplicacions, sobretot a nivell tècnic i polític en la presa de decisions. Es tracta d'un gran potencial en el que tot just s'hi està treballant.

4. Anàlisi i perspectives de futur

Com a primera aproximació a l'anàlisi del geoportal IDEC-Litoral, a continuació s'apunten algunes de les principals fortaleses i febleses d'aquesta iniciativa amb la voluntat d'evolucionar potenciant les primeres i reduint les segones.

A nivell de fortaleses:

IDEC-Litoral és únic, com a banc de dades de la costa de Catalunya.
L'impuls del geoportal per part d'una entitat pública amb competències atribuïdes com a l'ICC aporta al geoportal una rigorositat reconeguda.
Experiència i presència en el sector.
Treball amb una amplia xarxa d'agents.
L'accés immediat a la geoinformació.

Respecte a les febleses:

Dispersió de dades i estudis existents en l'àmbit costaner.
Coneixement difús dins del sector de l'existència del geoportal.
És necessari un manteniment periòdic de tota la informació, per evitar que hi hagi informació obsoleta.
Manca d'actualització de part de la informació, que hauria d'actualitzarse amb major freqüència (no existeix un programa sistemàtic per actualitzar les dades per part de l'administració).
Es requereix més pressupost per actualitzar la informació.

En aquesta línia, actualment s'està treballant de forma coordinada per tal d'impulsar i divulgar l'existència del geoportal com a objectiu principal, treballant amb els agents i organitzant reunions amb les principals entitats públiques amb competències en aquest àmbit.

En definitiva, encara queda molt camí a córrer amb l'IDEC-Litoral, tant per la informació que ha d'oferir, com per l'ús que n'han de fer els tècnics que necessiten d'aquesta plataforma. Tot i així, ara ja ningú qüestiona que l'IDEC-Litoral és un gran avanç per garantir una gestió més integrada del litoral.

Notes

1. Una IDE és un conjunt de tecnologies, polítiques, estàndards, serveis i recursos humans necessaris per a la recopilació, la manipulació, l'accés, la distribució i la utilització de dades geogràfiques a diferents nivells. És una base per al descobriment de dades espacials, la seva avaluació i la seva utilització per part de tot tipus d'usuaris, tant del sector públic, com del sector empresarial, acadèmic, no governamental o dels mateixos ciutadans. Conceptualment, les Infraestructures de dades tenen la finalitat de millorar la comunicació, facilitar l'accés, incrementar el comerç, etc.
2. Entitat pública formada per l'Ajuntament de Barcelona, la Generalitat de Catalunya, la Diputació de Barcelona i l'Autoritat Portuària de Barcelona.

Referències

[1] Directiva 2007/2/CE del Parlament Europeu i del consell de 14 de març de 2007 per la que s'estableix una Infraestructura d'Informació Espaial a la Comunitat Europea (INSPIRE) (2007)
[2] ICC (2009). Infraestructura de Dades Espacials de Catalunya en xifres 2009. Versió 2.0-Maig 2010 (2009)
[3] Eurosion. Living with coastal erosion in Europe. Sediment and space for sustainability. Results from the Eurosion Study. European Commission. (2004)
[4] Aquamarina. European consultation on EMODNET. Building a European marine knowledge infrastructure: Roadmap for a European Marine Observation and Data Network. Response from the "Data and indicators" working Group of the CPMR AQUAMARINA Group (2009)

La experiencia del USGS con I.G. voluntaria y su prototipo colaborativo de OpenStrretMap

Wed, 08 Feb 2012 00:00:00 +0100

LA EXPERIENCIA DEL USGS CON I.G. VOLUNTARIA Y SU PROTOTIPO COLABORATIVO DE OPENSTREETMAP

Iván Sánchez*, Eric B. Wolf**, Greg D. Matthews**, Kevin McNinch**, Barbara S. Poore**
*Asociación OpenStreetMap España
**United States Geological Survey

1. Prefacio

El presente artículo es una traducción íntegra de: Wolf, E.B., Matthews, G.D., McNinch, K., and Poore, B.S., 2011, OpenStreetMap Collaborative Prototype, Phase 1: U.S. Geological Survey Open-File Report 2011-1136, 23 p.

Salvo mención en contrario, las organizaciones citadas en este artículo pertenecen al ámbito de los Estados Unidos, y su mera mención no implica ningún apoyo o patrocinio.

El artículo completo puede ser consultado visitando la siguiente página web: http://pubs.usgs.gov/of/2011/1136/

2. Introducción

The National Map (www.nationalmap.org) es un esfuerzo colaborativo entre el USGS y colaboradores a nivel Federal, Estatal y local, para suministrar información topográfica para los Estados Unidos. La información geográfica inclute ortofotografías (fotografías aéreas), elevación, toponimia, hidrografía, líneas límite, transporte (incluyendo carreteras), estructuras, y uso del suelo. The National Map es una contribución significante a la Infraestructura de Datos Espaciales Nacional (NSDI) y actualmente está siendo transformado para servir mejor a la comunidad geoespacial, al ofrecer datos y servicios geoespaciales integrados y de alta calidad a través de Internet, incluyendo mapas topográficos digitales de nueva generación.

El USGS está respondiendo a los cambios en la producción y compartición de los datos a través de Internet, explorando colaboraciones con clientes y productores de datos no tradicionales (Sugarbaker et al, 2009)[11]. La Web Geoespacial (Scharl y Tochterman, 2007)[10], o la unión de localización con información y contenidos de Internet, ha democratizado la producción cartográfica en línea. El acceso civil a la señal del Sistema de Posicionamiento Global (GPS), la disponibilidad de interfaces de programación de aplicaciones (APIs) que permiten mezclar datos geoespaciales de diferentes fuentes dentro de una plataforma basada en mapas, la creciente madurez del software libre geoespacial, y la rápida proliferación de dispositivos móviles con capacidades geográficas han hecho más fácil para el público general acceder y utilizar datos espaciales en línea. Estos cambios técnicos han promovido una cultura de mapeamiento colaborativo en línea por usuarios que no son profesionales de las ciencias y Sistemas de Información Geográfica (SIG). Esta tendencia a recolectar y usar datos cartográficos por parte de usuarios no profesionales ha sido denominada Información Geográfica Voluntaria (VGI) (Goodchild, 2007)[4]. En lugar de ser meros usuarios pasivos de los mapas y datos de fuentes oficiales, estos usuarios son capaces de producir sus propios datos e innovadoras tecnologías geográficas.

Históricamente, el USGS ha llevado a cabo programas para que los voluntarios pudiesen contribuir datos a los mapas topográficos del USGS. En la década de los 90, el Cuerpo voluntario de Ciencias de la Tierra llevó a cabo el programa "adopta un quad¹", anotando revisiones en potencia sobre mapas en papel y enviándolos por correo al USGS. En la era de Internet, cambió de nombre para pasar a ser el Cuerpo del National Map. El énfasis se ponía en la recolección y edición de información sobre estructiras; incluyendo el proporcionar información sobre la localización de edificios como parques de bomberos, colegios y oficinas de correos. Poco después de empezar el programa, los ciudadanos enviaron los nombres y coordenadas GPS de las estructuras a través de un portal web. Un sistema posterior basado en ArcIMS de ESRI permitió una metodología de digitalización para la captura de datos. Este programa fue interrumpido debido a motivos presupuestarios.

Queriendo volver a evaluar la posibilidad de un programa de cartografía voluntaria, el USGS organizó un taller sobre I.G. Voluntaria en enero del 2010 (USGS VGI Workshop) (http://cegis.usgs.gov/vgi/index.html). El taller reunió a representantes de diferentes organizaciones con experiencia en información geográfica voluntaria, desde esfuerzos de ciencia ciudadana (por ejemplo, el Programa de Observación Cooperativa del NOAA²) pasando por identificación masiva en línea de fotografías históricas (por ejemplo, la Biblioteca del Congreso) y empresas que usan voluntarios y sensores en sus coches para actualizar redes viarias (por ejemplo, TeleAtlas), hasta una organización sin ánimo de lucro que construye un mapa del mundo creado únicamente por voluntarios (OpenStreetMap, www.openstreetmap.org).

3. Descripción del problema

Incluso después de que el taller de VGI del USGS demostrara que hay un número creciente de programas que usan información suministrada por voluntarios, en los sectores público, privado y sin ánimo de lucro, hay numerosas cuestiones que necesitan ser exploradas para poder evaluar la utilidad y efectividad de la VGI por parte del USGS en la creación del National Map. Estas cuestiones son:

¿Cómo de precisos son los datos?
De entre las conclusiones del taller, una de las cuestiones más urgentes está relacionada con la precisión de los datos: ¿Cómo de precisos son los datos voluntarios? Algunos programas de ciencia ciudadana como el Conteo Navideño de Pájaros de Audubon llevan en marcha varias décadas y su precisión está estudiada y contabilizada (Cohn, 2008)[2]; sin embargo, estos programas cuentan con protocolos altamente estructurados diseñados por científicos profesionales, y proporcionan entrenamiento intensivo a los voluntarios. El caso de la información geográfica voluntaria es más problemático, puesto que es un fenómeno relativamente reciente y tiene muchas variaciones (Goodchild, 2007)[4].

¿Qué tipo de tareas se adaptan bien a la recolección voluntaria de datos?
No todas las clases de datos espaciales se adaptan bien a la recolección voluntaria, debido a distintas necesidades de precisión, compleción y frecuencia de actualización. También hay consideraciones sobre la complejidad y seguridad, así como relaciones entre los diferentes conjuntos de datos. Las entidades con una geometría que pueda ser identificable visualmente mediante imágenes aéreas, o mediante trabajo de campo con GPS, como los edificios y carreteras, son más susceptibles de ser recolectadas por voluntarios, al contrario que entidades más abstractas como fronteras políticas. Los atributos de una entidad también tiene un impacto en cómo de bien un tipo de entidades se recolecta con voluntarios. Las entidades con atributos muy complejos que necesitan de un control de calidad significativamente superior no se prestan tan bien a esfuerzos voluntarios como lo hacen las entidades con atributos simples.

Los métodos de Información Geográfica Voluntaria permanecen sin ser probados en los sistemas de producción de los institutos geográficos nacionales, que tienen requisitos muy particulares sobre controles y revisiones de calidad de los datos. Los proyectos de edición colaborativa no espacial, como Wikipedia, cuentan con voluntarios específicamente asignados a la tarea de moderar y revisar contribuciones de otros voluntarios. Los esfuerzos actuales de mapas colaborativos, como OSM, no cuentan
specíficamente con una estructura de moderación y revisión de los datos; en cambio, dependen de la comunidad de voluntarios en pleno para identificar y corregir datos erróneos o vandalismo. El Prototipo Colaborativo del USGS servirá como un ensayo para comprobar si los voluntarios son capaces no sólo de recolectar datos, sino también de revisarlos, probarlos, y certificarlos a los institutos geográficos.

¿Qué motiva a los voluntarios?
En el taller de VGI del USGS se discutió sobre cómo motivar y mantener el interés de los voluntarios, siendo un asunto a considerar a la hora de crear un programa voluntario de recolección de datos. Se observó que los voluntarios necesitan tener una razón tangible para compartir su tiempo, conocimiento y esfuerzo. La motivación voluntaria puede incluir el estar involucrado en una comunidad que simboliza algo más grande que ellos mismos, y el devolver algo a esa cominidad; un hobby; un interés en una geografía particular y el deseo de mejorar su apariencia en un mapa libre; el poder disfrutar de datos de calidad para sus propios proyectos; recompensas y reconocimiento; o simplemente curiosidad.

¿Cuál es la mejor manera de estructurar estos programas y proporcionar incentivos?
Se puede establecer un buen programa voluntario a través de diferentes estructuras y organizaciones del proyecto. En el taller de VGI del USGS se discutieron muchos esfuerzos de recolección de datos voluntarios ya existentes, con diversas estructuras: Wikipedia, el Conteo Navideño de Pájaros de Audubon, OSM, etcétera. El USGS está en el proceso de evaluar cuál de estos modelos de proyecto es el que mejor funciona a la hora de establecer un programa para contribuir al National Map.

¿Cómo pueden los datos voluntarios ser integrados con datos producidos por organizaciones profesionales?
The National Map tiene necesidades particulares para datos autoritativos, no como proyectos como OpenStreetMap que proclaman no ser fuentes autoritativas de datos. El cómo certificar e integrar los datos voluntarios en el National Map son problemas significativos que no han sido investigados con anterioridad por la comunidad geoespacial.

¿Cuál es la relación coste-beneficio de usar datos voluntarios?
La utilidad, precisión, y compleción de los datos recolectados por voluntarios son investigados, junto a los costes asociados. Los resultados de este análisis costebeneficio serán un factor determinante en el futuro del programa.

¿Cómo de sostenibles son estos programas voluntarios?
Mantener a los contribuidores voluntarios involucrados a largo plazo es una cuestión discutida en detalle durante el taller VGI del USGS. El consenso fue que es para los voluntarios es más fácil crear nuevos datos, y más difícil actualizarlos, mantenerlos y validarlos. El cómo proyectos exitosos como Wikipedia y OSM han logrado mantener estables las contribuciones voluntarias todavía no ha sido estudiado.

¿Cómo de bien se podrían integrar los sistemas web de recogida de datos ya existentes en los esfuerzos VGI del USGS?
Una evaluación de los sistemas existentes para datos contribuidos por los usuarios reveló que la pila de software de OSM ha conseguidoun éxito real y parece prometedor.

4. Enfoque del proyecto OSMCP

El USGS ha puesto en marcha un proyecto de investigación, el OSMCP, para intentar resolver algunas de las cuestiones que el taller de VGI del USGS planteó. La Fase Uno se inició en el año fiscal 2010 (FY2010) y estuvo limitada a evaluar la idoneidad de sistemas de recolección de datos via web existentes para uso de VGI por parte del USGS. La Fase Uno estuvo enfocada a crear un sistema para la edición colaborativa por parte de colaboradores del USGS sin incorporar contribuciones voluntarias. Las fases posteriores se añadirán a esta primera fase y expandirán el ámbito para incluir contribuciones voluntarias no profesionales.

Se construyó un protitipo usando el mismo software libre que utiliza OSM. Este software fue replicado, desplegado, y personalizado en un sistema del USGS. Se insertaron datos desarrollados por una organización colaboradora del USGS, que fueron editados tanto por el USGS como por esta organización colaboradora en un entorno web. La Fase Uno incluye los siguientes componentes:

Seleccionar y desplegar hardware y software
Desarrollar documentación, incluyendo especificaciones para la edición colaborativa de datos de carreteras para el National Map.
Elegir un colaborador (y datos proporcionados por él) para su edición colaborativa.
Cargar y editar datos en el entorno de OSM.
Evaluar los datos resultantes tras la edición colaborativa.

El OSMCP empezaría con un prototipo que pueda ser utilizado para adquirir experiencia en edición colaborativa y poner en marcha una infraestructura para las siguientes fases del proyecto. Las subsiguientes fases del OSMCP se construirán sobre la Fase Uno y continuarán explorando el uso de VGI en el USGS. Hay planes para que las fases futuras involucren a grupos de usuarios más grandes, incluyendo contribuciones de grupos de voluntarios. Se intenta que la Fase Uno sea un primer hito en el proceso de incrementar la capacidad del sistema para dar respuesta a las cuestiones del taller VGI del USGS con respecto a precisión, motivación de los voluntarios, y coste-beneficio.

5. Materiales y métodos

La Fase Uno del proyecto incluye el explorar la capacidad de una herramienta de edición colaborativa en web para facilitar la co-edición inter-agencias y la integración de los datos en el National Map.

5.1 Selección y despliegue del software y hardware
En el taller VGI del USGS se discutieron varios sistemas software para recolectar información geográfica contribuída. Los factores tenidos en cuenta para elegir el software para el proyecto incluyeron:

Interfaz amigable al usuario que pueda ser utilizada con efectividad con sólo un mínimo de formación o documentación;
Bajo coste y compatibilidad con el hardware del USGS ya existente;
Sin necesidad de licencias de usuario para los contribuidores de datos;
Que el soporte técnico del USGS pueda aprender a resolver problemas y dudas sobre el sistema;
Que la funcionalidad básica aguante de manera simultánea un alto número de usuarios:
◦ Editando via web con un navegador, incluyendo Internet Explorer, Mozilla Firefox y Apple Safari,
◦ Creando y editando entidades espaciales incluyendo su posición y atributos a través de digitalización en puestos de trabajo,
◦ Mostrando una imagen ortorrectificada como fondo de digitalización,
◦ Personalizando los tipos de entidad y sus atributos sin programar,
◦ Almacenando o transfiriendo los datos a una base de datos fácilmente exportable a ArcGIS de ESRI.

Se consideraron las siguientes opciones para la arquitectura software:

Contribuciones directas de la USGS a OSM (www.openstreetmap.org)
Descarga y uso de OSM como parte del National Map.
Modificación de las herramientas de edición administrativa de los Datos Nacionales de Hidrografía (NHD) del USGS (http://webhosts.cr.usgs.gov/steward/scripts/st2_software.pl).
Modificación de la Herramienta de Edición Web del NHD de Alabama (http://nhdwet.alabama.gov/)
Desarrollar una nueva aplicación personalizada basada en ArcGIS Server de ESRI or el software de servidor de mapas GeoServer (www.geoserver.org)
Usar la arquitectura software de OSM con una base de datos de dominio público.

Una de las opciones consideradas en el taller VGI del USGS fue incentivar que el personal del USGS seleccione y recopile información útil de OSM para incluirla en el National Map. Esta opción no se persiguió dado a la licencia de los datos. Los datos en OSM se encuentran bajo una licencia Creative Commons Compartir Igual (www.openstreetmap.org/copyright), que obliga a cualquier persona utilizando los datos el ofrecer las modificaciones de vuelta a la comunidad bajo la misma licencia. No hay restricciones sobre el uso o redistribución de los datos. Esta diferencia hace que el USGS no pueda recopilar datos de OSM y ponerlos después en el National Map, puesto que debe ser una fuente de datos en el dominio público.

Otra alternativa considerada para una plataforma VGI del USGS fue el modificar el software de administración del NHD. El NHD es la capa de hidrografía del National Map y se mantiene a través de una red de administradores-contribuidores. Estos administradores reciben formación y soporte, y se les anima a firmar acuerdos de colaboración con el USGS. El software desarrollado para procesar los cambios del NHD necesita una licencia software de ArcGIS de ESRI. El software de actualización de NHD está diseñado específicamente para gestionar los tipos de datos del NHD. El NHD utiliza una representación topológica; el software está diseñado específicamente para ese tipo de representación de los datos. No se persiguió esta opción debido a la necesidad de una licencia de usuario de ArcGIS por usuario, y por la complejidad de ArcGIS en comparación a otras herramientas comparables de edición web.

Además de las herramientas creadas por el USGS para contribuciones de usuarios al NHD, la Herramienta de Edición Web (WET) de Alabama depende de un ArcGIS Server y todavía estaba en fase de desarrollo durante el taller de VGI. La WET necesita un login de software, y las ediciones no son incorporadas directamente al conjunto de datos hasta que son revisadas por un administrador del NHD. Esta opción no se persiguió debido a la limitación en el flujo de trabajo y a que la herramienta todavía estaba en desarrollo durante el inicio de la investigación.

Una cuarta opción era construir una aplicación web personalizada para apoyar los esfuerzos de VGI del USGS usando alguna de las muchas herramientas de geoprocesamiento y de servidor de mapas existentes, o bien comerciales o bien libres, como por ejemplo ArcGIS Server de ESRI, o GeoServer. El coste de desarrollo de tal aplicación personalizada sería prohibitivo.

La última opción tenida en consideración (y la que fue adoptada en última instancia) requería que el software de OSM fuera replicado en los sistemas del USGS. OSM es uno de los esfuerzos más ambiciosos para producir un mapa base del mundo a través de contribuciones voluntarias. La comunidad OSM, que tuvo una buena representación en el taller de VGI del USGS, propuso que el USGS utilizase la arquitectura de software libre que hay detrás de OSM. Esta arquitectura de software está bien documentada, es fácil de configurar, no necesita de ninguna licencia de software adicional para los usuarios del sistema, y tiene una gran comunidad de contribuidores, desarrolladores de software libre, y contribuidores en foros y en el wiki que pueden solventar dudas y cuestiones técnicas. La interfaz de edición de OSM es fácil de utilizar, y fue evaluada por el personal del USGS para verificar que abarca todas las funciones todas las funciones de edición necesarias para permitir que los datos sean integrados en el National Map. El software de OSM es fácil de modificar, configurar y personalizar para adecuarse al proyecto. La decisión de utilizar el software de OSM en la Fase Uno de este proyecto se hizo debido a su facilidad de uso, licenciamiento libre, potencial soporte y ayuda, y el liderazdo que la comunidad de OSM ha mostrado al utilizar cartógrafos voluntarios en la web.

5.2 El sistema software del OSMCP
La comunidad de OSM ha desarrollado una arquitectura de software sustancial (OpenStreetMap, 2010) para recolectar la información espacial generada por los usuarios. El software es gratis y está bajo licencias libres; utiliza el sistema operativo Linux, servidor web Apache, arquitectura web Ruby on Rails, y una base de datos relacional PostgreSQL (véase Figura 1). Una variedad de diferentes aplicaciones han sido desarrolladas para facilitar las contribuciones de usuarios, incluyendo el editor Potlach y Potlach 2, empotrados en páginas web, los clientes de escritorio JOSM y Merkaator, así como varias aplicaciones para iPhone. El software de OSM no impone ninguna estructura de datos más allá de nodos (puntos), vías (líneas, polígonos), y relaciones. Además, los atributos de las entidades en OSM se manejan a través de etiquetas ad hoc. No se impone ninguna ontología en los datos recolectados usando OSM.

Figura 1. Componentes de la arquitectura de sistemas de OSM (OpenStreetMap, 2010).

La arquitectura de sistemas de OSM se basa en un modelo distribuído, que consiste en una base de datos PostgreSQL con una capa intermedia, denominada API 0.6, desarrollada en Ruby on Rails (Figura 1). Algunas grandes importaciones y cargas de datos pueden hacerse de manera directa usando una herramienta demoninada Osmosis. La edición e importaciones de menor índole se realizan a través de la interfaz de la API 0.6 con herramientas como JOSM, Merkaator, y dentro de un navegador web, con Potlatch.

En la Fase Uno se ha usado un servidor físico sito en las instalaciones de NGTOC del USGS en Rolla, Missouri, conectado a Internet con una dirección públicamente accesible: www.navigator.er.usgs.gov. Este servidor se situó en una zona desmilitarizada (DMZ) detrás del Servicio de Aplicaciones Seguras Empresarial (eSAS) del USGS. Los servidores de la DMZ son accesibles desde la Internet pública. El eSAS protege a los servidores de la DMZ al filtrar peticiones web. El servidor tiene cuatro núcleos Intel Xeon 3.6GHz con 6 GB de RAM y 650GB de espacio en disco. El sistema operativo utilizado es Ubuntu Server 9.10 "Karmic Koala" 64-bit, con Apache 2.2 proporcionando el servicio de HTTP.

La interfaz web de OSM fue reconfigurada para el esquema de datos deseado para el National Map (Tabla 1) (http://nationalmap.gov/transport.html). El software de OSM no impone ninguna ontología o esquema de datos en particular. En el caso de la comunidad de OSM, el esquema de datos evoluciona a través de un proceso colaborativo. Uno de los principales desafíos en el OSMCP fue demostrar que el software de OSM puede ajustarse a un esquema predeterminado. La interfaz de Potlatch se reconfiguró para este esquema, editando varios ficheros de texto de configuración (véase apéndice B).

OSM	Mejores prácticas
highway:primary	highway:USHighway
name:West 6th Street	Full_Street_Name: W 6th ST
	State:KS
	Surface_Type:99
	US_Route1:US-40
	US_Route2:US-59
	Seodb_oid:162151

Tabla 1. Diferencias entre los esquemas de OSM y mejores prácticas del USGS.

El esquema de OSM resultó ser menos complejo que el esquema de Mejores Prácticas (BP). Por ejemplo, el editor Potlatch reconoce la clave de la etiqueta "highway" como un tipo de vía particular, que representa parte de una red viaria automobilística, pero no significa específicamente que sea una carretera de acceso limitado y de alta velocidad³.

En el esquema de OSM, algunos usos comunes de la etiqueta highway incluyen highway="calle residencial" y highway="vía de servicio".

Algunas modificaciones técnicas centradas alrededor del editor Potlatch se detallan en la Figura 2. Potlatch es un editor basado en Adobe Flash, escrito en ActionScript 1, diseñado para ser ejecutado dentro de un navegador web. La simbología vectorial en Potlatch se controla a través de una serie de ficheros de texto (listados en la Tabla 2) almacenados en el servidor. Los ficheros de Potlatch se modificaron para proporcionar una simbología más adecuada al esquema BP. La figura 3 muestra la interfaz de Potlatch con la simbología vectorial codificada para el esquema.

Figura 2. Componentes de la arquitectura de sistemas del OSMCP (subconjunto de Figura 1).

Fichero	Descripción
presets.txt	Listado tipo CSV con pares clave/valor comúnmente usados para nodos y vías
colours.txt	Lista separada por tabuladores de colores de relleno y línea usados al dibujar el mapa
relation_colours.txt	Lista separada por tabuladores de los colores de resalto usados para mostrar relaciones en el mapa
autocomplete.txt	SurfaceLista separada por tabuladores de los pares clave-valor usados en los menús de autocompleción

Tabla 2. Ficheros que definen la simbología vectorial de Potlatch (nótese la forma británica de "colour").

Figura 3. La interfaz de Potlatch con datos vectoriales sobreimpuestos a la capa de ortofotos
del National Map. La simbología está ligada al esquema de datos.

Editar en Potlatch es básicamente una experiencia de digitalización en pantalla. Aunque a los usuarios se les permite subir trazas de GPS en un fichero GPX, la práctica más común entre los contribuidores de OSM en áreas con buena cobertura de imágenes aéreas es dibujar encima de la ortofoto. En el sitio web de OSM (http://www.openstreetmap.org), Potlatch muestradatos vectoriales sobreimpuestos a ortofotos donadas por Microsoft Bing Maps, que proporcionan cobertura mundial a color a 0.3m (Meyer, 2010)[7].

En la Fase Uno del proyecto, se configuró una caché de teselas local para proporcionar el fondo de ortofotografía proveniente de la capa del National Map en vez de utilizar las imágenes aéreas de Microsoft. Esto sigue las directrices de calidad internas del NGTOC, puesto que al usar una capa de ortofotografías que mayoritariamente proviene del Plan Nacional de Imagen Aérea (NAIP) se puede determinar la calidad de los datos. Potlatch necesita que las imágenes sean servidas desde una caché de teselas "estilo Google", en la que las teselas se encuentran accesibles a través de HTTP como ficheros de imagen con direcciones adecuadas. Las teselas se extrajeron de un Servicio de Mapas Web (WMS) proporcionado por el National Map: Combined/TNM_Large_Scale_Imagery (MapServer) (véanse sus metadatos en http://raster.nationalmap.gov/ArcGIS/rest/services/Combined/ TNM_Large_Scale_Imagery/Map Server). Aunque el National Map ofrece ortofotos como un servicio teselado, las imágenes de tal servicio sólo abarcan los niveles de zoom del 1 al 11 (menos que aproximadamente una escala 1:220000) lo cual no ofrece el detalle suficiente como para dibujar entidades en Potlatch. Para poder identificar visualmente entidades en Potlatch, la edición tiene lugar en los niveles de zoom entre 16 y 20 (escalas mayores a aproximadamente 1:20000). El script de Python Tilecache 2.11 proporcionó los medios tanto para generar teselas dinámicamente como para hacer la "siembra"[sic] inicial de la caché. La mayoría del área de estudio para la Fase Uno fue sembrada de antemano, pero el proceso fue demadiado lento como para completarse antes de que los colaboradores recolectadan datos durante la Fase Uno del OSMCP.

5.3 Desarrollando especificaciones de edición de datos colaborativa
El USGS mantiene directrices para los datos de carreteras contribuídos al National Map. Estas directrices incluyen información sobre precisión espacial, representación de las geometrías, compleción, topología, y reglas de sus atributos (J. Walters y G. Matthews, USGS, sin publicar, 2010). Para que el USGS incorpore datos de terceros, incluyendo otros organismos y/o voluntarios, es necesario que los terceros cumplan con unas especificaciones mínimas para asegurarse de que los datos son de una calidad suficiente para el National Map. Para el proyecto de la Fase Uno, al colaborador se le pidió cumplir los requisitos mínimos del estándar del USGS para carreteras. Llegar a un acuerdo en las especificaciones crea métodos de trabajo similares a través de varios niveles gubernamentales y públicos, lo cual es la situación ideal. Este tipo de convenciones no siempre es posible con todos los potenciales colaboradores y voluntarios.

5.4 Eligiendo una entidad colaboradora (y sus datos) para la edición colaborativa
Se eligió al Centro de Soporte y Acceso de Datos de Kansas (DASC) como entidad colaboradora para este proyecto. El DASC se eligió por dos razones principales: primero, el DASC estaba dispuesto a proporcionar tiempo y personal al proyecto; segundo, los datos de carreteras en posesión del DASC, a nivel de estado, estaban parcialmente completos. La calidad de estos datos en relación a los datos de carreteras del Censo fue evaluada en un informe interno del NGTOC (G. Matthews, USGS, sin publicar, 2009). El informe concluyó con que los datos del DASC tienen una precisión posicional similar a los datos del Censo y sus atributos encajan bien con el Modelo de Datos de Mejores Prácticas. Sin embargo, los datos del DASC carecían de la representación estándar de dobles calzadas y nudos de enlace. Esta deficiencia específica en la representación geométrica proporcionó un punto donde centrarse en el proceso de co-edición del OSMCP.

Se seleccionaron los condados de Douglas y Johnson en Kansas como áreas de interés para su edición. El DASC está en el condado de Douglas. El condado de Johnson es adyacente a Douglas y abarca las áreas metropolitanas de Lawrence, así como gran parte de Kansas City. Se eligió este área debido a la variedad de tipos de entidades de carretera y porque el personal del DASC tiene un conocimiento del terreno razonable en ese entorno (Figura 4).

Figura 4. Área de interés para la Fase Uno del OSMCP.

5.5 Preprocesamiento y carga de datos en entorno OSM
Los pasos de preprocesamiento para la Fase Uno del proyecto se llevaron a cabo en dos etapas. Primero, el DASC asimiló los datos de carreteras hasta nivel de estado para crear un conjunto de datos de carreteras consistente. Después, el USGS procesó las carreteras del DASC usando el Motor de Manipulación de Entidades (FME) de Safe Software, para cruzar los atributos con el esquema de Mejores Prácticas para Transporte del USGS, y convertirlo desde una Geodatabase Personal a formato XML de OSM (Figura 5). Esto proporcionó un conjunto base de carreteras con atributos consistentes.

Figura 5. Conversión de atributos de carreteras del DASC a esquema de mejores prácticas usando FME 2011 beta.

Los pasos de geoprocesamiento incluyeron: evaluar auto-intersecciones en líneas, ejecutar un filtro de geometría para comprobar el tipo de entidad, ejecutar un proceso de encajado para resolver problemas de geometría (p. ej. líneas duplicadas), detectar y quitar astillas (slivers), ejecutar un proceso de ajuste para asegurar conectividad en la nueva red y, por último, convertir las geometrías de carreteras de Kansas al esquema del USGS.

Despúes de que se completara el procxeso inicial, el fichero resultante fue convertido a formato OSM para poder ser cargado en la base de datos PostgreSQL de OSM. Esto fue un proceso sencillo que involucró copiar atributos, detectar ciertas cadenas de texto para ayudar a identificar tipos de vía, y luego escribir el fichero OSM final (Figura 6).

Figura 6. Conversión de datos preprocesados a formato nativo de OSM.

5.6 Edición colaborativa de los datos de carreteras de Kansas en entorno OSM
Un miembro del NGTOC supervisó la edición de carreteras con el DASC, y verificó que los datos editados cumplían con todos los estándares del USGS. En el área de interés del proyecto, el USGS se responsabilizó de la edición de autovías interestatales, rutas, y los enlaces y vías de servicio correspondientes. Esta edición cubrió un total de 435 kilómetros con un coste aproximado de 88 horas. Esta edición preliminar del USGS se completó antes de que el colaborador se involucrara.

Para poder ayudar al DASC en familiarizarse con la interfaz web del OSMCP, un miembro del USGS se desplazó hasta las dependencias del DASC y pasó tiempo con su personal; ayudándoles a entender el software y los procedimientos a ser usados en la edición de datos. El DASC fue responsable de las rutas estatales, unos 115 kilómetros de carretera con un coste de unas 40 horas. Accedieron a la interfaz web de Potlatch a través de un navegador normal, como Mozilla Firefox o Microsoft Internet Explorer. Aunque los editores tanto del USGS como del DASC informaron de que la interfaz web es eficiente y fácil de usar, hubo un problema de edición por parte del DASC. Una sección de las carreteras importadas inicialmente estaba colgando el navegador, debido a un número de puntos inusualmente alto. Este problema pudo ser ocasionado inicialmente por "streaming" de puntos, un caso donde un editor puede haber no cerrado una sesión a tiempo. Este tipo de problema puede incluso causar que un equipo de escritorio se ralentice mientras intenta cargar miles de puntos de una única sección de línea. En el futuro, errores de datos como este pueden ser prevenidos por el USGS si se simplifican los datos con FME antes de cargarlos en la base de datos de OSM.

6. Resultados de datos de la Fase Uno del OSMCP

El proceso de edición se centró en deficiencias específicas en los datos del DASC identificados en un informe interno (G. Matthews, USGS, sin publicar, 2009). Se quería de antemano que los datos de carreteras cumplieran con los requisitos del NGP para precisión posicoinal, y que los atributos estaban preparados para ser compatibles con el esquema de Mejores Prácticas. La tabla 3 muestra un sumario de cambios de los datos resultantes tras finalizar la Fase Uno. El incremento en el número de entidades y longitud de carreteras interestatales se debe mayormente a la mala o inexistente representación de vías de doble calzada en los datos iniciales de Kansas. Los cambios a las vías de incorporación y salida no han sido capturados correctamente en este sumario, pero son evidentes visualmente como se puede apreciar en la Figura 7.

				Tipo de vía
		Interestatal	Ruta EEUU	Ruta estatal	Enlaces	Total
Datos originales	Entidades	22	310	136	48	516
	Km.	119	183	95	14	412
Datos finales	Entidades	37	341	179	48	605
	Km.	196	222	116	16	550
Cambios	Entidades	15	31	43	0	91
	Km.	77	39	21	2	138
% cambio	Entidades	68%	10%	32%	0%	18%
	Km.	65%	21%	22%	11%	34%

Tabla 3. Comparación de datos de carreteras del DASC para los condados de Douglas y Johnson.

Figura 7. Izquierda: enlace sin editar. Derecha: intersección corregida con incorporaciones.

Además de ediciones centradas en vías de doble calzada y representación de enlaces, se realizaron muchas mejoras menores en los datos tanto por el personal del NGTOC como por el del DASC, que no se muestran en la tabla superior.Muchas entidades mostraban discrepancias menores en su representación con respecto a la ortofotografía, como por ejemplo tramos cortos en Interestatales. En la mayor parte, estos problemas entran dentro de la tolerancia de error especificada por las Mejores Prácticas del NGP. Sin embargo, la naturaleza de la interfaz del OSMCP permite al usuario identificar y corregir rápidamente estos pequeños errores posicionales. De igual manera, se realizaron muchas pequeñas mejoras a los atributos cuando el usuario los advierte, como por ejemplo un uso consistente de abreviaturas y uso de mayúsculas. No se realizó una medición de estos cambios menores.

6.1 Análisis del software OSM para edición colaborativa
El software de OSM proporciona una plataforma fácil de usar, que se ejecuta en un navegador web, y que permite co-edición por personal geográficamente disperso. Durante el proceso se identificaton los siguientes resultados positivos y negativos.

Positivo

OSM y su software tiene mayor soporte y apoyo por parte de la comunidad de I.G. Voluntaria que los otros sistemas en consideración
◦ ArcGIS 10 soporta editar datos a través de la API 0.6.
◦ FME 2011 soporta leer y escribir el formato XML de OSM.
◦ Existen múltiples herramientas gratis y libres además del editor Potlatch que se consideran parte del núcleo de la infraestructura.
El software de OSM es razonablemente sencillo de configurar y utilizar
◦ El software es gratis y sin restricciones por licencias.
◦ El software se puede utilizar en múltiples puestos sin necesidad de negociar nuevas licencias de software.
Varias agencias pueden editar los mismos datos con las mismas especificaciones a la vez.
◦ La detección de conflictos funciona bien.
◦ Se realiza control de versiones automático y no se necesita hacer una copia local de los datos antes de editarlos.
◦ La plataforma soporta miles de sesiones de edición simultáneas.
◦ El proceso de edición en Potlatch (en un navegador) es mucho más rápido y fácil que ArcGIS.
◦ Potlatch permite crear datos geoespaciales complejos sin necesidad de experiencia técnica

Negativo

Configurar el software necesita de personal con conocimientos de Linux, Ruby on Rails y PostgreSQL.
Existen pocas oportunidades de formación para desarrollar un buen nivel de competencia con estas herremientas. El personal que trabaje con el proyecto necesita entirse cómodo siendo autodidacta para con las herremientas de OSM (Steve Coast, omunicación escrita, 2010).
Algunos artefactos en los datos pueden sobrecargar la base de datos de OSM.
El software de OSM no puede manejar buen números extremadamente grandes de bjetos en una pantalla. Por ejemplo, algunas de las entidades de carreteras del DASC ontenían un número inusualmente grande de puntos (miles de puntos en un tramo de arretera recta de un kilómetro de largo). Las consecuentes llamadas a la API y queries QL tomaban mucho más tiempo del esperado.
Trabajar en la DMZ del USGS puede dar lugar a problemas.
La API 0.6 de OSM es una aplicación de Ruby on Rails. Usa HTTP para la omunicación cliente-servidor. El proxy eSAS incluye ficheros para detectar tráfico TTP "inusual" de y hacia los servidores dentro de la DMZ (USGS, 2010)[11]. La comunicación entre el cliente Potlatch y la API estaba siendo continuamente impedida por el filtro eSAS, porque las URLs pasadas al servidor no son fácilmente predecibles. Al contratio que los filtros y proxy web usados por los usuarios de escritorio del USGS, el proxy eSAS bloquea el tráfico, sin proporcionar errores específicos como "bloqueado por cortafuegos". Un cortafuegos con filtrado agresivo cautó lo que parecía ser problemas en la configuración de la aplicación. Inicialmente fue difícil determinar si el problema estaba en la configuración del servidor, o en alguna otra parte. Se gastó una cantidad significante de esfuerzo comprobando la configuración de los servidores y preguntando a la comunidad de OSM antes de sospechar del cortafuegos.
Los editores de OSM están diseñados para un control de calidad cualitativo, no cuantitativo.
La filosofía detrás de OSM se basa en calidad implícita en vez de en calidad explícita. OSM no tiene en cuenta ninguna medida cuantitativa de calidad de los datos, tal como precisión posicional o actualidad. En su lugar, se supone que los usuarios de OSM identificarán errores de calidad en el mapa, específicamente en las entidades en el área local del usuario, y que las corregirá hasta llegar a la mejor representación posible. Las herremientas diseñadas por la comunidad de OSM reflejan una noción de calidad siguiendo el principio de la Ley de Linus, que dice que "si hay suficientes ojos, se pueden ver todos los errores" (Raymond, 2001). Esto quedó demostrado por las pequeñas ediciones de tipo posicional y atributos que quedaban fuera del ámbito de la Fase Uno.

7. Discusión y dirección futura

La Fase Uno del OSMCP ha probado que es posible crear y mejorar datos según las especificaciones del USGS a través de un prototipo de I.G. voluntaria. El esfuerzo terminó con la creación de un sistema funcional para contribuciones de entidades colaboradoras a través de edición colaborativa de datos espaciales, por múltiples organizaciones en un entorno distribuído. La plataforma prototipo de I.G. voluntaria proporciona un punto de partida para, en el futuro, seguir evaluando la utilidad y efectividad de la I.G. voluntaria para el National Map.

7.1 Fase Dos
En la Fase Uno, las entidades colaboradoras externas al USGS que contribuyeron con ediciones eran parte de una única oficina de información geográfica estatal. El DASC es una organización formalmente estructurada, con experiencia profesional en SIG. La Fase Dos no se centrará en carreteras, sino en la capa de estructuras. Históricamente, el cuerpo del National Map se centró en datos de estructuras. Son algo menos complejos que los datos de carreteras, pues consisten únicamente en puntos sin relaciones topológicas, en lugar de líneas o arcos con una topología relativamente compleja. La Fase Dos se construye a partir de la plataforma OSM ya existente, pero se actualizará la interfaz de usuario para usar Potlatch 2. Esta nueva versión de Potlatch proporciona una mayor flexibilidad para incorporar especificaciones de datos específicas a una organización. Se crearán conjuntos de teselas de fondo de mapa adicionales, a partir de servicios de mapas web (WMS) ofrecidos como parte del National Map (http://services.nationalmap.gov/ArcGIS/rest/services/TNM_Vector_Large/MapServer) y mapas topográficos escaneados (http://raster.nationalmap.gov/ArcGIS/rest/services/DRG/TNM_Digital_Raster_Graphics/

La Fase Dos se centrará también en incorporar un componente más público, basado en voluntarios. En lugar de trabajar con una organización estatal especializada en SIG, el USGS involucrará a clubs de aficionados de SIG en las universidades del área de Denver, para recoger de manera sistemática datos de estructuras para los quads topográficos de 7.5 minutos del área de Denver: Arvada, Commerce City, Fort Logan, y Englewood. Esto permitirá al USGS entender la cantidad y calidad de los datos recolectados por voluntarios. Debido a que la fase 2 involucrará a una audiencia más amplia y menos formal, se prestará especial atención a los elementos de la interfaz del OSMCP para asegurarse de que cumplen fielmente las especificaciones del USGS. Uno de los conceptos básicos del diseño centrado en el usuario es construir interfaces que guíen al usuario naturalmente a través de los pasos correctos de un proceso. Al prestar atención a los detalles de la interfaz de usuario, el usuario final tendrá menos problemas siguiendo las directrices de recogida de datos.

Otra meta importante de la Fase Dos será explorar métodos para no sólo entender la calidad de los datos de voluntarios, sino también gestionar el control de calidad de los datos que se recogen. Se explorarán métodos que involucren "editores de usuarios". En otras palabras, el proyecto incluirá una investigación de el uso de voluntarios para realizar el control de calidad sobre los datso recogidos por otros voluntarios. Además, se explorarán métodos cuantitativos para determinar el nivel de compleción. Se identificarán los errores de estructuras mal identificadas (errores de comisión o de atributos), así como métodos para estimar estructuras no presentes (errores de omisión). Una posible técnica implica comparar los datos contra conjuntos de datos ya existentes como los del Sistema de Información de Nombres Geográficos (GNIS). Estos métodos para estimar la calidad serán un factor importante para determinar los siguientes pasos del uso de datos de voluntarios en el National Map.

7.2 Fase Tres
Si los resultados de la Fase Dos indican que la incorporación de datos provenientes de voluntarios proporcionan datos de calidad a un coste menor que otros métodos de recogida de datos, la Fase Tres del OSMCP expandirá la recogida de datos de estructuras a áreas más diversas. Usando los quads de 7.5 minutos como una estructura organizativa para monitorizar la calidad de los datos, se elegirán quads específicos para probar la capacidad de los datos contribuídos por usuarios, especialmente en áreas rurales (Brando, 2010; Girres, 2010; Haklay, 2010)[1]. Entender cómo incentivar actividades de recogida de datos en estas áreas hará que se cumpla mejor el objetivo de cobertura uniforme del National Map. Se involucrará un abanico más amplio de voluntarios (Tabla 4). Diferentes grupos de voluntarios proveerán diferentes oportunidades de sostenibilidad. Por ejemplo, la captura inicial de grandes áreas remotas puede necesitar de grupos más preparados técnicamente como clubs de SIG. Sin embargo, el mantenimiento puede ser gestionado mejor a través de revisiones regulares por grupos de escuelas primarias, donde un nuevo grupo de voluntarios puede revisar los datos cada año.

Miembros ya existentes del Cuerpo del National Map	Departamentos de bomberos voluntarios
Comunidad de OSM	Clubs de 4H (asociaciones juveniles promovidas por el Ministerio de Agricultura)
Clubs de SIG	Clases de escuelas de primaria
Clases de cartografía/SIG en universidades

Tabla 4. Grupos potenciales de voluntarios para la Fase Tres.

La Fase Tres implicará menos cambios tecnológicos a la plataforma, prestándose mayor atención al aspecto de la interfaz para cumplir con los estándares del USGS. Se han sugerido varios modelos de calidad de datos para la información geográfica voluntaria. Un modelo importante se centra en la calidad de los contribuidores de datos (Grira et al, 2009)[5]. La Fase Tres utilizará métodos automatizados para estimar la calidad, cuando y donde sea posible, para crear indicadores de calidad para los usuarios. El nivel de formación necesaria puede ser variado a través de los distintos grupos de voluntarios, para determinar la formación necesaria para cumplir con los estándares de calidad de datos.

Agradecimientos
Este proyecto no habría sido posible sin el apoyo actico del Centro de Soporte y Acceso de Datos, los esfuerzos del personal de Soporte de Tecnologías de la Información del NGTOC en Rolla, y el interés y entusiasmo de la comunidad de OSM. Austin Green proporcionó un valioso apoyo durante la creación de los tados traducidos mediante FME 2011. HEnnifer Walters creó el documento de especificaciones de edición usado en el proyecto. A través de la comunidad de OSM, recibimos comentarios a través de listas de correo que beneficiaron directamente al proyecto; de Steve Coast, Richard Weait, Brett Henderson, IAn Dees, Andrzej Zaborowski, Matt Amos, Tom Hughes, Andy Allan, Shaun McDonald, Richard Fairhurst, Steve Bennett y Brendan Morley.

Notas
1. N. del T.: un quad es una hoja del mapa topográfico 1:24000 del USGS.
2 National Oceanic and Atmospheric Administration.
3 N. del T.: El highway norteameticano es similar a una autopista (de alta velocidad y acceso limitado), mientras que OSM usa highway en su sentido británico, que equivale a las carreteras convencionales españolas.

8. Bibliografía

[1] Brando, C. and Bucher, B., 2010, Quality in user generated spatial content-A matter of specifications, in Painho, M., Santos, M.Y. and Pund, H. eds., Proceedings of the 13th AGILE International Conference on Geographic Information Science, 11-14 May 2010, Guimarães, Portugal, p. 1-8.
[2] Cohn, J.P, 2008, Citizen science-Can volunteers do real research?: BioScience, v. 58, no. 3, p. 192-197.
[3] Girres, J.F. and Touya, G., 2010, Quality assessment of the French OpenStreetMap dataset: Transactions in GIS, v. 14, no. 4, p. 435-459, also available at http://dx.doi.org/10.1111/j.1467-9671.2010.01203.x.
[4] Goodchild, M.F, 2007, Citizens as sensors-The world of volunteered geography: GeoJournal, v. 69, no. 4, p. 211-221, also available at http://dx.doi.org/10.1007/s10708-007-9111-y.
[5] Grira, J., Bedard, Y., and Roche, S., 2009, Spatial data uncertainty in the VGI world-Going from consumer to producer: Geomatica, v. 64, no. 1, p. 61-71.
[6] Haklay, M., 2010, How good is volunteered geographical information? A comparative study of OpenStreetMap and ordnance survey datasets: Environment and Planning B-Planning and Design, v. 37, no. 4, p. 682-703, also available at http://econpapers.repec.org/RePEc:pio:envirb:v:37:y:2010:i:4:p:682-703.
[7] Meyer, D., 2010, Microsoft gives Bing Maps photos to OpenStreetMap: ZDNet-UK, last accessed 23 December 2010 at http://www.zdnet.co.uk/blogs/communication-breakdown-10000030/microsoftgives-bing-maps-photos-to-openstreetmap-10021150/ .
[8] OpenStreetMap, 2010, OpenStreetMap Wiki-Component overview: last accessed 15 Aug 2010 at http://wiki.openstreetmap.org/wiki/Component_overview.
[9] Raymond, E.S., 2001, The cathedral & the bazaar-Musings on Linux and Open Source by an accidental revolutionary: Sebastopol, CA, O'Reilly Media, 241 p.
[10] Scharl, A. and Tochterman, K., 2007, The geospatial web: London, Springer, 282 p.
[11] Sugarbaker, L., Coray, K.E., and Poore, B.S., 2009, The National Map customer requirements- Findings from interviews and surveys: U.S. Geological Survey Open-File Report 2009-1222, 34 p., also available at http://pubs.usgs.gov/of/2009/1222/.
[12] U.S. Geological Survey, 2010, DMZ & Infrastructure Team-Enterprise Secure Applications Service (eSAS): last accessed 1 February 2011 at http://itsot.usgs.gov/dmz/eweb/index.html.

Aplicação da Directiva INSPIRE em Portugal - Monitorização 2011

Mon, 13 Feb 2012 00:00:00 +0100

APLICAÇÃO DA DIRECTIVA INSPIRE EM PORTUGAL - MONITORIZAÇÃO 2011

J. Geirinhas, A. L. Gomes, A. Fonseca, A. S. Santos, H. Silva, R. P. Julião
Instituto Geográfico Português

1. Introdução

A Directiva INSPIRE pretende viabilizar a disponibilização de conjuntos e serviços de dados geográficos de acordo com princípios e regras comuns, com o intuito de permitir a qualquer utilizador pesquisar, visualizar e aceder de um modo interoperável, a informação geográfica proveniente de diferentes Estados Membros (EM) [1].

A aplicação da Directiva implica o cumprimento pelos EM de um conjunto de disposições de execução relativas às diferentes componentes das respectivas infra-estruturas de informação geográfica (e.g. metadados, conjuntos e serviços de dados geográficos). A aplicação das disposições de execução é feita de forma faseada de acordo com os prazos estipulados na Directiva.

O acompanhamento da aplicação da Directiva nos diferentes EM é uma tarefa essencial para que de uma forma sistemática seja possível monitorizar a evolução da aplicação da Directiva no que toca às diferentes exigências que esta estabelece.

Por outro lado, a caracterização da situação de cada EM obtida através dos relatórios elaborados de três em três anos, permitirá perceber as especificidades de cada Estado Membro em termos de organização e coordenação, funcionamento e utilização das respectivas infra-estruturas, bem como no que se refere à dinâmica de partilha de dados geográficos entre Autoridades Públicas e aos custos e benefícios associados à implementação da Directiva.

A monitorização e caracterização da situação de cada EM face à Directiva INSPIRE poderá servir para identificar problemas e partilhar abordagens e soluções que no seu conjunto suportem a criação da Infra-estrutura Europeia de Informação Geográfica que se pretende venha a existir para apoio à definição e aplicação das políticas ambientais na Europa Comunitária.

2. Monitorização e relatórios: Obrigações dos Estados-Membros

Com vista a acompanhar a aplicação e utilização das respectivas infra-estruturas de informação geográfica, os EM devem apresentar à Comissão Europeia (CE) dados de monitorização (abordagem quantitativa) e relatórios (abordagem qualitativa) sobre a aplicação da Directiva INSPIRE. Os EM devem facultar os resultados desse acompanhamento à CE e ao público de forma permanente (Art.21º.1.), devendo efectuar anualmente a monitorização e enviar um relatório à Comissão, de três em três anos. Para a monitorização e apresentação de relatórios sobre a aplicação da Directiva INSPIRE, foram publicadas em Junho de 2009 disposições de execução pela CE (Decisão 2009/442/CE, de 5 de Junho) [2].

Para além das disposições de execução que estabelecem o que é exigido a cada EM, a CE disponibilizou também um documento de orientação técnica para a monitorização de indicadores (INSPIRE Monitoring Indicators - Guidelines Document. Version 5.0) [3], que explica como proceder à recolha da informação e como implementar a monitorização e elaboração de relatórios. Nestas orientações são descritos os procedimentos a usar no cálculo de indicadores e apesar de não ser disponibilizada uma ferramenta para a automatização da monitorização, é proposta uma forma dos EM recolherem a informação necessária, através de uma folha de cálculo descrita naquele documento e disponibilizada no site do INSPIRE (Fig. 1).

De acordo com as disposições de execução estabelecidas na Decisão 2009/442/CE, de 5 de Junho e a fim de garantir uma abordagem coerente na monitorização e apresentação de relatórios, os EM devem estabelecer uma lista dos Conjuntos de Dados geográficos (CDG) correspondentes aos Temas enumerados nos Anexos I, II e III da Directiva INSPIRE, agrupados por Tema e por Anexo, bem como os serviços de rede, agrupados por tipo de serviço.

A monitorização baseia-se num conjunto de indicadores calculados a partir dos CDG e serviços identificados para cada Tema dos Anexos e dos dados que os caracterizam [2]. Esses indicadores traduzem informação relativa aos metadados, aos conjuntos de dados geográficos, relativamente à sua existência, conformidade com o INSPIRE e acessibilidade através de serviços, bem como, a utilização dos serviços de rede e a sua conformidade com as respectivas disposições de execução INSPIRE. Para cada um destes itens é definido um indicador geral subdividido em vários sub-indicadores. Os indicadores e suas formas de obtenção estão descritos, de forma resumida, na Tabela 1.

Existência de metadados
Mdi1 - quantifica a existência de metadados para os conjuntos e serviços de dados geográficos Mdi1 = Mdi1.1 + Mdi1.2 + Mdi1.3 + Mdi1.4	Mdi1.x = existência de CDG e serviços com metadados / total dos CDG e serviços Mdi1.1- Anexo I Mdi1.2 - Anexo II Mdi1.3 - Anexo III Mdi1.4 - Serviços de dados geográficos
Conformidade dos metadados
Mdi2 - quantifica a conformidade dos metadados para os conjuntos e serviços de dados geográficos. Mdi2 = Mdi2.1 + Mdi2.2 + Mdi2.3 + Mdi2.4	Mdi2.x = CDG e serviços com metadados em conformidade / total dos CDG e serviços Mdi2.1 - Anexo I Mdi2.2 - Anexo II Mdi2.3 - Anexo III Mdi2.4 - Serviços de dados geográficos
Cobertura Geográfica dos CDG
Dsi1 - quantifica o grau de cobertura do território pelos conjuntos de dados geográficos (CDG). Dsi1 = Dsi1.1 + Dsi1.2 + Dsi1.3	Dsi1.x = soma das superfícies reais cobertas por todos os CDG / soma das superfícies relevantes para todos os CDG. Dsi1.1- Anexo I Dsi1.2- Anexo II Dsi1.3- Anexo III
Conformidade dos CDG
Dsi2 - quantifica a conformidade dos CDG (incluindo os metadados) com as disposições de execução da Directiva. Dsi2 = Dsi2.1 + Dsi2.2 + Dsi2.3	Dsi2.x = CDG (incluindo metadados) em conformidade / total de CDG Dsi2.1 - Anexo I Dsi2.2 - Anexo II Dsi2.3 - Anexo III
Acessibilidade dos metadados através dos serviços de pesquisa
Nsi1 - quantifica os CDG e os serviços com metadados acessíveis através dos serviços de pesquisa. Nsi1 = Nsi1.1 + Nsi1.2	Nsi1.x = CDG e serviços com metadados acessíveis / total dos CDG e serviços Nsi1.1- CDG Nsi1.2 - Serviços
Acessibilidade dos CDG através dos serviços de visualização e de descarregamento de dados
Nsi2 - quantifica os CDG com informação geográfica acessível através dos serviços de visualização e/ou através dos serviços de descarregamento. Nsi2 = Nsi2.1 + Nsi2.2 + Nsi2.3	Nsi2.x = CDG acessíveis através de serviços / total dos CDGNsi2.1 - Serviços de visualização Nsi2.2 - Serviços de descarregamento Nsi3.3 - Serviços de visualização e de descarregamento
Utilização dos serviços de rede
Nsi3 - quantifica a utilização de todos os serviços de rede. Nsi3 = Nsi3.1 + Nsi3.2 + Nsi3.3 + Nsi3.4 + Nsi3.5	Nsi3.x = número anual de pedidos para os serviços de rede / total dos serviços Nsi3.1 - serviços de pesquisa Nsi3.2 - Serviços de visualização Nsi3.3 - Serviços de descarregamento Nsi3.4 - Serviços de transformação Nsi3.5 - Serviços de invocação
Conformidade dos serviços de rede
Nsi4 - quantifica a conformidade de todos os serviços de rede com as disposições de execução da Directiva. Nsi4 = Nsi4.1 + Nsi4.2 + Nsi4.3 + Nsi4.4 + Nsi4.5	Nsi4.x = serviços em conformidade/ total serviços Nsi4.1 - Serviços de pesquisa Nsi4.2 - Serviços de visualização Nsi4.3 - Serviços de descarregamento Nsi4.4 - Serviços de transformação Nsi4.5 - Serviços de invocação

Tabela 1: Indicadores para a monitorização dos CDG e Serviços.

Para apoiar na recolha dos dados necessários ao cálculo dos indicadores e à apresentação dos resultados globais relativos à monitorização dos CDG e serviços de cada EM, foi disponibilizada pela CE uma folha de cálculo que, para além de organizar a informação a recolher, facilita a sua consulta e fornece um modo automático de cálculo dos indicadores gerais e específicos (ver Figura 1).

Figura 1. Folha de cálculo disponibilizada pela CE para a monitorização.

3. Monitorização em Portugal: Organização, metodologia e processo

O primeiro prazo para implementação das disposições de execução relativas a monitorização e relatório foi 15 de Maio de 2010. Nesse ano, os EM tiveram que submeter à CE os indicadores da monitorização, reportando a situação relativa ao ano de 2009 e apresentaram o primeiro relatório.

No segundo ano de implementação da Directiva INSPIRE apenas foi exigido aos EM a monitorização dessa implementação já que a entrega do relatório é trienal.

Em Portugal, a monitorização de 2011 decorreu de forma mais eficiente uma vez que beneficiou da experiência acumulada em termos organizacionais metodológicos e processuais adquirida no ano anterior.

O Instituto Geográfico Português (IGP) é o Ponto de Contacto Nacional (PCN) para a Directiva INSPIRE pelo que é responsável por recolher os dados destinados à monitorização e apresentação de relatórios. Enquanto PCN, o IGP deverá compilar e enviar anualmente à CE a lista dos conjuntos de dados geográficos (CDG) e de três em três anos elaborar um relatório contendo informações actualizadas seguindo as orientações estabelecidas nas disposições de execução da Directiva INSPIRE. As autoridades públicas, por seu turno, devem fornecer numa base regular a informação necessária para que o IGP possa descrever a situação do País.

O IGP é também o coordenador da Infra-estrutura de Dados Espaciais (IDE) nacional, o Sistema Nacional de Informação Geográfica (SNIG), o qual tem por objectivo proporcionar, a partir dos vários pontos de acesso, a possibilidade de pesquisar, visualizar e explorar a informação geográfica sobre o território nacional. O SNIG foi criado em 1990, através do Decreto-Lei n.º 53/90 de 13 de Fevereiro, tendo sido a primeira IDE desenvolvida na Europa e a primeira a ser disponibilizada na Internet, em 1995 [4] [5]. Apesar de ter sido criada há 20 anos, esta infra-estrutura acompanhou os desenvolvimentos ocorridos no domínio das IDE, tendo mais recentemente, sofrido um processo de revisão organizacional, tecnológica e de conteúdos que reflectem as imposições da Directiva INSPIRE, transposta para a lei nacional em 2009, pelo Decreto-Lei n.º 180/2009, de 7 de Agosto [6] [7].

Nesse diploma foi criado o Conselho Orientador do SNIG (CO-SNIG) um órgão de âmbito nacional, presidido pelo IGP, que assegura a coordenação estratégica do SNIG, bem como a aplicação da Directiva INSPIRE em Portugal [6].

Enquanto PCN, o IGP usufruiu da existência da Rede do SNIG para a disseminação de informação sobre a Directiva INSPIRE. Partindo das instituições presentes no SNIG, o IGP criou em 2005 uma Rede de Gestores de Metadados e em 2007 a Rede de Pontos de Focais INSPIRE (RPF INSPIRE) reunindo os pontos de contacto das instituições públicas produtoras de conjuntos de dados geográficos e serviços nacionais [8].

Para apoiar em termos técnicos e organizacionais o IGP no seu papel de coordenador do SNIG e de PCN INSPIRE foi criada na Direcção de Serviços de Informação e Gestão da Informação Geográfica (DSIGIG) o Grupo de Trabalho INSPIRE (GT INSPIRE) que funcionou na fase de arranque da Directiva (2008-2010) tendo recentemente convergido para a Equipa SNIG-INSPIRE.

Já no âmbito do processo de monitorização e reporte da implementação da Directiva em Portugal, o IGP conta com o apoio do Grupo de Trabalho para a Monitorização e Relatórios do Conselho de Orientação do Sistema Nacional de Informação Geográfica (GT M&R CO-SNIG), um grupo criado pelo CO-SNIG para apoiar o PCN INSPIRE.

O processo de monitorização, em 2011, foi reformulado e agilizado (ver Figura 2). Começou por uma actualização das fichas de instituição, temas e assuntos, criadas no âmbito do estudo "Análise dos temas dos Anexos da Directiva INSPIRE e das Autoridades Públicas responsáveis pelos Conjuntos de Dados Geográficos de cada Tema", realizado aquando da Monitorização de 2010 para caracterizar os temas dos Anexos da Directiva INSPIRE e as Autoridades Públicas formalmente responsáveis pelos Conjuntos de Dados Geográficos de cada Tema. Este estudo foi desenvolvido com base numa metodologia centrada na análise dos temas dos Anexos da Directiva e na análise da legislação relativa às Autoridades Públicas [9].

Figura 2. Processo de monitorização aplicado em Portugal em 2011.

Para a introdução da informação necessária à criação da lista dos CDG e serviços e ao cálculo dos indicadores, o IGP desenvolveu um conjunto de formulários disponíveis na Internet, que foram utilizados pelas instituições públicas com responsabilidades sobre os CDG e serviços de cada Tema (Figura 3).

Neste formulário cada instituição identifica os CDG e serviços da sua responsabilidade associados aos temas dos Anexos da Directiva e caracteriza-os em termos de existência e conformidade dos metadados, cobertura e conformidade dos CDG e existência de serviços, sua acessibilidade através de metadados e sua utilização. Anualmente este formulário sofre alterações que visam implementar melhorias e ganhos de tempo no processo de monitorização. Actualmente, esta aplicação permite a geração automática de relatórios, utilizando o Business Intelligence and Reporting Tools (BIRT) assim como a validação automática dos metadados publicados na IDE (SNIG).

Figura 3. Conjuntos e Serviços de Dados Geográficos no formulário on-line.

O GT M&R CO-SNIG analisou a informação recebida e aprovou diversas recomendações no sentido de serem cumpridas as obrigações do País em termos de monitorização da aplicação da Directiva.

Uma vez finalizada a lista de CDG e serviços nacionais, o IGP procedeu ao cálculo dos indicadores de monitorização e submeteu-os para análise e aprovação do CO-SNIG. A folha de cálculo final aprovada pelo CO-SNIG a 5 de Maio foi submetida à CE dentro do prazo previsto na Directiva ou seja, até 15 Maio.

4. Monitorização dos CDG e Serviços em Portugal: Resultados obtidos

Os resultados globais obtidos na monitorização de CDG em 2010 e 2011 são os constantes da Tabela 2.

Tabela 2. Indicadores obtidos para os CDG de Portugal, valores totais e por Anexos da Directiva INSPIRE

Os resultados indicam que, entre 2010 e 2011, o número de CDG quase duplicou. Relativamente à abrangência territorial dos CDG, verifica-se que o grau de cobertura é quase total (98%). No que respeita aos indicadores relativos aos metadados dos CDG, houve também um aumento. Em 2011, 93% dos CDG têm metadados e 91% possuem metadados em conformidade com a Directiva INSPIRE. O significativo aumento deste indicador (de 53% para 91%) resulta da necessidade do cumprimento até 3 de Dezembro de 2010, da exigência da Directiva relativamente à conformidade com as disposições de execução dos metadados para os CDG dos Anexos I e II, obrigação que Portugal cumpriu atempadamente.

Quanto à distribuição dos CDG pelos Anexos da Directiva INSPIRE (ver Figura 4) verifica-se que nos dois anos há mais CDG reportados para os Anexos I e III do que para o Anexo II, o que se justifica pelo facto dos Anexos I e III abrangerem maior número de temas (9 e 21) do que o Anexo II (4 temas). Verifica-se também que em 2010 a distribuição dos CDG pelos Anexos I e III era mais próxima, respectivamente 182 (42%) e 190 (44%), do que em 2011, agora com 258 (35%) para o Anexo I e 353 (49%) para o Anexo III. O número de CDG reportados para o Anexo II aumentou ligeiramente, de 63 para 117 (14% para 16%).

Figura 4. Portugal: Distribuição dos CDG por Anexo.

Em relação à distribuição dos CDG por temas dos Anexos (ver Figura 5), a distribuição apresenta-se muito desigual nos dois anos. Refira-se ainda que em 2010, não houve identificação de CDG para dois temas do Anexo III, situação que se alterou em 2011, uma vez que Portugal já apresenta CDG para todos os temas.

Figura 5. CDG agrupados pelos temas INSPIRE: monitorização 2010 e 2011.

No que respeita aos serviços de rede (ver Tabela 3), registou-se um significativo aumento de 2010 para 2011 já que o seu valor triplicou, de 43 para 128 serviços. A existência de metadados nos serviços também aumentou consideravelmente (de 65% para 98%).

Foram identificados em Portugal serviços de pesquisa, visualização e descarregamento (ver Tabela 4). No que se refere aos CDG para os quais existem serviços de pesquisa, em 2011, 76% dos CDG eram pesquisáveis através de dois serviços de pesquisa, um nacional (SNIG) e outro temático relativo ao tema água (InterSIG). Quanto aos serviços de visualização e descarregamento e segundo os dados da monitorização, entre 2010 e 2011, o número de serviços de visualização triplicou e o número de serviços de descarregamento quase duplicou (ver Figura 6). Os valores registados derivam das indicações da CE para a monitorização, pelo que foram considerados como serviços de visualização e como serviços de descarregamento de dados geográficos, os Geo WebServices e as aplicações de webmapping que permitem a visualização e por vezes o descarregamento dos CDG.


Tabela 3. Indicadores obtidos para os Serviços.	Tabela 4. Distribuição por tipo de serviço.

Figura 6. Portugal: Distribuição dos Serviços por tipo.

Comparando os resultados nacionais, em 2010, com a panorâmica global dos países da CE, para a qual contribuíram 20 dos 27 países, verifica-se que Portugal foi o segundo País a reportar o maior número de CDG (Figura 7).

Figura 7. Resultados obtidos na Monitorização dos EM pela CE em 2010 [10].

Dos resultados apresentados verifica-se que Portugal terá que investir no aumento da disponibilização de serviços, preferencialmente de Geo WebServices.

Neste contexto, é importante referir que todos os CGD reportados no processo de monitorização terão que estar de acordo com as respectivas especificações de dados publicadas pela CE. A harmonização de dados geográficos é preconizada na Directiva INSPIRE como um processo faseado, mas representa mesmo assim um pesado fardo, cujas necessidades deverão ser consideradas atempadamente pelas instituições públicas no sentido de evitarem potenciais incumprimentos.

5. Conclusões

Este artigo descreve o processo de monitorização adoptado em Portugal, apresentando os indicadores de monitorização obtidos e a situação do País reportada junto da CE no que concerne à aplicação da Directiva INPIRE no País.

Este processo resultou da conjugação de esforços do IGP (PCN INSPIRE) que coordena e realiza, por via da Equipa SNIG-INSPIRE, todo o trabalho operativo de aplicação da Directiva em Portugal, com a actividade do GT M&R CO-SNIG, grupo de trabalho que apoia o IGP na obtenção de informação necessária para a monitorização e relatórios e também com a RPF INSPIRE Core, que reúne as autoridades públicas formalmente responsáveis pela produção dos CDG e serviços nacionais.

Em 2010, Portugal foi o segundo País com maior número de CDG identificados, sendo que em 2011 esse número quase duplicou. Tal facto poderá indicar que se registou um bom envolvimento das instituições nacionais com responsabilidades na produção de CDG, como resultado da interacção entre o PCN, o GT M&R CO-SNIG e a RPF INSPIRE. A harmonização dos dados geográficos reportados, de acordo com as especificações de dados entretanto publicadas, será um dos desafios mais relevantes para as instituições envolvidas.

Considera-se que a actividade de monitorização poderá vir a ser bastante facilitada através da utilização da informação contida nos metadados. A adopção de procedimentos automatizados baseados nessa informação, facilitará certamente o processo de monitorização anual da Directiva.

Agradecimentos
Os autores agradecem o envolvimento dos elementos do GT M&R CO-SNIG e de todas as instituições da RPF INSPIRE Core que contribuíram com o seu esforço na identificação e caracterização dos CDG e serviços da sua responsabilidade.

Referências
[1] Jornal Oficial da União Europeia, Directiva 2007/2/CE do Parlamento Europeu e do Conselho, de 14 de Março de 2007, que estabelece uma infra-estrutura de informação geográfica na Comunidade Europeia (Inspire),
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:108:0001:0014:PT:PDF.
[2] Jornal Oficial da União Europeia, Decisão da Comissão de 5 de Junho de 2009 que estabelece as disposições de execução da Directiva 2007/2/CE do Parlamento Europeu e do Conselho em matéria de monitorização e apresentação de relatórios [notificada com o número C(2009) 4199] (Texto relevante para efeitos do EEE) (2009/442/CE) (EN).
[3] Eurostat: INSPIRE Monitoring Indicators - Guidelines Document. Version 5.0. Monitoring and Reporting Drafting Team and European Commission (2009).
[4] Henriques, R.G., Fonseca, A., Gouveia, C.: Sistema Nacional de Informação Geográfica, In: Forum SNIG, vol. 5, pp. 35 - 39, Lisboa (1999).
[5] Masser, I.: All shapes and sizes: the first generation of national spatial data infrastructures, International Journal of Geographical Information Science, Vol. 13, Issue 1, pp 67 - 84 (1999).
[6] Decreto-Lei nº180/2009 de 7 de Agosto. Diploma que procede à revisão do Sistema Nacional de Informação Geográfica (SNIG) e transpõe para a ordem jurídica interna a Directiva INSPIRE - que estabelece uma Infra-Estrutura de Informação Geográfica na Comunidade Europeia.
[7] Julião, R. P., Bonnet, A., Silva, H., Furtado, D., Rizzonne, A. S., Marrecas, P., Silva, A. J.: Sistema Nacional de Informação Geográfica (SNIG) - Infra-estrutura de Dados Espaciais Portuguesa, 5º Congresso Luso-Moçambicano de Engenharia, Maputo, Moçambique, 2-4 de Setembro de 2008.
[8] Relatório INSPIRE Estado Membro: Portugal, 2010, http://snig.igeo.pt/Inspire/documentos/relatorioINSPIRE/RelatorioINSPIREPortugal_2010.pdf.
[9] Rizzone, A.S.; Fonseca, A., 2010, Temas dos temas dos Anexos da Directiva INSPIRE - Que Autoridades Públicas são responsáveis? I Jornadas Ibéricas de Infra-estruturas de Dados Espaciais - JIIDE, Lisboa (2010). http://snig.igeo.pt/Inspire/documentos/JIIDE2010/artigoASR.pdf
[10] Rizzi, D.: Towards the implementation of INSPIRE, INSPIRE CONFERENCE, Poland, June 2010.

Monitorizando la red: El seguimiento de INSPIRE en Europa, España y Andalucía

Sánchez, F., Villar, A., Pardo, E. — Wed, 08 Feb 2012 00:00:00 +0100

MONITORIZANDO LA RED: EL SEGUIMIENTO DE INSPIRE EN EUROPA, ESPAÑA Y ANDALUCÍA

F. Sánchez, A. Villar, E. Pardo
Instituto de Estadística y Cartografía de Andalucía

1. Monitorizando la red Inspire

El proceso de construcción de la infraestructura de información espacial en la Comunidad Europea, como todo proceso que pretenda ser planificado y no espontáneo, requiere disponer de unos mecanismos de seguimiento, evaluación e informe mediante los cuales sea posible medir su velocidad y dirección. De esta forma se pueden tomar decisiones antes de que finalice el proceso, asegurando así que los objetivos fijados se alcancen en los plazos previstos.

Este habitual instrumento para el seguimiento de planes ha sido aplicado desde un principio dentro del proceso para el establecimiento de la infraestructura de información espacial de la Comunidad Europea. La propia Directiva 2007/2/CE Inspire dedica su artículo 21 a fijar que los estados miembros hagan "un seguimiento de la aplicación y utilización de sus infraestructuras de información espacial", a cuyos resultados tendrán acceso permanente la Comisión y la ciudadanía.

En desarrollo de este artículo se aprobó la Decisión 2009/442/CE de la Comisión, de 5 de junio de 2009, en lo que se refiere al seguimiento y los informes [1]. Esta Decisión viene a concretar el mecanismo de seguimiento para evaluar el proceso de establecimiento de Inspire. En síntesis, se prevé que "los Estados miembros confeccionarán una lista de los conjuntos y los servicios de datos espaciales" actualizada anualmente; junto a una serie de indicadores sintéticos sobre los metadatos (disponibilidad, conformidad y accesibilidad), los conjuntos de datos (extensión territorial, conformidad y accesibilidad) y los servicios de red (nivel de utilización y conformidad).

Ya están disponibles los informes correspondientes a 2009 y 2010 [2], en los cuales se contiene una primera visión sobre del estado inicial de la infraestructura europea, aunque todavía con criterios heterogéneos entre países respecto a la interpretación de los conceptos de "conjuntos y servicios de datos espaciales". En todo caso, se cuenta con un listado pormenorizado en el que se reportan 11.936 conjuntos de datos y 3.765 servicios de red para la totalidad de Europa. Con las salvedades de Reino Unido, Italia, Malta, Estonia y Lituania, todos los países han proporcionado el listado requerido por la Comisión Europea.

Figura 1. Nivel de respuesta nacional a los informes anuales de Inspire.

Estos listados nacionales ofrecen un panorama muy desigual, al menos en términos cuantitativos. En cuanto al volumen de información disponible, destaca la gran cantidad de datos y servicios proporcionados en España, Alemania, Portugal, Irlanda, Países Bajos y Francia.

País	Data Sets	Servicios
Austria	304	8
Belgium	239	31
Bulgaria	436	49
Czech Republic	335	65
Estonia	0	0
Finland	122	21
France	431	212
Germany	1366	553
Greece	306	40
Hungary	107	32
Ireland	602	17
Italy	0	0
Latvia	113	21
Lithuania	0	0
Luxembourg	184	101
Malta	0	0
Netherlands	540	271
Norway	222	98
Poland	45	12
Portugal	728	128
Romania	220	44
Slovakia	99	21
Slovenia	77	11
Spain	5290	1999
Sweden	170	31
United Kingdom	0	0

El análisis de los distintos tipos de servicios ofrece una visión más precisa, ya que estas cantidades totales adolecen de una cierta falta de comparabilidad, por la imprecisión del propio concepto de "conjunto de datos". La mayor parte de los servicios disponibles en este momento inicial corresponde a los destinados a la visualización de datos, del tipo Web Map Service, que suponen el 81 % del total. De los 3.052 servicios de visualización reportados, 1.545 corresponden a España. En este tipo, España se sitúa en torno a la media europea, mientras que en estados como Suecia, Países Bajos o Austria los servicios de visualización suponen más del 97 % del total de los servicios de red. Por el contrario, los servicios que permiten la descarga de datos, del tipo Web Feature Service o Web Coverage Service, sólo suponen un 13 %; también con un papel destacado de España, que aporta 326 de los 508 existentes en Europa.

Los servicios de localización para la búsqueda en catálogos de metadatos, del tipo Web Catalog Service, son bastante numerosos en todos los países, con una sobreabundancia en Europa oriental. Como ejemplo, en Polonia se han inventariado 5 servicios de catálogo, para tan sólo 45 conjuntos de datos. En el otro extremo se encuentran los Países Bajos, que cuenta con un único catálogo centralizado y completo, denominado Nationaal Georegister.

Figura 2. Tipos de servicios interoperables en Europa

Estos indicadores sobre el grado de penetración de Inspire parecen mostrar que la infraestructura de información espacial europea ya dibuja una red que cubre casi la totalidad de Europa, si bien con conjuntos de datos aún no homogéneos, con excesiva proliferación de catálogos, con un predominio actual de los servicios de visualización y todavía escasos servicios de descarga.

2. La situación en España

En el caso de España, la situación es muy similar a la media europea; lo que viene influido en todo caso por la alta presencia española en este inventario, al que aporta el 44 % de los datos y el 53 % de los servicios. En el conjunto nacional, los 1.999 servicios reportados ofrecen un absoluto predominio de la visualización, que alcanza el 80% con 1.595 servicios WMS, mientras que las descargas sólo son posibles en el 16 % de los casos. También se constata la disponibilidad de 44 servicios de catálogo, lo que indica una cierta dispersión de los recursos para la búsqueda y localización. [3]

De estos 5.290 conjuntos de datos y 1.999 servicios, corresponden a las administraciones autonómicas un total de 4.718 y 1.742 respectivamente. Esta descentralización es uno de los rasgos más singulares de la infraestructura española y viene a permitirle un funcionamiento como una verdadera red. El resto de servicios corresponden a la Administración General del Estado, ya que la administración local se encuentra aún muy escasamente representada.

Comunidad	Data Sets	Servicios
Andalucía	1738	368
Aragón	38	9
Asturias	1	0
Baleares	174	70
Canarias	24	44
Cantabria	39	2
Castilla-La Mancha	23	7
Castilla-León	44	27
Cataluña	105	394
Extremadura	75	16
Galicia	133	32
Madrid	0	2
Murcia	7	2
Navarra	272	0
País Vasco	156	23
Rioja	1667	706
Valencia	222	40

Del conjunto de IDEs autonómicas, las que han catalogado un mayor volumen de información son las de Andalucía, Rioja, Navarra, Valencia, Baleares, Euskadi, Galicia y Cataluña. Hay que aclarar en todo caso que el parámetro que se mide es el número de conjuntos de datos, no el volumen de datos al que se refieran. A este nivel, se han usado criterios distintos entre comunidades autónomas, ya que en algunos casos se catalogan series cartográficas, en otros hojas y en otros capas de información.

Figura 3. Número de conjuntos de datos autonómicos en España

En cuanto a los tipos de datos, se encuentran representados de forma bastante equilibrada los datos de referencia y los de carácter temático, ya que los tres anejos de Inspire se reparten respectivamente el 35, 26 y 39 % de los datos reportados. Tan sólo en Andalucía, Murcia, Valencia, Cataluña y Euskadi, los datos temáticos del anejo 3 resultan mayoritarios.

Figura 4. Tipos de conjuntos de datos autonómicos en España

Si se analizan en detalle los indicadores sobre servicios aportados por las IDEs autonómicas se aprecian los rasgos habituales en el resto de Europa en cuanto a la sobreabundancia de catálogos, el predominio de la visualización y la escasa oferta de servicios de descarga. Como rasgos singulares se pueden señalar la ausencia de catálogos interoperables en 6 comunidades, el alto número de servicios de visualización en Rioja, Andalucía y Cataluña y una curiosa pauta geográfica de concentración de los servicios de descarga en la mitad norte.

Figura 5. Tipos de servicios interoperables autonómicos en España

En síntesis, la Infraestructura de Información Geográfica de España se encuentra ya muy madura, siendo la red nacional que ha reportado el mayor volumen de datos y servicios en toda Europa. Es además una red bastante descentralizada, aunque un tanto heterogénea, destacando el crecimiento alcanzado en la propia Administración General de Estado y muy en especial en las comunidades autónomas de Cataluña, Andalucía, La Rioja y Baleares.

3. El caso de Andalucía

La Infraestructura de Datos Espaciales de Andalucía [4] constituye uno de las subredes de mayor tamaño dentro de la infraestructura española, con el 33 % de los datos y el 18 % de los servicios disponibles en el conjunto de España. Se trata además de una verdadera red, con variedad de nodos, en la que participan publicando servicios interoperables los siguientes organismos:
o Instituto de Estadística y Cartografía de Andalucía
o Consejería de Medio Ambiente
o Consejería de Obras Públicas y Vivienda
o Dirección General de Industria, Energía y Minas
o Agencia Andaluza de la Energía
o Diputación de Málaga
o Diputación de Jaén
o Diputación de Córdoba
o Diputación de Sevilla
o Diputación de Granada
o Mancomunidad de la Campiña Sur de Córdoba
o Confederación Hidrográfica del Guadalquivir
o Estación Biológica de Doñana

A fines de 2010, la IDEAndalucía disponía de 368 servicios en su inventario de servicios interoperables. De ellos, 359 correspondían a servicios de visualización, 4 eran de descarga y 1 de descubrimiento. En este volumen de servicios destaca la gran aportación de la Consejería de Medio Ambiente, con 300 servicios WMS. A lo largo de 2011 se han abierto 5 nuevos servicios de descarga con WFS. En cuanto a los servicios de localización en catálogos de datos, se dispone de un catálogo centralizado con 23.085 metadatos, que incluye la mayor parte de los conjuntos de datos de responsabilidad autonómica y los de algunas diputaciones.

Figura 6. Tipos de servicios interoperables en IDEAndalucía

Esos más de 23.000 metadatos se corresponden con 1.738 conjuntos de datos, debido a que las series de cartografía básica y ortoimágenes se han inventariado a nivel de hojas, mientras que los datos temáticos se catalogan a nivel de capa. Los conjuntos de datos catalogados se distribuyen entre un 16,6 % para el anejo I de Inspire, un 27,7 % del anejo II y un 55,6 % para los datos temáticos del anejo III. Esta distribución en la que predominan los datos temáticos se explica también por la elevada presencia de datos ambientales y porque el Catálogo de Datos Espaciales de Andalucía ha realizado una campaña de catalogación exhaustiva en todas las consejerías de la Junta de Andalucía.

Figura 7. Tipos de conjuntos de datos en IDEAndalucía

Una herramienta esencial para medir el nivel de utilización de IDEandalucía, y de cualquier infraestructura de datos espaciales, la proporcionan las estadísticas de accesos al geoportal. En este sentido, la monitorización de las visitas al geoportal proporciona una batería de indicadores de gran valor para realizar un seguimiento detallado sobre el uso de los servicios.

El volumen de usuarios de IDEandalucía a lo largo del último año -entre agosto de 2010 y agosto de 2011- se refleja en unos totales de 413.967 visitas y 51.193.919 peticiones a los servidores. Este indicador relativo al número total de accesos aporta además una visión dinámica al permitir medir la evolución temporal del número de usuarios. En el caso de IDEAndalucía, se dispone ya de una serie completa de datos sobre accesos correspondientes a los tres últimos años, que indica una tendencia creciente con puntas de hasta 47.000 accesos mensuales, aunque con bajadas estacionales durante las vacaciones de verano y Navidad.

Figura 8. Visitas mensuales al geoportal de IDEAndalucía

Esta pauta estacional, junto con el reparto semanal y la distribución horaria, parecen indicar que perfil de usuarios es mayoritariamente profesional. A pesar de este predominio de los usuarios con perfil profesional, los clientes que se utilizan para consumir los servicios siguen siendo mayoritariamente los navegadores web mediante visualizadores embebidos y con un uso todavía escaso de clientes pesados.

Figura 9. Tipos de clientes en los servicios del geoportal de IDEAndalucía

En cuanto a los tipos de servicios más consumidos, los de visualización suponen la inmensa mayoría de las demandas. Los servicios de descarga en cambio muestran un pico inicial cuando se publican y un decaimiento en los meses sucesivos, lo que puede ponerse en relación con el aún escaso uso de clientes pesados. Por su parte, el servicio CSW del Catálogo de Datos Espaciales de Andalucía supone tan sólo el 3 % de los accesos a los servidores del geoportal.

Figura 10. Evolución mensual de los accesos a servicios CSW y WFS

4. Los indicadores de utilización y calidad

Además de los indicadores recogidos en la Decisión 2009/442/CE de la Comisión, de 5 de junio de 2009, en lo que se refiere al seguimiento y los informes, la normativa de desarrollo de Inspire ha establecido otros parámetros de calidad de los servicios, recogidos en la Reglamento (CE) nº 976/2009 de la Comisión de 19 de octubre de 2009 por el que se ejecuta la Directiva 2007/2/CE del Parlamento Europeo y del Consejo en lo que se refiere a los servicios de red [5]. Este Reglamento establece como variables para medir la idoneidad de los servicios unos tiempos máximos de respuesta, una capacidad mínima de peticiones simultáneas y un tiempo mínimo de disponibilidad.

En desarrollo de estas normas europeas, el Grupo de Trabajo que coordina a los administradores de los nodos que componen la IDEAndalucía, ha acordado adoptar como indicadores básicos los siguientes:

Visitas o accesos:
Número de veces que cualquier cliente se conecta al servidor y permanece conectado durante una misma sesión. No se consideran los visitantes (IP únicas que pueden acceder varias veces), sino el número de ocasiones en que se establece la conexión, independientemente del tiempo de duración.

Solicitudes:
También se denominan peticiones y básicamente es el número total de archivos pedidos, entendiendo un archivo por una petición Http que para páginas Html serían archivos y para servicios WMS seria cada una de las peticiones GetCapabilities, GetMap o GetFeatureInfo.

Tráfico:
El número total de Kilobytes descargados por los visitantes incluyendo páginas Html, imágenes, archivos Javascript, hojas de estilo, etc. Para los servicios se puede utilizar un valor medio de tamaño de archivo descargado, que si lo multiplicamos por las visitas/accesos permite obtener un valor aproximado del tráfico.

Tiempo de respuesta:
Tiempo que tarda el servidor en responder a una solicitud/petición estandarizada en el Reglamento (CE) 976/2009 para cada petición GetCapabilities, GetMap y para cada tipo de servicio. Por ejemplo, para una petición GetMapRequest a un servicio de visualización, para una imagen de 470 kilobytes será de 5 segundos como máximo.

Disponibilidad del servicio:
Tiempo durante el que el servicio está activo. El Reglamento (CE) 976/2009 establece que debe ser superior al 99%.

Estos parámetros de monitorización constituyen la batería de indicadores que se utilizarán en los nodos de la red de IDEandalucía para medir la oferta, rendimiento, capacidad y disponibilidad de los servicios que constituyen el núcleo de cualquier infraestructura de datos espaciales.

Referencias
[1] http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:148:0018:0026:ES:PDF
[2] http://inspire.jrc.ec.europa.eu/index.cfm/pageid/182/list/indicators
[3] http://www.idee.es/show.do?to=pideep_INSPIRE_Seguimiento.ES
[4] http://www.ideandalucia.es/index.php/es/nodos/nodo-central-ideandalucia
[5] http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:01:ES:HTML