Sistemas Informaci´ on

de

Geogr´ afica

V´ıctor Olaya Versi´on 1.0 — Rev. 25 de noviembre de 2011

718

´ n Geogra ´ fica Sistemas de Informacio

consigue localizarlo y desea adquirirlo, es igualmente probable que encuentre dificultades para comunic´ arselo al proveedor, ya que seguir´ a existiendo la misma barrera ling¨ u´ıstica. Y si finalmente recibe el producto, puede tener dificultades al utilizarlo, ya que este puede funcionar a un voltaje distinto al de la red el´ectrica espa˜ nola o bien estar preparado para un tipo de enchufe distinto. Este peque˜ no ejemplo nos hace ver que en la relaci´on cliente–servidor pueden surgir problemas derivados de la falta de elementos comunes entre ambos actores. Si todos los elementos que toman parte en el establecimiento de esa relaci´on comercial estuvieran normalizados y fueran u ´nicos, un comprador de cualquier parte del mundo podr´ıa de forma inmediata comprar un dispositivo a cualquier vendedor de otro pa´ıs comunic´andose en un u ´nico idioma, y tener despu´es la garant´ıa de poder usarlo sin problemas. En el ´ ambito de la informaci´ on geogr´ afica la situaci´on es similar a la anterior. Hay muchos formatos distintos para almacenarla y muchas formas distintas de transmitirla, y ello dificulta el trabajo en el marco de una IDE. Igual que los clientes espa˜ noles no hablan el mismo idioma que los vendedores chinos, no todos los clientes SIG hablan el mismo idioma que todos los servidores, y dos cualesquiera de ellos no han de ((entenderse)) necesariamente. De hecho, hist´ oricamente los distintos fabricantes de clientes defin´ıan por s´ı mismos la forma en que sus programas se comunicaban, que no coincid´ıa con la del resto de fabricantes. Un cliente de un fabricante dado no podr´ıa acceder a los servicios de un servidor creado por un fabricante distinto. Este paradigma, caracter´ıstico del software privativo, es un problema en el marco de una IDE, pues dificulta el acceso a los datos. En circunstancias ideales, en el marco de la IDE debe existir una total interoperabilidad con independencia de los formatos y las aplicaciones empleadas, pudiendo interactuar entre s´ı los distintos clientes y servidores. Los est´ andares son el elemento que va a permitir esa interoperabilidad, definiendo el marco com´ un que clientes y servidores emplear´an para entenderse. En un contexto altamente heterog´eneo tanto en datos como en herramientas, lograr esto no resulta una tarea sencilla[349], y los est´andares son los encargados de aportar homogeneidad tecnol´ ogica y favorecer todo el trabajo a desarrollar dentro de una IDE.

32.2.

Est´ andares abiertos e interoperabilidad

La interoperabilidad implica que podemos sustituir unos elementos del sistema en el que se incluyen los clientes y servidores por otros distintos, teniendo la seguridad de que van a interaccionar entre ellos sin dificultades. Las funcionalidades que un cliente o servidor nos ofrece pueden ser distintas a las de otro, pero independientemente de su origen (independientemente del fabricante), si esos elementos implementan un est´andar dado, siempre podr´an interactuar con todos aquellos que tambi´en lo implementen. La clave, por tanto, est´ a en los est´ andares, y en particular en que estos sean est´andares abiertos. Un est´ andar es un documento o pr´ actica que busca armonizar los aspectos t´ecnicos de un producto o servicio. Un est´ andar se considera como tal cuando es empleado por un grupo o comunidad, que lo acepta para la definici´ on de las caracter´ısticas de ese producto o servicio en su seno. Si u ´nicamente es el uso del est´ andar el que lo ratifica como tal, se denomina est´andar de facto. El formato shapefile para capas vectoriales, por ejemplo, es uno de estos est´andares, ya que est´ a ampliamente difundido y existe tal cantidad de datos en este formato que todas las aplicaciones deben implementarlo para tener valor pr´actico.

´ ndares Esta

719

Existen est´ andares que se convierten en normas o est´andares de iure, cuando estos son promovidos por alg´ un organismo oficial de normalizaci´on o su uso se impone con car´acter legal. Un est´ andar abierto es aquel cuya definici´ on se encuentra disponible y todo aquel que lo desee puede conocerla y emplearla para el desarrollo de la actividad relacionada con ese est´ andar. En nuestro campo de trabajo, eso quiere decir que cualquier desarrollador que desee crear un nuevo cliente o servidor para datos SIG puede acceder al est´andar y desarrollar en base a este. Los principios fundamentales de los est´ andares abiertos son los siguientes [57]: Disponibilidad. Los est´ andares abiertos est´an disponibles para todos el mundo para su lectura y uso en cualquier implementaci´on. M´ axima posibilidad de elecci´ on para los usuarios finales. Los est´andares abiertos crean un mercado competitivo y justo, y no bloquean a los usuarios en el entorno de un vendedor particular. Desde el punto de quienes venden la tecnolog´ıa SIG, esto no es tan ventajoso, ya que permite la aparici´on de competidores que antes no pod´ıan existir. Si un fabricante basa sus productos en un est´andar cerrado definido por ´el mismo, otros no pueden elaborar soluciones que trabajen con esos productos, ya que no conocen el est´ andar empleado. Asimismo, el fabricante puede cambiar el est´andar utilizado por, por ejemplo, su producto de servidor, y obligar a los consumidores y a todo aquel que quiera utilizar un servicio basado en ese servidor a que actualicen tambi´en los clientes, pues los anteriores ya no podr´ an comunicarse con el nuevo servidor. Utilizando est´andares abiertos, la competencia entre fabricantes ha de basarse puramente en las capacidades que ofrecen, con lo que los consumidores ganan en calidad de los productos y en posibilidades de elecci´ on. Gratuidad. Implementar un est´ andar es gratuito, sin necesidad de pagar, como en el caso de una patente. Los organismos que generan los est´andares pueden cobrar una cierta cantidad por acceder a la definici´ on de los est´andares, con objeto de financiar as´ı la labor que desarrollan, y tambi´en pueden cobrar por emitir certificados de que un determinado producto o servicio se ha desarrollado de acuerdo con el est´andar. Discriminaci´ on. Los est´ andares abiertos y las organizaciones que los desarrollan no favorecen de ning´ un modo a uno u otro implementador sobre los restantes. Extensi´ on o creaci´ on de subconjuntos de un est´ andar. Los est´andares abiertos pueden ser extendidos o bien presentados como subconjuntos del est´andar original. Pr´ acticas predatorias. Los est´ andares abiertos pueden tener licencias que requieran a todo aquel que desarrolle una extensi´ on de dicho est´andar la publicaci´on de informaci´ on acerca de esa extensi´ on, y el establecimiento de una licencia dada para todos aquellos que creen, distribuyan y vendan software compatible con ella. Un est´andar abierto no puede prohibir de otro modo el desarrollo de extensiones. Para tener una noci´ on de lo que en la pr´ actica realmente significa el uso de est´andares abiertos en el campo de los SIG y las IDE, podemos ver la figura 32.1, donde se representa el esquema de una arquitectura no interoperable. Es decir, una arquitectura que no se basa en este tipo de est´ andares.

