FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS EMERSON LEITE DE MORAES J.O.W.S. CLIENT - UMA BIBLIOTECA PARA USO DE WEB SERVICES GEOGRÁFICOS

Transcrição

1 FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS EMERSON LEITE DE MORAES J.O.W.S. CLIENT - UMA BIBLIOTECA PARA USO DE WEB SERVICES GEOGRÁFICOS SÃO JOSÉ DOS CAMPOS 2011

2 EMERSON LEITE DE MORAES J.O.W.S. CLIENT - UMA BIBLIOTECA PARA USO DE WEB SERVICES GEOGRÁFICOS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção do título de Tecnólogo em Banco de Dados. Orientador: Reinaldo Gen Ichiro Arakaki Co-orientador: Ubirajara Moura de Freitas SÃO JOSÉ DOS CAMPOS 2011

3 EMERSON LEITE DE MORAES J.O.W.S. CLIENT - UMA BIBLIOTECA PARA USO DE WEB SERVICES GEOGRÁFICOS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção do título de Tecnólogo em Banco de Dados. GILBERTO RIBEIRO DE QUEIROZ, Me. CARLOS AUGUSTO LOMBARDI GARCIA, Me. REINALDO GEN ICHIRO ARAKAKI, Dr. UBIRAJARA MOURA DE FREITAS, Me. / / DATA DE APROVAÇÃO

4 IV AGRADECIMENTOS Agradeço a minha mãe Vera Lúcia Sant Ana e meu pai Edson Leite de Moraes pelo apoio, ininterrupto, que eles me deram ao longo desses três anos e principalmente no ultimo ano, que foi o momento em que estive mais ausente. Meus sinceros agradecimentos ao meu orientador Reinaldo Gen Ichiro Arakaki e meu co-orientador Ubirajara Moura de Freitas, pelo estimulo a pesquisa e ao apoio dado na construção deste trabalho. Não poderia deixar de agradecer aos colegas de trabalho André Carvalho, Claudio Bogossian, Henrique Asakura, Ricardo Pontes, José Thomazini e Frederico Augusto Bede pelas várias idéias trocadas sobre este trabalho, agradeço também à Claudete Borges que coordenou meu estágio na FUNCATE e junto ao Bira tornou possível esta minha vivência na área de geoprocessamento. Meus sinceros agradecimentos também ao Gilberto Ribeiro de Queiroz, do INPE, pelas idéias iniciais e dúvidas tiradas no decorrer deste ano, que foram fundamentais para que fosse possível a realização deste trabalho.

5 V Os investimentos em conhecimento geram os melhores dividendos. Benjamin Franklin

6 VI RESUMO Com a modernização da sociedade e o crescimento da internet como forma de compartilhamento de dados, viu-se a necessidade da criação de padrões para interoperabilidade de dados, entre diferentes plataformas de desenvolvimento. Uma dessas especificações é o Web Service que faz uso de protocolos da internet para realizar a comunicação entre diferentes aplicações. Atualmente, na área de geoprocessamento também existe uma forte tendência em utilizar a internet para compartilhamento de dados espaciais. Para isso, o Open Geospatial Consortium (OGC) criou um conjunto de especificações que tornam possível a interoperabilidade de dados geográficos, algumas dessas especificações são os OGC Web Services (OWS). Este trabalho apresenta a especificação e o desenvolvimento de uma biblioteca para uso de serviços OWS, bem como um protótipo de cliente Web Feature Service (WFS) implementado, utilizando a biblioteca proposta, internamente a um Sistema de Informações Geográficas (SIG) denominado Geographical Lightweight Universal Engine (GLUE), que é desenvolvido pela Fundação de Ciência, Aplicações e Tecnologias Espaciais (FUNCATE). Palavras chave: Interoperabilidade, Dados Geográficos, OGC, WFS, GML.

7 VII ABSTRACT Growth of web use as a way to sharing data and with the modernization of society, saw the need to create patterns to data interoperability, between different development platforms. One of these specifications is the Web Service that uses the web protocols to perform the comunication between different applications. Nowadays, in the GIS area also exists a tendency to use the web to share spatial data. The Open Geospatial Consortium (OGC) has created standards that provides spatial data interoperability, some of these specification are the OGC Web Services (OWS). This work presents the specification and development of a library to use the OWS services, this work shows also a prototype of Web Feature Service client that are implemented, using the proposed library, internally in a GIS called Geographical Lightweight Universal Engine (GLUE), this GIS are developed by FUNCATE. Keywords: Interoperability, Geographic Data, OGC, WFS, GML.

8 VIII LISTA DE FIGURAS Figura 2.1. Características dos Web Services Figura 2.2. Exemplo de WSDL Web Feature Service Figura 2.3. Ciclo de vida dos Web Services Figura 2.4. Hierarquia de classes geométricas Figura 2.5. Exemplo de feição geográfica em GML Figura 2.6. Operações Suportadas pelo WFS Figura 2.7. Utilização da TerraLib por uma aplicação Figura 2.8. Extensões TerraLib Figura 3.1. Arquitetura e uso do JAX-B Figura 4.1. Modelo de aplicação sem uso do padrão Façade Figura 4.2. Modelo de aplicação utilizando o padrão Façade Figura 4.3. Modelo da API com o uso do padrão Façade Figura 4.4. Casos de Uso da API Figura 4.5. WFSCapabilitiesRequester e suas dependências Figura 4.6. Interação entre WFSCapabilitiesRequester e um Serviço WFS Figura 4.7. WFSDescribeRequester e suas dependências Figura 4.8. Comunicação entre WFSDescribeRequester e um Serviço WFS Figura 4.9. WFSGetFeatureRequester e suas dependências Figura Modelo de abstração dos Requesters Figura Camada de conversão Figura Estrutura de pacotes da biblioteca Figura 5.1. Geographical Lightweight Universal Engine Figura 5.2. Cliente WFS GLUE Figura 5.3. Desmonstração WFSClient Figura 5.4. Métodos que disponibilizam os dados do GetCapabilities Figura 5.5. Criação de queries simples Figura 5.6. Resultado de GetFeature simples Figura 5.7. Criação de filtro não-espacial simples Figura 5.8. Query com filtro Figura 5.9. Resultado da requisição com filtro Figura Conversão de objetos GML para JTS Figura Dados Hidrográficos da Espanha Figura Dados do U. S. Geological Survey Região do Havaí

9 IX LISTA DE ABREVIATURAS E SIGLAS API: Application Programming Interface. DOM: Document Object Model. DPI: Divisão de Processamento de Imagens INPE. FUNCATE: Fundação de Ciência, Aplicações e Tecnologia Espaciais. GLUE: Geographical Lightweight Universal Engine. GML: Geography Markup Language. HTTP: Hyper Text Transfer Protocol. INPE: Instituto Nacional de Pesquisas Espaciais. JAX-B: Java Architeture for XML Binding. JDK: Java Development Kit. JTS: JTS Topology Suite. JVM: Java Virtual Machine. MIME: Multipurpose Internet Mail Extensions. Namespace: Qualificador de Nomes. OGC: Open Geospatial Consortium. OpenJDK: Open Java Development Kit. OWS: OGC Web Services. Parser: Analisador Sintático. POO: Programação Orientada a Objetos. REST: Representational State Transfer. SAX: Simple API for XML. SFS: Simple Feature Specification. SGBD: Sistema Gerenciador de Banco de Dados. SIG: Sistema de Informação Geográfica. SOAP: Simple Object Acess Protocol. TecGraf: Tecnologia em Computação Gráfica. UDDI: Universal Description, Discovery and Integration. URL: Universal Resource Location. W3C: World Wide Web Consortium. WCS: Web Couverage Service. WFS: Web Feature Service. WFS-T: Web Feature Service Transactional.