720

´ n Geogra ´ fica Sistemas de Informacio

Figura 32.1: Esquema de una arquitectura no interoperable. Los datos que se encuentran en cada base de datos son accesibles u ´nicamente a trav´es de un u ´nico cliente, que es aquel correspondiente al servidor que ofrece servicios basados en esos datos. Los restantes datos quedan fuera del alcance de ese cliente, ya que no es capaz de acceder a ellos. Las diferentes soluciones cliente–servidor crean en esta situaci´on un conjunto de islas tecnol´ ogicas, cada una completamente independiente y sin posibilidad alguna de interactuar con las restantes. Entre los principales inconvenientes de una arquitectura no interoperable como la representada podemos citar los siguientes: Desperdicio de recursos. Cada servicio debe gestionar sus propio conjunto de datos, lo cual requiere abundantes recursos y no es sencillo, adem´as de implicar un elevado coste. Necesidad de conocer m´ ultiples clientes. Si para acceder a cada servicio necesitamos su cliente particular, acceder al conjunto de servicios ofrecidos por esos servidores requiere por parte de los usuarios aprender a utilizar tantos clientes como servidores existan. Imposibilidad de combinar datos. Dos datos a los que pueda accederse a trav´es de dos servidores distintos no podr´ an utilizarse simult´aneamente en un u ´nico cliente, ya que este no podr´ a comunicarse con ambos servidores. Un an´alisis que requiera distintos tipos de datos no podr´ a realizarse si todos ellos no se ofrecen a trav´es de un mismo servidor. Imposibilidad de combinar funcionalidades. Los datos ofrecidos por un servidor pueden usarse para el desarrollo de muchas tareas. Estas tareas requieren que las correspondientes herramientas est´en disponibles en los clientes, y estos se diferencian notablemente, de la misma forma que lo hacen tambi´en los SIG de escritorio entre s´ı. Si acceder a los datos a trav´es de un servidor solo se puede hacer empleando un cliente concreto, no existe la posibilidad de aprovechar las funcionalidades de otro cliente sobre esos mismos datos, y el usuario ve as´ı limitadas sus posibilidades de trabajo. En contraste con lo anterior, tenemos una situaci´on de plena interoperabilidad basada en est´ andares abiertos como la representada en el esquema de la figura 32.2. En este caso, existe un servidor que es el que gestiona y ofrece los servicios para cada base de datos, pero a ´el pueden acceder todos los clientes, ya que por el hecho de estar

´ ndares Esta

721

Figura 32.2: Esquema de una arquitectura interoperable. basados en est´ andares abiertos es posible una comunicaci´on plena entre dos cualesquiera de ellos. En esta situaci´ on, un usuario puede emplear su cliente favorito (siempre que este implemente los est´ andares pertinentes) para acceder a muchos servicios distintos, o bien puede utilizar varios clientes para acceder a unos mismos datos, eligiendo en cada momento el que m´ as le convenga seg´ un sus necesidades. Las posibilidades de trabajo se multiplican cuando la arquitectura del sistema se fundamenta en est´andares abiertos. Las ventajas no son solo para los usuarios, sino tambi´en para los desarrolladores. A la hora de crear un cliente, no es necesario comprobar que este se comunica bien con todos los servidores y funciona correctamente, sino simplemente seguir las especificaciones del est´ andar. Todo aquel servidor que las implemente funcionar´a sin dificultades, ya que el est´ andar garantiza la buena comunicaci´ on y la interoperabilidad.

32.3.

Entidades creadoras de est´ andares

Crear un est´ andar no es una labor sencilla. Se han de recoger las principales necesidades y armonizar todas ellas en una especificaci´ on u ´nica, de modo que clientes y servidores que implementen ese est´ andar sean de la mayor utilidad posible para todos los usuarios. Existen organizaciones dedicadas a redactar las especificaciones correspondientes a est´andares que cubran los distintos servicios, as´ı como a promoverlas y mejorarlas. Los est´andares m´ as habituales en el campo de la informaci´ on geogr´afica son elaborados por tres organizaciones: el Open Geospatial Consortium (OGC), ISO y W3C.