10 X WMS: Web Map Service. WSDL: Web Service Description Language. WWW: World Wide Web. XLink: XML Linking Language. XML: extensible Markup Language. XSD: XML Schema Document. XSOM: XML Schema Object Model.

11 XI SUMÁRIO 1 INTRODUÇÃO Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologia Organização do Trabalho Interoperabilidade de dados geográficos Web Services Web Services Geográficos Open Geospatial Consortium Simple Feature Specification Geography Markup Language Web Feature Service Iniciativas no Brasil TerraOGC A Fundação OSGeo A Biblioteca GeoTools REVISÃO TECNOLOGICA Linguagem Java Java Architeture for XML - Binding Compilação OGC para JAX-B XML Schema Object Model Xerces Java Topology Suite... 35

12 XII 4 ARQUITETURA DA API Padrões estruturais de projeto Padrão Façade Modelagem da API Casos de Uso Classes da API Classe WFSCapabilitiesRequester Classe WFSDescribeFeatureRequester Classe WFSGetFeatureRequester Classe WFSClient Conversão de geometrias GML para JTS Estrutura de Pacotes da API TESTES E RESULTADOS Geographical Lightweight Universal Engine Cliente WFS Uso da API Uso da WFSCapabilitiesRequester Construção de Queries Uso da Camada de Conversão Testes com Vários Provedores de Serviço WFS CONSIDERAÇÕES FINAIS Contribuições Trabalhos Futuros Referências Bibliográficas... 60

13 13 1 INTRODUÇÃO 1.1. Motivação Atualmente, com a modernização da sociedade, os serviços para atendimento das necessidades mais básicas das pessoas como água, luz, gás, e outros, são entregues de forma simplificada, ou seja, é possível se utilizar de energia elétrica acendendo a luz, ou ligando um aparelho elétrico na tomada. Por trás dessa facilidade, existe toda uma infra-estrutura que permite a disponibilização desse serviço. A utilização dos serviços é cobrada com base em políticas de uso. Uma tendência parecida tem ganhado força no mundo da informática, esse conceito é denominado Computação em Nuvem (Cloud Computing), e traz a idéia de disponibilização de aplicações e serviços por meio da Internet (VECCHIOLA, 2009). Segundo Zanelato (2010), uma arquitetura baseada em componentes que faz parte da idéia de Computação em Nuvem é o Serviço Web (Web Service), que tem como proposta inicial a criação de um conjunto de funcionalidades que possam ser acessadas remotamente. Essa arquitetura de serviço torna-se atraente pela questão da interoperabilidade, pois ela trabalha encima de protocolos de comunicação da Internet como Hyper Text Transfer Protocol (HTTP), utilizando-se também da linguagem de marcação extensible Markup Language (XML), possibilitando assim o desenvolvimento de serviços e clientes nas mais variadas linguagens de programação (Figura 2.1). Na área de geoprocessamento atualmente, com esse crescimento da Internet como meio de disseminação de dados, existe um forte interesse na interoperabilidade de dados geográficos, entre sistemas heterogêneos (CÂMARA, 2005). Seguindo essa tendência, o Open Geospatial Consortium (OGC) propõe uma série de especificações para a construção e utilização de Web Services Geográficos. Essas especificações foram criadas com o intuito de proporcionar maior interoperabilidade de dados espaciais, entre Sistemas de Informações Geográficas (SIG) (GARDELS, 1996). Com isso, torna-se necessário a quem tenha interesse em desenvolver utilizando os padrões OGC, ter amplo conhecimento com relação a tais padrões.

14 14 Considerando os conceitos básicos da Programação Orientada a Objetos (POO), de encapsulamento e reuso de código, junto da necessidade de se ter alto conhecimento sobre os serviços OGC, abre-se uma porta para a concepção de APIs (Interface de Programação de Aplicativos ou Application Programming Interface), que tenham como principal objetivo abstrair alguns procedimentos necessários à implementação de clientes para serviços geográficos, tendo em vista que esses procedimentos são feitos de forma padrão de acordo com as especificações Objetivos Nas subseções a seguir serão apresentados os objetivos deste trabalho Objetivo Geral Este trabalho possui como objetivo, a especificação e desenvolvimento de um protótipo de uma API Java para utilização de Web Services Geográficos Objetivos Específicos Os objetivos específicos deste trabalho são: a) Facilitar a utilização de Serviços Geográficos com a implementação da biblioteca proposta; b) Indicar práticas e tecnologias que podem ser utilizadas na concepção desse tipo de API;

15 15 c) Demonstrar o uso da biblioteca desenvolvida em um protótipo de cliente Web Feature Service Metodologia Para que a comunicação com serviços OGC seja feita de forma integra, é necessário que a implementação tanto do lado cliente, quanto do lado servidor, seja desenvolvida com base nos documentos de especificação de implementação disponibilizados pelo consórcio OGC. Para tornar possível o desenvolvimento do protótipo da API, este trabalho tem como base a especificação do serviço Web Feature Service (WFS) (OGC, 2005). O WFS é um serviço que permite aos clientes recuperarem objetos geográficos em formato Geography Markup Language (GML), e opcionalmente em outros formatos como, por exemplo, Shape File (SHP) e Keyhole Markup Language (KML) (Câmara, 2005). No decorrer do trabalho serão abordadas as tecnologias que possibilitam o desenvolvimento do protótipo, bem como os padrões de projeto de software que podem ser utilizados para estruturar a API. Com o intuito de demonstrar o uso da biblioteca proposta foi criado um protótipo de cliente WFS, internamente a um SIG Organização do Trabalho Este Trabalho está organizado da seguinte forma: a) O Capítulo 2 trata dos Web Services de uma forma geral, e mais especificamente os Serviços OGC, bem como as iniciativas no Brasil relacionadas a este trabalho; b) O Capítulo 3 aborda as tecnologias, padrões de serviços e demonstra a arquitetura da API; c) O Capítulo 4 demonstra o uso do protótipo da API, e as tecnologias empregadas;

16 d) O Capítulo 5 apresenta as considerações finais sobre este trabalho. 16

17 17 2 INTEROPERABILIDADE DE DADOS GEOGRÁFICOS A integração de dados geográficos que normalmente estão armazenados com sintaxe e semântica heterogênea, ou seja, com diferentes estruturas e significados, nos últimos tempos tem sido foco de muitas pesquisas na área de ambiente distribuído em geoprocessamento. Essa necessidade de integração de dados é advinda da demanda que as instituições produtoras de dados espaciais têm com relação ao compartilhamento dos dados produzidos (AZEVEDO, 2006). Segundo Fonseca (1999), as primeiras tentativas em se obter certa interoperabilidade de dados entre SIGs foram feitas por meio de tradução do formato de dados de determinado sistema, para o formato de outro sistema. De acordo com Lima (2002), cada SIG trabalha sobre um modelo próprio, e as organizações produtoras de dados espaciais operam de acordo com os modelos conceituais dos SIGs que ela utiliza. Com isso, quando a tradução desses dados é feita, alguns problemas semânticos podem ocorrer como: distorção de alguns dados, comprometimento da qualidade da informação, entre outros. Proporcionar um alto grau de interoperabilidade entre SIGs, não é uma tarefa trivial, isso ocorre devido à alta complexidade envolvida em informações geográficas. Atualmente, existem várias abordagens que vem sendo estudadas e aplicadas para alcançar o intercâmbio de dados espaciais (CÂMARA, 2005). A iniciativa voltada à interoperabilidade geográfica que será revisada neste trabalho é a abordagem proposta pelo consórcio OpenGIS (OGC) que segundo Gardels (1996), tem como objetivo desenvolver padrões, especificações e requisitos que suportem um Sistema Aberto de Informação Geográfica. Nesta seção serão abordados os seguintes tópicos: a) Web Services: onde serão detalhados o que a literatura aborda sobre padrões, arquiteturas, entre outros; b) Web Services Geográficos: onde se demonstram os serviços direcionados à área de geoprocessamento, definições do órgão padronizador desse tipo de serviços o OGC e especificação do serviço Web Feature Service, o qual este trabalho tem como foco;

18 18 c) Iniciativas no Brasil: nesta subseção serão abordadas as iniciativas do Brasil relacionadas à área deste trabalho Web Services De acordo com Abinader (2006), existem arquiteturas de sistemas distribuídos que possuem certa falha com relação à interoperabilidade, por serem altamente acoplados, não tendo assim o dinamismo que as atuais aplicações requerem. Com isso, surgiram os Web Services com uma proposta inovadora onde foram especificadas interfaces padrões de comunicação, que tem como base o uso de protocolos Web, gerando assim um alto grau de interação entre sistemas heterogêneos. Os conceitos que cercam a tecnologia de Web Services possibilitam que clientes sejam desenvolvidos com base nas mais diferentes plataformas de desenvolvimento, para isso é necessário apenas que a linguagem escolhida tenha suporte aos protocolos da Internet, a Figura 2.1 demonstra uma visão geral dos padrões Web Service. Figura 2.1. Características dos Web Services Fonte: Adaptado de ABINADER, 2006.

19 19 De acordo com o documento W3C (2004), os Web Services são um tipo de sistema que propicia a interoperabilidade máquina-máquina via rede mundial de computadores. Esses serviços são descritos por meio de um tipo de documento processável baseado em XML chamado Web Services Description Language (WSDL), que possui um robusto esquema de tags que tornam possível a descrição detalhada dos serviços disponibilizados. A Figura 2.2 mostra parte de um documento WSDL, no qual são especificados detalhes de como funcionam as mensagens trocadas via Web Services. Figura 2.2. Exemplo de WSDL Web Feature Service Fonte: OGC, Outra característica dos Web Services é que podem ser implementados utilizando-se do protocolo Simple Object Access Protocol (SOAP), que é um meio para que se possa realizar trocas de mensagens no formato XML entre aplicações. O uso de XML como padrão é também uma característica importante dos Web Services, pois, o XML foi projetado com o principal propósito de resolver o problema da interoperabilidade, entre aplicações (LIMA, 2002). De acordo com Lopes (2004), o ciclo de vida de um Web Service consiste em quatro etapas que são: 1. Publicação: processo considerado opcional, onde o fornecedor do serviço publica seu serviço em um servidor com suporte a Universal Description, Discovery and Integration (UDDI) que é uma linguagem de anotação XML onde é possível se criar metainformações sobre Web Services; 2. Descoberta: processo também opcional, onde o cliente encontra o serviço que procura por meio do repositório UDDI; 3. Descrição: procedimento no qual o Web Service expõe sua API por meio de WSDL, para que o cliente possa ter conhecimento das funcionalidades que o serviço dispõe;

20 20 4. Invocação: processo em que o cliente e o serviço interagem, por meio de mensagens XML, encapsuladas em envelopes SOAP. A Figura 2.2 demonstra a especificação de tais mensagens no WSDL. A Figura 2.3 demonstra um esquema representando o ciclo de vida de um Web Service. Figura 2.3. Ciclo de vida dos Web Services. Fonte: Adaptado de LOPES, 2004 Os processos referentes à publicação e descoberta são considerados opcionais, pois, é necessário apenas que o cliente tenha acesso ao WSDL do Serviço em questão, para que seja possível conhecer os métodos disponíveis, ou seja, os procedimentos obrigatórios são apenas os de descrição e invocação Web Services Geográficos No mundo dos SIGs existe também uma tendência a se utilizar Web Services Geográficos para o compartilhamento de dados espaciais, devido a isso neste tópico serão abordados

21 21 aspectos referentes ao consórcio que especifica os padrões de serviços, e também será detalhado o funcionamento do WFS Open Geospatial Consortium O Open Geospatial Consortium (OGC, 2011), também conhecido como OpenGIS, é um consórcio internacional composto por mais de 420 companhias, agências governamentais e universidades, que foi criado com o objetivo de promover soluções voltadas à obtenção de maior interoperabilidade entre sistemas que envolvem informações geográficas, propondo uma abordagem diferente dos tradicionais modelos de SIGs, onde são utilizados modelos de dados proprietários, e funções monolíticas (GARDELS, 1996). De acordo com Câmara (2005), os esforços do OGC são demonstrados na forma de especificações de interfaces e padrões que propiciam o intercâmbio de dados espaciais. Os Web Services especificados pelo OGC seguem os seguintes princípios da arquitetura orientada a serviços (OGC, 2008): Serviço: é parte da funcionalidade que é fornecida por uma entidade através de interfaces; Interface: é composta por um conjunto de operações que caracterizam o comportamento de determinada entidade; Operação: é definida por operação a ação que o serviço executa, referente à transformação ou requisição. Cada operação possui um nome e uma lista de parâmetros. Os OGC Web Services (OWS) trabalham sobre os padrões abertos da Internet, especificamente as especificações World Wide Web (WWW) do HTTP, Uniform Resource Locators (URLs), Multipurpose Internet Mail Extensions (MIME), e o XML. Atualmente, os OWS estão cada vez mais evoluindo nos aspectos relacionados aos padrões Web Service especificados pelo W3C, como no uso de WSDL e SOAP. Bem como, no uso da arquitetura REST detalhada por Fielding (2000).

22 Simple Feature Specification Uma das formas mais comuns de representar determinados fenômenos geoespaciais, do mundo real, é por meio de feições (features) geográficas. Uma feição simples, segundo OGC (1999), é composta de atributos espaciais e não-espaciais. Os atributos espaciais correspondem a uma geometria, ou conjunto geométrico, relacionado a um lugar no mundo. Já os atributos não-espaciais são os metadados referentes ao local representado pelas geometrias da feição (OGC, 2008). O consórcio OGC define por meio do padrão Simple Feature Specification (SFS), como as feições geográficas devem ser estruturadas, e estendidas, propondo também um modelo bem definido de geometrias (Figura 2.4) (OGC, 1999). Figura 2.4. Hierarquia de classes geométricas. Fonte: OGC, Na Figura 2.4 é possível visualizar como se da à hierarquia das classes geométricas do modelo SFS (OGC, 1999):