32.3.1.

Open Geospatial Consortium (OGC)

El Open Geospatial Consortium [58] es una organizaci´on internacional y voluntaria dedicada a la elaboraci´ on de est´ andares. En el OGC participan m´as de 350 organizaciones miembro, incluyendo entre ellas a los principales fabricantes del sector, agencias nacionales, grupos de investigaci´ on u organizaciones sin ´ animo de lucro, entre otros. Estas organizaciones miembro colaboran para alcanzar consensos y desarrollar e implementar est´andares en el ´ ambito de los contenidos geoespaciales. Algunos de los est´ andares OGC m´ as relevantes, los cuales veremos a lo largo de este cap´ıtulo, son los siguientes: WMS. Para obtener im´ agenes de mapas.

´ n Geogra ´ fica Sistemas de Informacio

722

WCS. Para obtener y consultar coberturas. WFS. Para obtener y editar entidades geogr´ aficas y sus atributos asociados. WPS. Para servicios de procesos remotos. GML. Para almacenamiento de informaci´ on geogr´afica. CSW. Para consultas en cat´ alogos. Cada uno de estos est´ andares est´ a descrito en una especificaci´on, y estas est´an sujetas a cambios y mejoras, existiendo varias versiones en cada caso.

32.3.2.

ISO

ISO [59] es una organizaci´ on internacional dedicada a la elaboraci´on de est´andares no solo en el ´ ambito geogr´ afico, sino en todas las ´ areas. ISO es responsable, por ejemplo, de est´ andares bien conocidos y aplicados en la industria actual, tales como los relacionados con la gesti´ on medioambiental en empresas o los est´ andares de calidad. Dentro de ISO existen diversos comit´es t´ecnicos, cada uno de los cuales se encarga de definir los est´ andares correspondientes a un campo de trabajo. El comit´e ISO/TC 211 es el responsable de aquellos relacionados con la informaci´on geogr´afica digital. ISO redacta Especificaciones T´ecnicas y Est´ andares Internacionales, catalogando estos con un n´ umero que los identifica. Los elaborados por ISO/TC 211 corresponde a la serie 19100. Existe una estrecha relaci´ on entre ISO y OGC, y los est´andares elaborados por ambas organizaciones son muchos de ellos muy similares o incluso id´enticos. De hecho, algunos de los est´ andares desarrollados por el OGC, como WMS o GML, citados anteriormente y que en breve detallaremos, son tambi´en est´ andares ISO. En [60] puede consultarse la lista de normas ISO/TC211 aprobadas y el estado de cada uno de sus documentos de trabajo.

32.3.3.

W3C

El Consorcio World Wide Web (W3C) es un consorcio internacional donde las organizaciones miembro, personal a tiempo completo y el p´ ublico en general, trabajan conjuntamente para desarrollar est´ andares Web. Seg´ un su propia definici´on[61], la misi´on del W3C es guiar la Web hacia su m´ aximo potencial a trav´es del desarrollo de protocolos y pautas que aseguren el crecimiento futuro de la Web. El W3C no guarda una relaci´ on directa con los SIG, pero parece l´ogico pensar que todo aquello que se haga en el seno de Internet deber´ıa acomodarse a las pautas establecidas por este consorcio, en especial si lo que se desea es maximizar la interoperabilidad, como ya hemos visto que resulta de inter´es en el ´ ambito SIG. Puesto que la mayor´ıa de los est´andares abiertos que vamos a ver en este cap´ıtulo se aplican sobre tecnolog´ıas que operan en la red, estos se han de fundamentar siempre que sea posible en otros existentes desarrollados por el W3C, o al menos seguir las recomendaciones de este organismo. Visto de otro modo, el W3C persigue objetivos similares a los de las organizaciones que elaboran est´ andares para la informaci´ on geoespacial, pero su campo de actuaci´on es la red en t´erminos generales.

´ ndares Esta

723

De entre todos los elementos definidos por el W3C, resulta de especial importancia el lenguaje XML (eXtensible Markup Language1 ). XML no es un lenguaje en s´ı, sino que permite definir la gram´ atica de otros lenguajes. Es lo que se conoce como metalenguaje. De este modo, puede utilizarse para definir reglas para crear formas de expresi´on que permitan recoger cualquier tipo de informaci´ on. Esto hace que pueda emplearse para el intercambio de informaci´ on de toda clase, y como veremos es la base de la mayor´ıa de est´andares a tratar en este cap´ıtulo. Entrar en detalles acerca de XML escapa del ´ambito de este libro. No obstante, para aquellos que deseen saber m´ as, Internet est´ a llena de buenas referencias libres sobre XML, como por ejemplo [62].

32.4.

Est´ andares para representaci´ on y obtenci´ on de informaci´ on geogr´ afica

Entre los est´ andares m´ as importantes encontramos aquellos que especifican la forma de recoger la informaci´ on geogr´ afica, as´ı como aquellos que definen el modo en que esta se transmite. Los siguientes est´ andares OGC forman parte de este grupo.

32.4.1.

Simple Features for SQL (SFS)