23 23 Geometry: é a classe raiz da hierarquia SFS, é uma classe abstrata, ou seja, não é possível instanciá-la. A classe Geometry define vários métodos básicos, de relações e analise espaciais que todas as subclasses devem possuir. Toda geometria está diretamente ligada a um objeto da classe SpatialReferenceSystem que define qual é o sistema de coordenadas que essa geometria se encontra; Point: é o tipo mais simples de geometria concreta, é composto apenas de duas coordenadas, uma no eixo x e outra no eixo y do sistema de coordenadas. A classe Point herda diretamente da classe Geometry; Curve: é uma geometria geralmente composta de uma sequência de pontos. Esta classe define que se uma linha não possui interseções, ou seja, não tem cruzamentos consigo mesma, ela é uma linha simples, caso contrário não. A classe Curve especifica também que quando o último ponto de uma linha é exatamente igual ao primeiro e for também uma linha simples, então essa linha é um anel. Curve herda diretamente de Geometry; Surface: uma Surface é composta de um conjunto de Curve, sendo que todas devem ser fechadas, ou seja, devem possuir o ultimo ponto igual ao primeiro ponto, uma das Curves é denominada exterior, este atributo é obrigatório. Uma Surface também pode conter zero ou mais Curves internos denominados interiors ; GeometryCollection: é a classe abstrata que define uma coleção para geometrias, permitindo a recuperação de objetos por índice, entre outras funções. Todos os objetos geométricos contidos em uma GeometryCollection devem estar associados, obrigatoriamente, a um mesmo SpatialReferenceSystem; LineString: é uma implementação concreta de Curve, e possuí o conceito de interpolação entre dois pontos, sendo que cada par de pontos define um seguimento de linha. Existem duas especializações de LineString, são elas: Line que só permite uma linha composta por apenas dois pontos e a LinearRing que aceita apenas uma linha fechada e simples; Polygon: esta classe representa uma superfície plana, que herda de Surface. Um Polygon é composto de um LinearRing exterior e zero ou mais interiors,

24 24 sendo que o exterior corresponde a borda do polígono e os interiors os possíveis buracos do mesmo; MultiSurface: é uma especialização abstrata de GeometryCollection que define alguns métodos que suas subclasses devem possuir. A única classe concreta que estende MultiSurface é a classe MultiPolygon que é uma coleção especializada de polígonos apenas; MultiCurve: é uma coleção derivada de GeometryCollection que define métodos que suas subclasses devem possuir. A implementação concreta para esta classe é a MultiLineString que é uma coleção que possui apenas objetos LineStrings; MultiPoint: esta coleção é uma implementação concreta que estende diretamente de GeometryCollection. A classe MultiPoint é especializada em armazenar pontos. Uma feição pode ser, por exemplo, do tipo rio contendo uma linha (LineString) como geometria que representa um determinado rio no mundo, e também atributos não-espaciais como nome do rio, extensão e nível de poluição. Com a analise de feições do tipo rio pode-se saber, por exemplo, onde estão localizados os rios com maior nível de poluição Geography Markup Language Tendo em vista a questão da interoperabilidade o OGC utiliza o padrão XML para que seja possível representar dados geográficos. Com isso, o consórcio criou a linguagem de marcação Geography Markup Language (GML). Atualmente, a GML encontra-se na versão e foi especificada com o intuito de transportar e armazenar informações geográficas, que incluem atributos espaciais e não espaciais de feições geográficas (OGC, 2006) (CÂMARA, 2005) (LIMA, 2002) (OGC, 2007). A GML define um conjunto de regras que permitem aos desenvolvedores implementar a melhor forma de descrever seus dados e informações no documento GML, sendo também possível se necessário que os usuários de GML convertam seus dados de seus modelos

25 25 nativos, para o modelo especificado em OGC (2007). A linguagem GML é baseada em esquemas XML denominados XMLSchemas, que de acordo com Câmara (2005), definem elementos (tags) que são suportados por determinado documento XML, que neste caso é a GML. A linguagem GML possui uma série de esquemas cuja raiz é o gml.xsd, esses esquemas podem ser encontrados em GML (2011). Tendo a posse dos esquemas, os desenvolvedores podem criar um esquema próprio para a sua aplicação. Contudo, é necessário seguir algumas regras para que a conformidade dos dados não seja afetada e assim o intercâmbio dos mesmos continue sendo possível. Segundo Câmara (2005) essas regras são: No desenvolvimento dos esquemas customizados deve ser assegurado que os novos tipos implementados sejam subtipos dos tipos da GML: para a especificação de feições gml:abstractfeaturetype ou gml:abstractfeaturecollection, e para criação de tipos de geometrias utiliza-se gml:abstractgeometrytype ou gml:abstractgeometrycollection; O esquema não deve modificar as definições dos elementos obrigatórios da GML; Os tipos abstratos definidos nos esquemas GML podem ser estendidos e restritos de forma livre pelo desenvolvedor; Os esquemas desenvolvidos devem especificar e disponibilizar um namespace, para que seja possível outra aplicação identificar tais esquemas. Seguindo essas definições é possível que desenvolvedores especifiquem seus tipos e tags garantindo que aplicações que se baseiem na tecnologia GML utilizem esses dados. A Figura 2.5 demonstra um exemplo real de feição geográfica disponibilizada por meio de GML.

26 26 Figura 2.5. Exemplo de feição geográfica em GML. O exemplo da Figura 2.5, demonstra uma instância de uma feição disponibilizada no formato GML por DPI (Divisão de Processamento de Imagens) (2011), que contém uma geometria MultiPoint que possui um Point representando um local com coordenada x e y no mundo, associada a atributos contendo dados sobre este ponto. A feição demonstrada representa um foco de incêndio, possuindo dados sobre o foco como: município, horário, data, bioma, satélite que capturou a queimada, entre outros Web Feature Service A especificação Web Feature Service (WFS) é uma das definições de serviços geográficos do OGC. Essa especificação define um serviço onde é possível realizar transações e acessos a objetos (feições) geográficos no formato GML, e opcionalmente em outros formatos, independente do modelo de dados utilizado. Existem duas versões do serviço WFS, uma delas é básica onde é possível apenas recuperar dados geográficos que se encontram no servidor, já a segunda versão é denominada WFS-T (Transactional) onde é possível se realizar operações

27 27 transacionais como: inserir, excluir, atualizar, obter bloqueio de objetos, entre outras (OGC, 2010). O serviço WFS suporta vários tipos de operação, a Figura 2.6 demonstra um Overview sobre essas operações. Figura 2.6. Operações Suportadas pelo WFS. Fonte: QUEIROZ, 2007 Para dar suporte às requisições e transações WFS, foram definidas as seguintes operações (OGC, 2007) (CÂMARA, 2005): GetCapabilites: essa operação trata de indicar quais tipos de feições o serviço dispõe e quais são as outras operações suportados pelo servidor; DescribeFeatureType: operação responsável por descrever a estrutura de qualquer tipo de feição que o serviço possua; GetFeature: operação que retorna instancias dos objetos disponíveis na base de dados do servidor. O cliente pode utilizar de critérios espaciais ou não para definir quais feições ele deseja que o serviço retorne; GetGmlObject: operação que é opcional existente somente em servidores com suporte a XLinks, neste método os clientes podem requisitar determinada feição com base em IDs (gml:id);

28 28 Transaction: operação que existe apenas em serviços que suportem WFS-T, uma transação se refere às operações que executam modificações em feições geográficas como: criar, atualizar e deletar feições; LockFeature: operação restrita a servidores WFS-T também, tem como responsabilidade possibilitar o bloqueio de uma ou mais feições para que as mesmas possam ser modificadas por operações transacionais sem que haja inconsistência ao longo da transação. Caso não seja utilizada nenhuma biblioteca, que forneça suporte às requisições descritas anteriormente, cada detalhe das formas de requisição, bem como recuperação de dados devem ser suportados diretamente pela aplicação. Por exemplo, uma aplicação cliente WFS faz uma chamada de GetCapabilities à um serviço, esta aplicação cliente vai precisar fazer uma requisição via Get ou Post junto ao serviço, utilizando uma série de parâmetros necessários para identificar a operação, após, o servidor retornará um documento XML, que a aplicação deve realizar a extração dos dados deste documento. 2.3 Iniciativas no Brasil Devido ao crescimento da necessidade do uso de Sistemas de Informações Geográficas (SIGs) ao redor do mundo, nas mais diversas áreas, viu-se no Brasil a motivação para se criar uma biblioteca voltada à construção de aplicações geográficas (CÂMARA, 2008). A TerraLib é uma biblioteca de código fonte aberto escrita em C++, desenvolvida para dar suporte a construção de aplicativos geográficos. Foi idealizada e é mantida pelo Instituto Nacional de Pesquisas Espaciais (INPE), pela Fundação de Ciência, Aplicações e Tecnologia Espaciais (FUNCATE) e a Tecnologia em Computação Gráfica (TecGraf). No entanto, apesar de existirem instituições que mantém a TerraLib, o grande ideal é que ela não só sirva como um suporte ao desenvolvimento, mas que exista contribuições da comunidade desenvolvedora da área de geoprocessamento à biblioteca (CÂMARA, 2005).

29 29 A TerraLib possui funções para a tradução de dados espaciais, estruturas de dados espaciais, representações de mapas e algoritmos para analise espacial, além de propor também um modelo de banco de dados geográfico para informações espaciais. Outra característica importante da TerraLib é a facilidade de integração numa aplicação geoespacial, pois ela se torna uma camada na aplicação (Figura 2.7), abstraindo o SGBD utilizado. Figura 2.7. Utilização da TerraLib por uma aplicação. Fonte: TERRALIB, TerraOGC De acordo com o documento TerraLib (2011), existem algumas extensões da TerraLib (Figura 2.8) criadas para promover novas funcionalidades no uso da biblioteca. Uma dessas extensões que têm um ideal parecido com o deste trabalho é o TerraOGC.

30 30 Figura 2.8. Extensões TerraLib. Fonte: TERRALIB, O TerraOGC é uma extensão que permite o uso das funcionalidades e base de dados TerraLib no ambiente da internet. Essa extensão utiliza uma arquitetura baseada nos serviços OWS. Atualmente, o TerraOGC encontra-se na versão 1.0.0, e tem suporte a aos serviços: Web Map Service (WMS), Web Feature Service (WFS) e Web Coverage Service (WCS). Tanto o TerraOGC, quanto a TerraLib podem ser encontrados para download em TERRALIB (2011). 2.4 A Fundação OSGeo A Open Source Geospatial Foundation (OSGeo), é uma fundação sem fins lucrativos, que têm como missão promover o suporte ao desenvolvimento colaborativo de código livre na área geo-espacial. A fundação possui vários projetos, dentre eles estão diversos SIGs, bem como bibliotecas que dão suporte no desenvolvimento de aplicações geográficas (OSGEO, 2012).

31 A Biblioteca GeoTools Um dos projetos do OSGeo, que possui um foco parecido com o deste trabalho é a biblioteca GeoTools. Esta API open source é escrita em Java e segue os padrões internacionais do OGC. O GeoTools atualmente possui um extenso arcabouço de classes para o desenvolvimento de aplicações geo-espaciais, em Java. Bem como, têm a colaboração de uma extensa comunidade de desenvolvedores (GEOTOOLS, 2012). A biblioteca GeoTools, suporta uma extensa gama de padrões especificados pelo OGC. Portanto, o uso do GeoTools na criação de aplicações geográficas que seguem de forma irrestrita os padrões OGC, se demonstra bastante eficaz, dado que existem alguns SIGs da própria fundação OSGeo desenvolvidos com base no GeoTools. Apesar de todo o poder da biblioteca GeoTools no ambiente Java, existem aplicações geográficas que não seguem exatamente o modelo de dados especificado pelo consórcio OGC. Um exemplo desse tipo de aplicação seria uma aplicação desenvolvida com base no modelo de dados TerraLib. A API proposta neste trabalho visa permitir o uso de serviços geográficos, por quaisquer aplicações geográficas, fazendo o papel de mediador entre o Web Service Geográfico e a aplicação, independente do modelo de dados. Enquanto que para utilizar o suporte a serviços geográficos com o GeoTools é necessário que a aplicação importe também toda a base da biblioteca que da suporte à modelagem do consórcio OGC.

32 32 3 REVISÃO TECNOLOGICA Nesta seção serão abordadas as tecnologias utilizadas neste protótipo da API Linguagem Java A linguagem de programação Java foi concebida em 1995, pela empresa Sun Microsystems, foi inicialmente utilizada no desenvolvimento de pequenos sistemas para eletrodomésticos, porém, com o tempo a linguagem passou por um grande crescimento e inúmeras transformações. Atualmente a Oracle é a empresa mantenedora do Java, que é uma das linguagens de programação mais difundidas do mundo, alguns dos grandes atrativos dessa linguagem são (Oracle, 2011): Independência de Plataforma: o Java roda encima da Java Virtual Machine (JVM), que por sua vez tem a responsabilidade de abstrair o sistema operacional que está sendo utilizado, ou seja, um programa escrito em Java tem a capacidade de rodar em ambiente Windows, ou Linux, por exemplo; Comunidade Ativa: por Java ser um projeto Open Source em sua versão OpenJDK, possui uma grande comunidade ativa que desenvolve inúmeras ferramentas livres, ajudando a plataforma a crescer cada vez mais; Grande número de Frameworks: atualmente a linguagem Java possui inúmeros frameworks e APIs para se trabalhar com as mais diversas coisas, como por exemplo: utilização de XML, bancos de dados, web, 3D, entre outros. Neste projeto, tornou-se interessante o uso de Java devido à facilidade que a plataforma oferece na utilização de XML. Nas subseções a seguir serão abordados alguns recursos oferecidos pela linguagem que foram utilizados na implementação do protótipo.

33 Java Architeture for XML - Binding Uma das abordagens da plataforma Java para uso de XML é a especificação Java Archteture for XML Binding (JAX-B). A própria JDK a partir da quinta versão possui uma implementação nativa desta especificação (Figura 3.1). Figura 3.1. Arquitetura e uso do JAX-B. Fonte: JAX-B, A arquitetura JAX-B possibilita a criação de classes Java que correspondem a um determinado documento XML, essas classes podem ser geradas utilizando o documento XML Schema (XSD) que descreve a estrutura do XML que será lido. O JAX-B possibilita com base nas classes, tanto a leitura, quanto a escrita de documentos XML que possuem aquela determinada estrutura (JAX-B, 2011) Compilação OGC para JAX-B Considerando que tanto a GML, quanto os serviços OWS possuem seus XSDs bem definidos, é possível utilizar o JAX-B para criar classes correspondentes a tais Schemas, porém, quando existe dependência entre diferentes documentos XSD como é o caso do gml.xsd que depende