Sabemos del cap´ıtulo 11 que el lenguaje SQL en su forma b´asica no sirve para recoger las geometr´ıas que forman la parte espacial de una entidad, sino u ´nicamente los datos no espaciales de esta. Sin embargo, versiones posteriores de SQL permiten la definici´on de tipos personalizados, y esto puede emplearse para poder incorporar estos elementos espaciales dentro del lenguaje. El problema surge debido a que la propia flexibilidad de este mecanismo permite que los tipos se implementen de diversas formas, lo cual no favorece la interoperabilidad. Si una consulta se establece sobre unos tipos definidos de forma distinta a como lo est´an en la base de datos que recibe la consulta, esa consulta no podr´an procesarse correctamente. Es necesario definir una forma estandarizada de definir esos tipos, y una pauta a seguir para su implementaci´ on. OGC define la especificaci´ on Simple Features for SQL (SFS) [63] con objeto de hacer frente al problema anterior. SFS define por un lado unos tipos estandarizados para geometr´ıas, los cuales se basan en otra especificaci´on OGC denominada OpenGIS Geometry Model , que establece una forma de definir geometr´ıas. Por otra parte, se definen una serie de operaciones SQL que operan sobre esos tipos. Todas las geometr´ıas que pueden definirse seg´ un este esquema son geometr´ıas en un espacio bidimensional, y cada objeto geom´etrico est´a asociado a un sistema de referencia en el cual se define. Existe un objeto fundamental denominado Geometry del que heredan los restantes en una jerarqu´ıa bien definida (Figura 32.3). Los m´etodos de este objeto son de tres tipos: M´etodos b´ asicos. Proveen informaci´ on sobre el objeto (dimensi´on, tipo de geometr´ıa, sistema de referencia, etc.) 1 Lenguaje

de Marcado Extensible

´ n Geogra ´ fica Sistemas de Informacio

724

M´etodos para comprobar relaciones espaciales entre objetos geom´etricos (cruza a, contiene a, se intersecta con, etc.) M´etodos que efect´ uan alg´ un tipo de an´ alisis (uni´on de geometr´ıas, distancia entre geometr´ıas, area de influencia de una geometr´ıa, etc.)

Figura 32.3: Esquema de clases de geometr´ıas en Simple Features for SQL. Cada uno de los objetos derivados de la clase ra´ız Geometry tiene adem´as a su vez sus propios m´etodos espec´ıficos, siempre dentro de alguno de los grupos anteriores. Con estos objetos y sus m´etodos se da respuesta a todas las necesidades que aparecen en la realizaci´ on de consultas sobre bases de datos espaciales. La especificaci´on SFS permite as´ı dotar de potencia al lenguaje de consulta SQL y hacerlo de forma estandarizada para ampliar la interoperabilidad en las operaciones de consulta.

32.4.2.

Geography Markup Language (GML)

El Geography Markup Language (GML) [64] es un lenguaje basado en XML, dise˜ nado para el almacenamiento de informaci´ on geogr´ afica. Utilizando este lenguaje, resulta posible el intercambio de informaci´ on geogr´ afica de forma interoperable. GML puede utilizarse para transmitir informaci´ on a trav´es de una red, como parte de un servicio. Este es el caso del servicio WFS que veremos m´as adelante, que devuelve informaci´on geogr´ afica codificada seg´ un este lenguaje. No obstante, puede emplearse igualmente para almacenar la informaci´ on con la que trabajamos de un SIG, del mismo modo que utilizamos

´ ndares Esta

725

cualquiera de los formatos de archivo que vimos en el cap´ıtulo 6. Es decir, sin que tengan que mediar servicios en ning´ un momento. Algunos SIG permiten este uso, y soportan GML como un formato m´as de archivo. No obstante, no es una pr´ actica com´ un, ya que, pese a las ventajas de ser un est´andar aceptado, GML es un formato de fichero de tipo texto (est´a basado en XML) y produce archivos de gran tama˜ no. Para este uso, es m´ as habitual recurrir a alg´ un otro formato. GML es un lenguaje extremadamente gen´erico, que permite recoger tanto datos r´aster como vectoriales y hacerlo con mucha flexibilidad. Permite, por ejemplo, recoger datos vectoriales sin que exista una geometr´ıa asociada, es decir, simplemente almacenando unos atributos como si se tratara de una base de datos no espacial. Esta gran flexibilidad, que es uno de los puntos fuertes de GML, es tambi´en uno de sus inconvenientes, ya que la especificaci´ on es muy compleja y dif´ıcil de implementar en su totalidad. La versi´ on m´ as reciente de GML es GML3, aunque GML2 es la m´as extendida. Existe un dialecto conocido como Simple Features Protocol que trata de solucionar el problema de la excesiva complejidad de GML3, ofreciendo las ventajas m´as importantes de este frente a GML2, pero sin incorporar todos sus elementos.

32.4.3.

Web Feature Service (WFS)

El servicio Web Feature Service WFS [65] est´a relacionado con los datos de tipo vectorial, y a trav´es de ´el se sirven directamente las entidades de un dato vectorial con sus geometr´ıas y datos alfanum´ericos asociados. Desde este punto de vista, acceder a un servicio WFS es similar a acceder a una capa vectorial cualquiera o a una base de datos, ya que el SIG puede recuperar la informaci´ on correspondiente (tanto la componente geogr´afica como la tem´atica de cada entidad) y operar con ella. En particular, las operaciones que permite un servicio WFS son: Crear una nueva entidad. Borrar una entidad. Actualizar una entidad. Obtener o consultar el conjunto de entidades en base a condiciones espaciales y no espaciales. Para realizar lo anterior, un servicio WFS debe permitir las siguientes operaciones: GetCapabilities. Esta operaci´ on devuelve los metadatos correspondientes al propio servicio WFS. Estos contienen una descripci´ on del contenido del servicio y los par´ametros que este acepta a la hora de realizar peticiones sobre ´el. Es decir, la respuesta a esta operaci´ on es un documento que informa acerca del servicio y de los datos disponibles a trav´es de este. Este documento es un archivo XML que debe comunicar al cliente el tipo de entidades que sirve y las operaciones que soporta sobre estas. DescribeFeatureType. La respuesta a esta operaci´on es la descripci´on de la estructura de las entidades que pueden servirse, indicando tipo de geometr´ıa y nombre y tipo de campos asociados a esta.

´ n Geogra ´ fica Sistemas de Informacio

726

GetFeature. Como respuesta a esta operaci´ on, el servidor devuelve un conjunto de entidades. El cliente puede especificar restricciones tanto espaciales como no espaciales en los par´ ametros de la operaci´ on, para as´ı limitar el conjunto de entidades obtenidas. Estas entidades son devueltas por el servidor en formato GML. Transaction. El servidor puede realizar transacciones. Estas se componen de operaciones que modifican las entidades, tales como la creaci´on de una nueva, o la actualizaci´on o eliminaci´ on de una ya existente2 . En funci´ on de lo anterior, podemos distinguir dos tipos de servicios WFS: Un servicio WFS b´ asico, que solo provee las tres primeras operaciones. Es decir, que permite consultar los datos, pero no modificarlos. Un servicio WFS transaccional (WFS–T) que implementa la operaci´on de transacci´on y por tanto permite realizar modificaciones en las entidades. La versi´ on m´ as actual de la especificaci´ on WFS es la 1.1. No obstante, la versi´on 1.0 es la implementada mayoritariamente en los servidores actuales. WFS 1.1 utiliza GML3 como lenguaje para la codificaci´ on de la informaci´ on a servir, mientras que WFS 1.0 usa GML2.

32.4.4.

Filter Encoding

Cuando un cliente efect´ ua una petici´ on a un servidor WFS, no es necesario que obtenga de este todas las entidades de una capa. Incluso para una zona geogr´afica dada, el usuario puede querer obtener a trav´es del cliente solo aquellas entidades que cumplan un criterio dado. Ya conocemos elementos que permiten realizar ese tipo de consultas para trabajar con un subgrupo de las entidades de una capa. En el cap´ıtulo 11 vimos el lenguaje SQL, mediante el cual pod´ıan definirse consultas de esta clase. El est´ andar Filter Encoding [66] define un formato basado en XML para el almacenamiento de expresiones de filtrado seg´ un otro est´ andar OGC conocido como OGC Common Catalog Query Language. La expresi´ on del filtro expresada seg´ un la especificaci´on Filter Encoding puede ser validada y procesada por herramientas adicionales para convertirla en las expresiones correspondientes en otro lenguaje para consulta de bases de datos espaciales. Por ejemplo, en una clausula WHERE de SQL que emplear en una sentencia SELECT. Las expresiones que pueden recogerse empleando Feature Encoding pueden ser consultas con componente espacial o hacer referencia a la parte tem´atica de la informaci´on geogr´afica. Es decir, que permiten recoger toda la variabilidad de las consultas espaciales que vimos en el cap´ıtulo 11 Adem´ as de emplear estas expresiones para consultar servicios WFS, pueden utilizarse igualmente para otros como los servicios de Nomencl´ator (Gazetteer) que veremos m´as adelante, y en general en todos aquellos en los que tenga sentido especificar alg´ un tipo de restricci´ on a la hora de realizar una petici´ on al servidor. 2 Recu´ erdese

el concepto de transacci´ on visto en el cap´ıtulo 8 sobre bases de datos

´ ndares Esta

32.4.5.

727

Web Coverage Service (WCS)

Si el est´ andar WFS permite obtener de un servidor datos vectoriales en forma de entidades, el est´ andar Web Coverage Service hace lo propio con datos r´aster. Este servicio est´ a pensado para tratar con coberturas, es decir, representaciones de un fen´omeno que var´ıa en el espacio. Como ya vimos en su momento, las coberturas se corresponden con el modelos de campos. Representar una cobertura puede hacerse de muchas formas distintas: capas r´aster, Redes de Tri´ angulos Irregulares (TIN) o funciones matem´aticas. No obstante, por el momento el est´ andar WCS solo est´ a preparado para el trabajo con mallas r´aster regulares. EL servicio WCS ofrece los datos de la capa r´aster como tales, con su sem´antica original. Es decir, que un servicio WCS puede servir un MDE y el cliente obtiene directamente los valores de elevaci´ on en sus unidades correspondientes. De forma similar a WFS, WCS presenta tres operaciones b´asicas que permiten consultar al servicio por sus caracter´ısticas o por las caracter´ısticas de los datos de que dispone, y obtener finalmente los datos en s´ı. GetCapabilities. Describe las capacidades del servicio, indicando las coberturas de que dispone. DescribeCoverage. Describe una cobertura particular GetCoverage. Obtiene una de las coberturas disponibles. Los par´ametros de esta operaci´ on se emplean para indicar al servidor la extensi´on que se desea cubrir.

32.5.

Est´ andares para mapas y visualizaci´ on

De entre todos los est´ andares que vamos a ver en este cap´ıtulo, los m´as importantes por ser los m´ as extendidos son los que sirven mapas. Entendemos por mapa en este contexto a una representaci´ on gr´ afica de una determinada informaci´on geogr´afica, elaborada a partir de una o m´ as capas. Gran parte de los sitios Web que ofrecen informaci´on geogr´afica lo hacen en forma de mapas, es decir, que permiten simplemente ((ver)) los datos geogr´aficos, y los est´andares de esta secci´ on son los encargados de definir ese tipo de servicios. El est´ andar WMS, el principal en esta categor´ıa, est´a ampliamente probado e implementado en gran cantidad de software, y es el soporte fundamental para cientos de aplicaciones basadas en mapas, lo que ratifica su utilidad y validez.

32.5.1.

Web Map Service (WMS)