34 34 de vários outros documentos, o processo de geração de classes se torna mais complicado com relação a configurações. Atualmente existe um projeto Open Source disponível em OGC TOOLS (2011), que foi criado com o intuito de prover as classes geradas a partir dos documentos XSD do OGC. Com isso, os desenvolvedores que têm interesse em criar sistemas que utilizam os padrões podem utilizar essa biblioteca de classes em suas aplicações sem ter a preocupação de gerar e documentar essas classes. Na implementação deste trabalho foram utilizadas classes que possibilitam a leitura e escrita de objetos GML e WFS XML Schema Object Model O XML Schema Object Model (XSOM), é uma biblioteca que possuí um modelo bem definido de classes capazes de representar quaisquer dados que se encontram em um documento XSD, bem como um parser capaz de ler um XSD e criar objetos com os dados do documento. Essa API permite que aplicações Java que precisem utilizar dados contidos em determinado XSD o façam de forma simplificada. Para se ter um cliente para serviço WFS, por exemplo, é indispensável o suporte a leitura de XSD em tempo de execução, pois, o método DescribeFeatureType retorna a descrição da estrutura das feições na forma de documentos XSD (XSOM, 2011) Xerces O projeto XERCES (2011) da fundação Apache, disponibiliza implementações das duas interfaces de programação para XML mais comuns, Document Object Model (DOM) e Simple API for XML (SAX). Atualmente o projeto conta com API para Java, C++ e Pearl.

35 35 O Xerces possui uma gama de funcionalidades para se percorrer e manipular documentos XML. A JDK tem a implementação do xerces de forma nativa. Com isso, não é necessário adicionar qualquer novo componente ao projeto. Na construção da API proposta neste trabalho, foi utilizado o conjunto de classes que dão suporte a abordagem DOM, pois, assim é possível integrar essa API ao JAX-B, dando mais dinamismo à manipulação de documentos XML Java Topology Suite A Java Topology Suite (JTS), é uma API escrita em Java que implementa a especificação SFS (OGC, 1999), contendo todo o modelo geométrico SFS. Esta biblioteca possui um extenso conjunto de classes que disponibilizam uma série de métodos e algoritmos para tratamento de dados espaciais (DAVIS, 2003). A biblioteca JTS foi criada com o intuito de possibilitar a construção de aplicações, em Java, que tenham a necessidade de manipular, integrar, recuperar e validar dados espaciais. Documentação, estudos de caso, guia de desenvolvimento, entre outros sobre a JTS podem ser encontrados em VIVIDSOLUTIONS (2011). A JTS foi utilizada na construção da API proposta neste trabalho, com a finalidade de disponibilizar ao desenvolvedor uma forma mais fácil de manipular as geometrias recuperadas de serviços WFS, considerando que todos os serviços OWS utilizam também o padrão SFS.

36 36 4 ARQUITETURA DA API Neste capítulo serão abordados tópicos relativos a aspectos de projeto de software, bem como tecnologias utilizadas na concretização deste projeto Padrões estruturais de projeto Segundo Gamma (1995), a criação de aplicações orientadas a objetos não é tarefa fácil, isso se torna ainda mais complexo quando se tem que pensar em reuso e flexibilidade do código. Com isso, torna-se importante a aplicação de alguns conceitos que permitem uma melhor estruturação de um projeto de software, ajudando a definir responsabilidades de classes, heranças, interfaces, hierarquias, entre outros. Essas regras são chamadas de padrões de projeto (Design Patterns). Dentro deste mundo dos Design Patterns existe um conjunto de padrões denominados padrões estruturais (Structural Patterns), tais padrões se referem diretamente em como as classes e objetos irão compor a aplicação, ou seja, definem a estrutura de forma geral. Em Gamma (1995), são descritos sete padrões estruturais: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy. Cada um desses padrões tem como foco propor uma estrutura capaz de trazer maior desacoplamento e facilidade no reuso do código, de acordo com determinados tipos de problemas Padrão Façade Para a proposta deste trabalho um padrão de projeto que se encaixou bem é o Façade que propõe uma interface unificada de alto nível responsável pela abstração no uso de um subsistema de alta complexidade. Esse padrão é muito utilizado no desenvolvimento de bibliotecas.

37 37 A grande motivação para o uso do Façade vem da dificuldade de se desenvolver uma aplicação utilizando-se diretamente das APIs de mais baixo nível, tendo que entender o funcionamento de todas elas (Figura 4.1). Figura 4.1. Modelo de aplicação sem uso do padrão Façade. Fonte: GAMMA, A Figura 4.1 demonstra uma aplicação que utiliza diretamente diversas tecnologias em seu desenvolvimento, ou seja, neste modelo não são utilizados os conceitos do padrão Façade. Figura 4.2. Modelo de aplicação utilizando o padrão Façade. Fonte: GAMMA, 1995.

38 38 Com a Figura 4.2 percebe-se que com a aplicação do padrão Façade toda a complexidade do uso das diversas APIs é escondido da aplicação por meio da criação de uma interface que simplifica o uso do subsistema. Tendo o Façade como proposta de padrão, a arquitetura da API proposta neste trabalho fica da seguinte forma (Figura 4.3). Figura 4.3. Modelo da API com o uso do padrão Façade. Fonte: GAMMA, A API abstrai o uso de um subsistema que é composto de outras bibliotecas como o JAX-B, uma compilação de classes dos XMLSchemas da OGC para JAX-B, entre outras. No caso da Figura 4.3 em especifico a aplicação do padrão Façade pode ser vista na interface WFSClient que é responsável pela abstração do subsistema Modelagem da API Nesta subseção serão abordados alguns tópicos referentes à modelagem da API.

39 Casos de Uso A API proposta neste trabalho possui os seguintes casos de uso (Figura 4.4). Figura 4.4. Casos de Uso da API. Os casos de uso apresentados na Figura 4.4 são referentes a uma implementação voltada ao serviço de WFS, os quais têm as seguintes funções: Requisitar Capacidades do Serviço: é a implementação do método GetCapabilities do WFS, o qual retorna quais dados e operações, o servidor disponibiliza; Obter Descrição de Feições que Deseja Recuperar: corresponde ao método DescribeFeatureType, o qual é responsável por descrever o tipo dos dados que determinada feição geográfica possui; Recuperar Feições Geográficas: método responsável por trazer as feições do servidor.

40 Classes da API A proposta de solução para os requisitos apresentados anteriormente é demonstrada ao longo desta subseção, definindo responsabilidades de classes, bem como quais recursos das tecnologias abordadas essas classes utilizam Classe WFSCapabilitiesRequester A Figura 4.5 demonstra o modelo de classes para a recuperação e disponibilização das capacidades de um serviço WFS. Figura 4.5. WFSCapabilitiesRequester e suas dependências.