El est´ andar Web Map Service (WMS) [67] define los elementos necesarios para un servicio de mapas. Un servicio WMS devuelve una imagen con informaci´on geogr´afica, pero esta solo contiene la propia informaci´ on visual para que el cliente pueda mostrarla. Es decir, si se pide a este servicio un mapa creado a partir de un MDE, la informaci´on de los p´ıxeles no contiene la elevaci´ on de la coordenada correspondiente, sino el color asociado en funci´on de un determinado criterio. La imagen puede contener otros elementos visuales tales como etiquetas o s´ımbolos, en funci´ on de c´ omo se haga la representaci´on en el servidor. Una vez que el cliente

´ n Geogra ´ fica Sistemas de Informacio

728

recibe la imagen, no puede actuar sobre esta para cambiar la forma de representaci´on de una capa, sino simplemente representarla como es. Se definen en este servicio tres operaciones b´ asicas, dos de ellas obligatorias y la restante opcional, que son empleadas por los clientes para consultar los servidores. Las tres operaciones fundamentales son: GetCapabilities (obligatoria): Al igual que en el caso de WFS y WMS, esta operaci´on describe el servicio, informando de los mapas disponibles. GetFeatureInfo (opcional): Esta operaci´ on permite al cliente pedir al servidor informaci´ on particular sobre algunas entidades representadas en el mapa. Si el servidor soporta esta operaci´ on, los mapas que devuelve pueden consultarse. Para ello, la consulta hecha por el cliente debe a˜ nadir ciertos par´ ametros adicionales como una localizaci´on (una coordenada dentro de la imagen) y el n´ umero de entidades cercanas de las que se desea obtener informaci´ on. GetMap (obligatoria): Esta operaci´ on devuelve una imagen de un mapa con unos par´ ametros geoespaciales y dimensionales (tama˜ no de la imagen) definidos. El cliente utiliza esta funci´ on para obtener un conjunto rectangular de p´ıxeles, los cuales conforman una imagen de un mapa correspondiente a una zona geogr´afica dada, o un conjunto de elementos gr´ aficos dentro de esa zona. La operaci´ on GetMap permite asimismo al cliente especificar qu´e capas emplear para formar la imagen a obtener, el sistema de referencia a utilizar, el ´area geogr´afica a cubrir o el formato en el que se desea recibir la imagen (de entre una serie de formato habituales soportados). Las capas pueden especificarse como accesos a otros servicios tales como WFS. En un servicio WMS, cuando el cliente pide un mapa al servidor, puede controlar en cierto modo la forma en que este va a representarlo (colores, estilos, etc.). El servidor ofrece una serie de opciones predeterminadas, de las cuales el cliente solo conoce su nombre, y puede elegir una de ellas. No obstante, no puede saber exactamente qu´e caracteriza a cada uno de esos perfiles predeterminados de representaci´on ni tampoco puede definir los suyos propios. Para solucionar esto y ampliar las capacidades del servicio WMS, aparece otro nuevo est´ andar: SLD.

32.5.2.

Standard Layer Description (SLD)

El est´ andar OGC Standard Layer Description (SLD) [68] define una forma de almacenar los par´ ametros de representaci´ on empleados para crear un mapa a partir de los datos geogr´ aficos. Este est´ andar permite extender las capacidades de WMS, ofreciendo al cliente la posibilidad de definir sus propias configuraciones. SLD es un est´ andar complejo que permite cubrir situaciones variadas y no solo las m´as sencillas y habituales. Permite, por ejemplo, el ajuste de elementos tales como etiquetas o simbolog´ıas personalizadas para elementos puntuales (por ejemplo, representar cada punto de una capa de localizaciones de estaciones de autob´ us con un peque˜ no dibujo de un autob´ us), Para esto u ´ltimo se apoya en otros est´ andares tales como SVG [69], dise˜ nado para la representaci´ on de gr´ aficos vectoriales.

´ ndares Esta

729

Las simbolog´ıas recogidas en un documento SLD pueden emplearse para la representaci´on tanto de capas r´ aster como vectoriales. A la hora de definir una simbolog´ıa para una capa, es necesario conocer cierta informaci´on acerca de esta. Para definir una simbolog´ıa sencilla en la que todos los elementos de una capa van a ser representados de igual forma (por ejemplo, todos las l´ıneas de una capa de r´ıos con un grosor dado y en color azul), esta informaci´on no es imprescindible, pero en caso de que se quiera variar ese color o ese grosor en funci´on de un atributo, ser´a necesario conocer qu´e atributos tiene la capa y de qu´e tipo son. Para hacer esto, pueden emplearse las operaciones de los servicios de donde se toman los datos a representar. La operaci´ on DescribeLayers del servicio WFS permite conocer los tipos de entidades de una capa representada. La informaci´on sobre los atributos puede obtenerse con la operaci´ on DescribeFeatureTypes.

32.5.3.

Web Mapping Context (WMC)

El est´ andar Web Mapping Context (WMC) [70] define un formato estandarizado para almacenar un contexto. Un contexto recoge la informaci´on necesaria para reproducir las condiciones de una determinada sesi´ on de uso de un cliente, de tal forma que ese cliente pueda restablecerlas posteriormente. El contexto se almacena en un archivo XML. En el contexto se almacena informaci´ on sobre las capas que forman el mapa representado por el cliente y los servidores de los que estas se obtienen, la regi´on cubierta por el mapa, as´ı como informaci´ on adicional para anotar este mapa. Los usos que se le pueden dar a un contexto son variados, entre ellos los siguientes: Mediante un contexto se puede definir una configuraci´on particular de inicio para distintos tipos de usuario del cliente. Un contexto puede emplearse para almacenar el estado del cliente a medida que el usuario navega y modifica elementos, pudiendo retornar a una configuraci´on establecida anteriormente. El contexto puede almacenarse y despu´es transferirse a otro cliente distinto en el que comenzar en una misma configuraci´ on. Los contextos pueden a su vez catalogarse y descubrirse, ofreciendo as´ı un nivel de granularidad m´ as amplio que las capas individuales. Pueden crearse diferentes contextos predefinidos y despu´es hacer estos accesibles para facilitar el establecimiento de una determinada configuraci´ on en un cliente.