41 41 A classe WFSCapabilitiesRequester é responsável por fazer requisições de capacidades (GetCapabilities) a um determinado serviço WFS. Internamente ao método executegetcapabilities existe a lógica de negócio para que o servidor entenda que a aplicação está requisitando suas capacidades. Após resposta do serviço, com o documento XML de capacidades, são criados objetos JAX-B que contém os dados da resposta do serviço, a partir daí o objeto WFSCapabilitiesRequester disponibiliza, ao usuário, todos os dados via métodos get. A Figura 4.6 demonstra a interação com o serviço WFS. Figura 4.6. Interação entre WFSCapabilitiesRequester e um Serviço WFS Classe WFSDescribeFeatureRequester Tendo conhecimento, por meio do GetCapabilities, de quais feições geográficas o serviço WFS disponibiliza é possível obter suas descrições, ou seja, quais atributos que uma determinada feição possui, por meio do método DescribeFeatureType. Para isso foi criada a classe WFSDescribeRequester que tem a responsabilidade de realizar requisições para obter a estrutura das feições desejadas (Figura 4.7).

42 42 Figura 4.7. WFSDescribeRequester e suas dependências. Considerando que a resposta de um servidor WFS, à requisição DescribeFeatureType, é um documento XSD contendo a descrição das feições requisitadas, a classe WFSDescribeRequester utiliza-se da biblioteca XSOM para que seja possível extrair as informações do documento de forma simples. Esta classe permite que sejam feitas requisições tanto via método Get, quanto Post. Após executado o DescribeFeatureType é possível, por meio do método getfeaturedescriptionmap, obter um mapa onde a chave é o nome da feição (QName) e o valor uma lista que contem os nomes e tipos dos atributos da referentes a esta feição. Na Figura 4.8 pode-se visualizar como se da um ciclo do WFSDescribeRequester.

43 43 Figura 4.8. Comunicação entre WFSDescribeRequester e um Serviço WFS Classe WFSGetFeatureRequester Para suprir a necessidade de recuperação das feições geográficas, disponibilizando-as à aplicação, foi criada a classe WFSGetFeatureRequester que como pode-se visualizar na Figura 4.9 possui algumas relações com outras classes.

44 44 Figura 4.9. WFSGetFeatureRequester e suas dependências As classes representadas na Figura 4.9 têm as seguintes funções: FeatureAttribute: representa um atributo não geográfico de uma feição, possui apenas um nome e um valor; GMLFeature: é a representação para uma feição geográfica recuperada de um serviço WFS. Esta classe possui ligação com as classes geradas pelo JAX-B, EnvelopeType que define a área que envolve esta feição no mundo e AbstractGeometryType que representa uma geometria; GMLFeatureCollection: é uma coleção de feições geográficas, esta classe possui uma lista de GMLFeature e têm um EnvelopeType que engloba todas as feições da lista; GMLHandler: esta classe é capaz de extrair uma geometria AbstractGeometryType, com base em um nó de um documento XML; GMLFeatureFactory: tem a responsabilidade de criar uma coleção de feições com base em um documento retornado pelo GetFeature. Está classe utiliza o mapa gerado pela WFSDescribeRequester para recuperar os atributos das

45 45 feições retornadas pelo servidor. Quando um atributo é geométrico esta classe faz uso da GMLHandler para recuperar a geometria; WFSGetFeatureRequester: classe responsável por executar requisições GetFeature à serviços WFS e utilizar a GMLFeatureFactory para disponibilizar os dados retornados na forma de um objeto GMLFeatureCollection Classe WFSClient Para tornar mais fácil o uso da API, foi criada uma classe de mais alto nível chamada WFSClient que tem a função de abstrair o uso das classes WFSCapabilitiesRequester e WFSGetFeatureRequester (Figura 4.10). Figura Modelo de abstração dos Requesters. Com o modelo apresentado, o usuário da API tem acesso a um objeto WFSCapabilitiesRequester somente após a requisição ao serviço. De posse dos dados, o usuário pode criar suas Queries (objetos QueryType) e utilizar o método getfeature para obter as feições desejadas.

46 Conversão de geometrias GML para JTS Em adição aos requisitos propostos foi criada na API uma camada de conversão de geometrias pertencentes às classes geradas pelo JAX-B, para geometrias da biblioteca JTS (Figura 4.11). Figura Camada de conversão. As classes da Figura 4.11 possuem as seguintes responsabilidades: SimpleFeature: representa uma feição geográfica, assim como GMLFeature. Porém, esta classe tem relação com classes da biblioteca JTS como Geometry e Envelope; SimpleFeatureCollection: é uma coleção de SimpleFeatures que também se utiliza de Envelope da JTS; GML311ToJTS: esta classe é responsável pela conversão de geometrias, das classes geradas pelo JAX-B, para geometrias JTS; GMLFeatureToSimpleFeature: disponibiliza métodos para conversão de GMLFeature e GMLFeatureCollection para SimpleFeature e

47 47 SimpleFeatureCollection respectivamente. Esta classe utiliza a GML311ToJTS para realizar a conversão de geometrias. Tanto as geometrias GML, quanto as JTS seguem o padrão SFS (OGC, 1999). Porém, as classes geradas, com o JAX-B, não possuem os mesmos recursos que a biblioteca JTS disponibiliza para a manipulação de geometrias. Com isso, foi importante a criação das conversões a fim de possibilitar o uso dos algoritmos espaciais da JTS Estrutura de Pacotes da API As classes modeladas anteriormente ficaram com a seguinte estrutura de pacotes (Figura 4.12). Figura Estrutura de Pacotes da Biblioteca. Cada pacote possui classes com as seguintes responsabilidades: Enumeration: possui os enumeradores da biblioteca, ou seja, as classes que determinam os valores constantes que são utilizados como, por exemplo, os namespaces fornecidos pelo OGC; Conversion: camada de conversão da API, neste pacote que se encontram classes como a GML311ToJTS; Feature: pacote dedicado as classes de feição SimpleFeature e SimpleFeatureCollection;

48 48 Gml: possui classes relacionadas à GML. Por exemplo, GMLHandler, GMLFeatureFactory, entre outros; Wfs: estão armazenados neste pacote, as classes de requisição, como WFSCapabilitiesRequester; Teste: contém os testes executados para validar as funcionalidades da biblioteca; Xml: pacote com as classes que manipulam documentos XML via DOM; Exception: possui exceções que podem ser lançadas com relação a problemas que podem ocorrer com relação a XML; Xsom: tem classes que utilizam a biblioteca XSOM, para leitura de XMLSchemas.

49 49 5 TESTES E RESULTADOS Neste capítulo será demonstrado um cliente WFS simples, que foi desenvolvido utilizando a API internamente a um SIG, bem como as funcionalidades disponibilizadas pela API proposta neste trabalho Geographical Lightweight Universal Engine Para ser possível demonstrar a funcionamento da API proposta neste trabalho foi construído um protótipo simples de cliente WFS dentro do Sistema de Informações Geográficas Geographical Lightweight Universal Engine (GLUE) (Figura 5.1). Este sistema é desenvolvido pela Fundação de Ciências, Aplicações e Tecnologia Espaciais (FUNCATE), apenas com tecnologias abertas, como Java e a TerraLib. Figura 5.1. Geographical Lightweight Universal Engine O GLUE atualmente, possui suporte a dados disponibilizados no modelo TerraLib. Este SIG também permite a visualização de mapas recuperados de serviços Web Map Service (WMS), bem como de servidores de mapas globais como: Open Street Maps, Bing e Google.