32.6.

Est´ andares para metadatos, cat´ alogos y consulta de datos

Los metadatos y las operaciones sobre ellos tienen sus propios est´andares bien definidos. Por una parte, existen est´ andares dedicados a los metadatos en s´ı y a la forma de almacenarlos. Estos pueden especificar par´ ametros relativos a los metadatos tales como los siguientes: Contenido de los metadatos, definiendo qu´e campos son obligatorios y cu´ales opcionales.

´ n Geogra ´ fica Sistemas de Informacio

730

Formato de almacenamiento. En general, una descripci´on del formato a emplear. Pr´ acticas adecuadas de creaci´ on y actualizaci´on. Se definen las pautas correctas que han de seguirse a lo largo del ciclo de vida de los datos. Reglas de conformidad. Reglas que permiten comprobar si un determinado metadato se encuentra conforme con el est´ andar. Por otro lado, un conjunto de metadatos conforma la base para las consultas sobre un cat´ alogo, el cual describe a su vez un conjunto de datos. Como ya vimos, el cat´alogo constituye una forma m´ as sencilla y eficaz de consultar los datos, agilizando las operaciones y permitiendo el descubrimiento de datos de forma ´optima, por lo que la consulta de estos metadatos tambi´en debe estar estandarizada, y debe definirse c´omo los clientes deben obtener la informaci´ on de los metadatos para posteriormente, a partir de dicha informaci´on, realizar el acceso a los datos correspondientes que resulten de inter´es.

32.6.1.

ISO 19115 e ISO 19119

ISO 19115 e ISO 19119 son los est´ andares ISO para metadatos asociados a informaci´on geogr´ afica. Definen m´ as de 400 elementos, de los cuales los siguientes forman parte de su n´ ucleo fundamental. T´ıtulo Fecha de referencia de los datos Idioma Categor´ıa en que encuadrar la tem´ atica de los datos Resumen Punto de contacto para los metadatos Fecha de los metadatos Organismo responsable de los datos Localizaci´ on Juego de caracteres de los datos Resoluci´ on espacial Formato de distribuci´ on Tipo de representaci´ on espacial Sistema de referencia Recurso en l´ınea Identificador del fichero de metadatos

´ ndares Esta

731

Nombre del est´ andar de metadatos Versi´ on del est´ andar de metadatos Idioma de los metadatos Juego de caracteres de los metadatos En Espa˜ na, existe el N´ ucleo Espa˜ nol de Metadatos (NEM), un subconjunto de la ISO 19115 definido por un subgrupo de trabajo de la IDEE.

32.6.2.

Nomencl´ ator (Gazetteer)

Un nomencl´ ator o gazeteer permite la localizaci´on de fen´omenos geogr´aficos a partir de un determinado nombre. El cat´ alogo sobre el que se basa es una colecci´on de estos fen´ omenos, cada uno de ellos asociados a un identificador geogr´afico. Dicho identificador es una referencia espacial en forma de etiqueta o c´odigo que identifica un lugar en el mundo real [123]. Ejemplos de tales identificadores son los nombres de ciudades o pueblos (Burgos, Plasencia), los c´ odigos postales (10600), los accidentes geogr´aficos (Puerto de Navacerrada, Pico de la Miel) o las direcciones (Carretera N–V p.k.35, Calle Mayor 32), entre otros. As´ı, el servicio de nomencl´ ator permite establecer un sistema de referencia basado en identificadores geogr´ aficos. El servicio recibe como entrada un nombre y utiliza este para localizar los fen´omenos geogr´ aficos que cumplen un criterio. Este criterio puede ser variable, pudiendo exigir que el nombre coincida plenamente, que comience por ´el, o que lo contenga, entre otras opciones. Es habitual adem´ as que el cat´ alogo contenga una tipolog´ıa de los fen´omenos recogidos (poblaci´ on, r´ıo, puerto, lago, etc.), de forma que esta tambi´en puede utilizarse para establecer el criterio de consulta (por ejemplo, para localizar todos los r´ıos que comiencen con las letra ((b))). En el terreno de los nomencl´ ator encontramos la Norma ISO 19115:2003 (Geographic Information – Spatial referencing by Geographic Identifiers), y los OGC Catalog Services, que permiten estandarizar procesos de consulta como los mencionados.

32.7.

Est´ andares para procesamiento

Adem´ as de servir datos, pueden servirse procesos sobre esos datos, de tal forma que existan procesos remotos a los que los clientes pueden acceder. Tambi´en debe estandarizarse la forma de acceso a estos servicios y c´ omo los clientes efectuar´an las peticiones de procesos y la transmisi´ on o definici´ on de los datos que han de tomarse para esos procesos.

32.7.1.

Web Processing Service (WPS)

El est´ andar Web Processing Service (WPS) de OGC est´a enfocado a definir el marco en el que se ha de producir el servicio de procesos remotos. WPS define una interfaz est´andar que facilita la publicaci´ on de procesos y su uso posterior por parte de clientes. Se entiende por proceso en este contexto a todo aquel algoritmo, c´alculo o modelo que opere sobre datos georreferenciados. Los procesos que pueden definirse son sumamente flexibles, pudiendo tener un n´ umero cualquiera de entradas y salidas, y operar con distintos tipos de datos. Es decir, que ofrece