50 Cliente WFS O cliente WFS introduzido ao GLUE possui uma interface simples (Figura 5.2), que permite que um usuário do sistema entre com uma URL de um serviço WFS, escolha quais feições deseja visualizar e selecione um número máximo de feições a serem recuperadas. Figura 5.2. Cliente WFS GLUE. Tendo selecionado as feições desejadas e o número máximo, o usuário finaliza a operação e a partir daí, depois de recuperadas as feições, elas são mostradas na área de visualização do GLUE. No decorrer deste capítulo os recursos da API serão demonstrados usando este cliente WFS.

51 Uso da API Como já visto anteriormente, a API permite que o usuário faça uso de serviços WFS de forma simplificada por meio de uma classe de alto nível chamada WFSClient. Esta classe possui dois métodos (Figura 4.10). O uso desses métodos é exemplificado na Figura 5.3. Figura 5.3. Demonstração WFSClient. Na demonstração apresentada na Figura 5.3, é possível observar o comportamento da classe WFSClient. Inicialmente é necessário definir uma URL válida para um serviço WFS. Por meio do método getcapabilities é feita a requisição ao serviço e recuperadas as informações sobre as capacidades do servidor. Após isso, é possível utilizar o método getfeature para recuperar as feições desejadas. Mais adiante neste capítulo será detalhado como utilizar o objeto WFSCapabilitiesRequester e também como montar os objetos QueryType para se recuperar as feições Uso da WFSCapabilitiesRequester A classe WFSCapabilitiesRequester, como visto na seção 3, tem a responsabilidade de realizar requisições GetCapabilities, ao serviço WFS, e reter os dados retornados. Esta classe possui um conjunto de métodos get (Figura 5.4) que permitem a recuperação, pelo usuário, dos dados do GetCapabilities.

52 52 Figura 5.4. Métodos que disponibilizam os dados do GetCapabilities. Os métodos disponibilizados pela classe WFSCapabilitiesRequester, tem a função de listar, por meio de objetos JAX-B, algumas coisas como: getfeaturelist: quais feições geográficas o serviço é capaz de oferecer; getgeometryoperandlist: os tipos de objetos geométricos utilizados pelo serviço, por exemplo, gml:point; getgmlobjectlist: lista de objetos do servidor que suportam a operação GetGMLObject; getoperationsmetadata: metadados sobre as operações suportadas pelo servidor como GetCapabilities, DescribeFeatureType, GetFeature, entre outros; getoperationstypelist: quais operações transacionais este servidor suporta, por exemplo, Query, Lock, Delete, Update, etc; getspatialoperatorlist: lista de operações espaciais que o servidor provê, como interseção, está dentro, união, sobrepõe-se, etc. Com base nessas informações, é possível obter-se todas as informações necessárias para realizar outras operações junto ao servidor. A Figura 5.2 demonstra uma interface gráfica construída utilizando o método getfeaturelist, colocando seus nomes para a seleção do usuário Construção de Queries Viu-se na Figura 5.3 que para se fazer uma chamada de GetFeature a um serviço WFS, é necessário construir uma lista de objetos QueryType que correspondem as feições que se

53 53 deseja recuperar. Nesta subseção serão demonstradas algumas formas de se construir esses objetos. A Figura 5.5 demonstra como construir a lista de queries, sem nenhum tipo de filtro. Neste tipo de requisição o serviço retornará as feições do tipo requisitado, na ordem em que estiverem armazenadas respeitando apenas o valor passado como maxfeatures, que representa o número máximo de feições que o cliente deseja receber. Figura 5.5. Criação de queries simples De posse da lista de tipos de feição que o usuário deseja recuperar, é possível criar uma lista onde cada objeto QueryType corresponde a uma feição a ser recuperada. Para isso, é necessário apenas adicionar o nome da feição ao QueryType e colocar este objeto em uma lista de queries, para que posteriormente esta lista seja utilizada na chamada ao GetFeature. Se for executada a requisição exemplificada na Figura 5.2, onde a feição escolhida é Focos_Brasil e o número máximo de feições é trinta, se tem o seguinte resultado (Figura 5.6).

54 54 Figura 5.6. Resultado de GetFeature simples. Os pontos em imagens de fogo representam os focos de incêndio recuperados, sem filtros, do serviço WFS (DPI, 2011). O seguinte exemplo de código demonstra como construir um filtro não-espacial para a recuperação de feições (Figura 5.7). Figura 5.7. Criação de filtro não-espacial simples. O método criarfiltro retorna um filtro que possibilita, com base em uma propriedade da feição Focos_Brasil, recuperar feições especificas do serviço. Para definir qual é o nome do atributo

55 55 pelo qual se deseja fazer a filtragem é necessária a criação de um objeto PropertyNameType e adicionar o nome da propriedade a ele, que no caso foi uf, e para definir o valor é criado um objeto LiteralType e nele é adicionado o valor do atributo MA. A seguir, o nome e o valor da propriedade são adicionados a um objeto de comparação BinaryComparisonOpType e este objeto é adicionado ao filtro. O FilterType criado pode ser adicionado a um QueryType de requisição à Focos_Brasil (Figura 5.8). Figura 5.8. Query com filtro. Executando a mesma requisição da feição Focos_Brasil, têm-se o seguinte resultado (Figura 5.9). Figura 5.9. Resultado da requisição com filtro. É possível visualizar no mapa que foram recuperados apenas focos ocorridos no estado do maranhão. A tela no lado esquerdo mostra os dados referentes a um dos pontos recuperados. Com o uso da API é possível a criação de vários tipos de filtro, o OGC possuí toda uma documentação para a criação de filtros (Filter, 2005).

56 Uso da Camada de Conversão Como é possível ver na Figura 5.5, o resultado de um getfeature, utilizando a API, é um GMLFeatureCollection este objeto possuí todos os dados retornados sejam eles geométricos ou não. Porém, para desenvolver a parte de visualização do protótipo WFS do GLUE foi utilizada a camada de conversão das feições GML para feições baseadas em JTS (Figura 5.10). Figura Conversão de objetos GML para JTS. O procedimento de conversão é bem simples, depois de ter recuperado os dados em um objeto GMLFeatureCollection, deve-se se usar a classe GMLFeatureToSimpleFeature para transformar a coleção em um SimpleFeatureCollection. Essa operação facilita muito o desenvolvimento da parte de visualização e manipulação das geometrias pertencentes às feições, devido a gama de algoritmos espaciais que a biblioteca JTS dispõe Testes com Vários Provedores de Serviço WFS Ao longo do desenvolvimento deste projeto a API foi testada requisitando feições em diferentes serviços WFS: WFS queimadas (DPI, 2011), infraestrutura de dados espaciais da Espanha (IDEE, 2011), U. S. Geological Survey (FRAMEWORK, 2011a) (FRAMEWORK, 2011b) e servidor de demonstração MapServer (MAPSERVER, 2011), entre outros serviços.

57 57 Como os provedores de serviço também seguem as especificações OGC, viu-se que é possível com base nos padrões estabelecer comunicação de forma integra com vários servidores WFS. A Figura 5.11 e Figura 5.12 demonstram dados recuperados de alguns serviços internacionais. As linhas e polígonos correspondentes as feições recuperadas estão representadas em azul no mapa. Figura Dados Hidrográficos da Espanha. Figura Dados do U. S. Geological Survey Região do Havaí.