´ n Geogra ´ fica Sistemas de Informacio

732

un marco para definir cualquier tipo de proceso de an´alisis geogr´afico, tanto si este utiliza datos r´ aster como si utiliza datos vectoriales. Todos los procesos que hemos visto en la parte III de este libro pueden ofrecerse como servicios remotos a trav´es de WPS. Los datos empleados para alimentar los procesos pueden encontrarse en el propio servidor o ser transmitidos a trav´es de la red al igual que la propia petici´on de proceso por parte del cliente. Asimismo, puede relacionarse este est´ andar con otros que ya hemos visto, como por ejemplo WFS. Los datos necesarios para ejecutar un proceso que requiera una capa vectorial pueden obtenerse llamando a un servicio WFS, en cuyo caso debe indicarse en los par´ ametros del proceso los propios par´ ametros que corresponden a la petici´on a ese servicio WFS. WPS define tres operaciones b´ asicas, todas ellas obligatorias para todo servidor que implemente este est´ andar: GetCapabilities. Al igual que en otros est´ andares que ya hemos visto, esta operaci´on hace que el servidor ofrezca los metadatos referentes al servicio. En este caso, estos incluyen la definici´ on de todos los procesos que es capaz de ejecutar el servidor. DescribeProcess. El servidor devuelve la definici´on detallada de uno de los procesos soportados, especificando n´ umero y tipo de entradas y salidas, y formatos v´alidos para estas. Execute. Esta operaci´ on pide la ejecuci´ on de un proceso con unas entradas dadas, y la obtenci´ on de los resultados de este.

32.8.

Relaci´ on entre est´ andares

Los est´ andares que hemos visto a lo largo de est´as p´aginas guardan una l´ogica relaci´on entre ellos. Dentro de un mismo ´ ambito, los est´ andares pueden guardar relaci´on con otros similares aun habiendo sido desarrollados por entidades distintas. El objetivo de armonizaci´ on tecnol´ ogica que pretenden los est´ andares resulta m´as dif´ıcil de lograr si el n´ umero de est´ andares para una misma tecnolog´ıa es elevado, ya que los fabricantes necesitan dedicar m´ as tiempo y recursos a implementar todos ellos, y lo normal es que opten por implementar solo algunos. Por este motivo, las organizaciones que promueven est´andares trabajan conjuntamente y suelen producir est´ andares muy similares. En algunos casos, como ya hemos mencionado, algunos est´ andares OGC son tambi´en est´ andares ISO, existiendo no una similitud sino una absoluta coincidencia. M´ as importante es la relaci´ on que guardan entre s´ı est´andares dedicados a ´areas distintas. Las tecnolog´ıas para la gesti´ on y transmisi´ on de datos incluyen diversos elementos que forman un todo interrelacionado como vimos en el cap´ıtulo 23. Los est´andares correspondientes a esos elementos y a cada proceso particular que se desarrolla deben formar tambi´en un todo conectado y poder a su vez ((entenderse)) con otros est´andares relacionados. Un caso particular de esto es, por ejemplo, el de los est´andares WMS, SLD y WFS. El servicio WMS ofrece un mapa, que no es sino una representaci´on de unos datos seg´ un unos criterios dados. Esos datos pueden obtenerse de un servicio WFS y los criterios para representarlos pueden expresarse utilizando el est´ andar SLD. La ventaja de los est´andares abiertos, m´ axime si estos han sido adem´ as creados por una misma organizaci´on, es la capacidad de interoperar entre ellos, de forma que WMS puede tomar datos de servicios WFS o

´ ndares Esta

733

WCS, o una consulta conforme a Filter Encoding puede aplicarse para consultar un servicio WFS y tambi´en un servicio de nomencl´ ator. Otro ejemplo en esta l´ınea es el que hemos descrito para un servicio WPS que toma datos de un servicio WFS para operar con ellos. En su conjunto deben verse todos los est´ andares como una gran familia de elementos que armoniza el trabajo con la informaci´ on geogr´ afica, potenciando as´ı el cumplimiento de los objetivos de la IDE.

32.9.

Resumen

Los est´ andares abiertos son b´ asicos en el entorno de las IDE para garantizar una correcta comunicaci´ on entre clientes y servidores, y su adopci´on implica una larga serie de ventajas, aumentando las posibilidades de uso de la IDE y la potencia de los datos y herramientas que se incluyen en estas. Existen diversas organizaciones que desarrollan estos est´andares, siendo OGC e ISO las m´ as relevantes en el campo de la informaci´ on geogr´afica, y W3C en el campo de la World Wide Web. Est´ as organizaciones han creado est´andares que son de aplicaci´on en diversas tareas. Para la codificaci´ on y almacenamiento de la informaci´on geogr´afica encontramos est´andares a nivel conceptual como SFS, y otros para la propia codificaci´on y creaci´on de archivos como GML. Este u ´ltimo es el empleado tambi´en para la transmisi´on de informaci´on geogr´ afica seg´ un el est´ andar WFS, definido para el trabajo con datos vectoriales. Para servir coberturas (en la especificaci´ on actual equivalentes a datos r´aster regulares), encontramos el est´ andar WCS. Existen igualmente est´ andares para mapas, como WMS, que a su vez se apoyan en los anteriores para obtener los datos a representar, y en otros como SLD para establecer los par´ ametros de esa representaci´ on. Los est´ andares se encuentra interrelacionados entre s´ı y se apoyan unos en otros. El conjunto de todos ellos permite en el seno de una IDE el trabajo fluido y la interoperabilidad en todas las operaciones que se realizan.