Uma arquitetura de software para catalogação automática de dados geográficos

Transcrição

1 Luiz André Portes Paes Leme Uma arquitetura de software para catalogação automática de dados geográficos Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós- Graduação em Informática da PUC-Rio. Orientador: Prof. Marco Antonio Casanova Rio de Janeiro 8 de agosto de 2006

2 Luiz André Portes Paes Leme Uma arquitetura de software para catalogação automática de dados geográficos Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós- Graduação em Informática da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Marco Antonio Casanova Orientador PUC-Rio Prof. Daniel Schwabe PUC-Rio Profª. Karin Koogan Breitman PUC-Rio Prof. José Eugênio Leal Coordenador Setorial do Centro Técnico Científico - PUC-Rio Rio de Janeiro 8 de agosto de 2006

3 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Luiz André Portes Paes Leme Engenheiro Eletrônico graduado pela Universidade do Estado do Rio de Janeiro em julho de Cursou Pósgraduação "latu-sensu" em Gerência e Desenvolvimento de Sistemas Distribuídos no Núcleo de Computação Eletrônica da UFRJ de julho/2000 a jun./2001. Coordenou projetos de Sistemas de Informação para a Golden Cross de 1996 a 2004 nas áreas de análise de sinistros e atendimento a clientes. Leme, Luiz André Portes Paes Ficha Catalográfica Uma arquitetura de software para catalogação automática de dados geográficos / Luiz André Portes Paes Leme ; orientador: Marco Antonio Casanova. Rio de Janeiro : PUC-Rio, Departamento de Informática, f. : il. ; 30 cm Dissertação (mestrado) Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática Inclui bibliografia 1. Informática Teses. 2. Dicionário geográfico. 3. Tesauro. 4. Alexandria digital library. 5. Catálogo. 6. Banco de dados. 7. Indexação. 8. Dado geográfico. 9. Metadado. 10. ISSO I. Casanova, Marco Antonio. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título. CDD: 004

4 Agradecimentos Ao meu orientador Professor Marco Antonio Casanova pelo grande estímulo e conhecimento técnico. À minha mulher pela paciência e carinho com que me estimulou a superar os desafios. Aos meus colegas da PUC-Rio, em especial à Daniela Brauner pelas inúmeras contribuições a este trabalho. Ao CNPq e à PUC-Rio, pelos auxílios concedidos, sem os quais este trabalho não poderia ter sido realizado. Aos professores que participaram da Comissão examinadora. A todos os professores e funcionários do Departamento pelos ensinamentos e pela ajuda. A todos os amigos e familiares que de uma forma ou de outra me estimularam ou me ajudaram.

5 Resumo Paes Leme, Luiz André Portes. Uma arquitetura de software para catalogação automática de dados geográficos. Rio de Janeiro, p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Dados geográficos estão disponíveis em quantidade e variedade crescentes à medida que evoluem as tecnologias de informática. Para torná-los úteis, é necessário que mecanismos de busca de dados possam identificar dados apropriados a determinado propósito. Tais mecanismos, comumente, utilizam catálogos de metadados que descrevem cada dado geográfico. Entretanto, a geração de metadados é um processo que pode consumir muito tempo e estar sujeito a muitos erros, caso seja feito manualmente. Essa dissertação apresenta uma arquitetura de software e tecnologias correlatas para aplicações de catalogação automática de dados geográficos. Palavras-chave 1. Informática Teses; 2. dicionário geográfico; 3. tesauro; 4. Alexandria Digital Library; 5. catálogo; 6. banco de dados; 7. indexação; 8. dado geográfico 9. metadado; 10. ISO 19115

6 Abstract Paes Leme, Luiz André Portes. A software architecture for automated cataloguing of geographic data. Rio de Janeiro, p. MSc. Dissertation - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. The amount and variety of geographic data increase as technology evolves. To make them useful it is necessary to implement search engines capable of identifying appropriate data. Such engines are usually based on metadata catalogs which describe the geographic data. However, the metadata generation process is time consuming and is not fail safe if it is carried out manually. This dissertation presents a software architecture, and related technologies, for the construction of automated cataloguing applications of geographic data. Palavras-chave 1. information science thesis; 2. gazetteer; 3. thesaurus; 4. Alexandria Digital Library; 5. catalog; 6. database; 7. indexing; 8. geographic data; 9. metadata; 10. ISO 19115

7 Sumário 1 Introdução Motivação Trabalhos relacionados Organização do trabalho 15 2 Dicionários e catálogos Padrões de metadados Padrão ISO Padrão FGDC Interface de serviço de catálogos OpenGIS Services Framework Geospatial Web Services Architecture OGC Catalogue Service Dicionários geográficos Exemplos de dicionários geográficos Classificação de objetos geográficos Padrões para dicionários geográficos Alexandria Digital Library Gazetteer 38 3 Arquitetura de software para catalogação automática de dados geográficos Estratégia de catalogação Requisitos da arquitetura Processo de catalogação Geração de metadados Esquema de metadados 55 4 Implementação do GeoCatalog Casos de uso Padrão arquitetural da aplicação Interface de usuário Interação com usuário 70

8 Atualização das informações de interface de usuário Configuração de um processo de catalogação Inicialização de processo de catalogação Geração de metadados Framework de catalogação de dados Métricas e organização do código Exemplo de utilização 89 5 Conclusões e trabalhos futuros 94 6 GLOSSÁRIO 96 7 REFERÊNCIAS 99 8 APÊNDICE A Protocolo de Serviço do ADL Gazetteer (esquemas XML) APÊNDICE B Casos de teste 109

9 Lista de figuras Figura 1 Esquema do processo de identificação de áreas de alagamento ao redor de um rio 13 Figura 2 Esquema de organização de dados geográficos definidos pela ISO Figura 3 Esquema geral de metadados geográficos definidos pela ISO Figura 4 Componentes do OpenGIS Services Framework 27 Figura 5 Camadas de serviços na arquitetura OWS 29 Figura 6 Arquitetura interna de um serviço de catálogo 30 Figura 7 Fragmento da hierarquia de termos do ADL Gazetteer Feature Type Thesaurus 35 Figura 8 Um fragmento do ADL Feature Type Thesaurus e uma imagem da cidade do Rio de Janeiro 46 Figura 9 - Arquitetura de agentes para o processo de catalogação 48 Figura 10 - Processo de catalogação automática 51 Figura 11 - Recuperação de informações 54 Figura 12 - Esquema de metadados 57 Figura 13 Diagrama de Casos de Uso 59 Figura 14 - Divisão de componentes do GeoCatalog segundo o padrão MVC 68 Figura 15 Componentes da interface de usuário do GeoCatalog 69 Figura 16 - Janela de área de trabalho 70 Figura 17 - Estrutura do padrão de projeto Command 70 Figura 18 - Padrão Command no GeoCatalog 71 Figura 19 - Estrutura do padrão de projeto Observer 72 Figura 20 - Estrutura do padrão de projeto Factory Method 75 Figura 21 Fábrica de objetos do GeoCatalog 76 Figura 22 - Infra-estrutura para criação de agentes 77 Figura 23 Framework de catalogação automática 83 Figura 24 Arquivo contendo a descrição de área geográfica do entorno do estádio do Maracanã (Rio de Janeiro) 89 Figura 25 Arquivo contendo a descrição de uma região vazia 90

10 Figura 26 Arquivo com erro de estrtura (falata o identificador) 90 Figura 27 Configuração de processo de catalogação no GeoCatalog 91 Figura 28 Metadados produzidos pela catalogação dos arquivos de dados anteriormente especificados 92 Figura 29 Metadados produzidos pela catalogação dos arquivos de dados anteriormente especificados (cont.) 93 Figura 30 - Estratégia de teste 111

11 Lista de tabelas Tabela 1 Conjunto de metadados principal definidos pela ISO Tabela 2 Conjunto de metadados principal definidos pela ISO (cont.) 23 Tabela 3 Elementos de metadado obrigatórios no padrão FGDC 24 Tabela 4 Elementos de metadado obrigatórios no padrão FGDC (cont.) 25 Tabela 5 Elementos de metadado obrigatórios no padrão FGDC (cont.) 26 Tabela 6 Conjunto de metadados mínimo 31 Tabela 7 Conjunto de metadados mínimo (cont.) 32 Tabela 8 Relacionamentos entre conceitos de um tesauro 34 Tabela 9 Alguns atributos selecionados do esquema conceitual da ISO Tabela 10 Alguns atributos selecionados do ADL Gazetteer Content Standard 37

12 1 Introdução 1.1. Motivação Dados geográficos estão disponíveis em uma grande variedade de repositórios, desde os computadores pessoais até repositórios sofisticados mantidos por organizações. Para ajudar na localização e acesso aos dados disponíveis, um tipo de solução frequentemente utilizado é organizar descrições dos dados em catálogos de metadados. Apesar da óbvia utilidade dos catálogos de metadados, o processo de gerá-los manualmente pode ser tedioso ou até impossível, dependendo da quantidade de metadados envolvida. Por isso, catálogos devem possuir um componente que automatiza o processo de geração e armazenamento de metadados tanto quanto possível. Tal componente pode obter metadados tanto por uma análise do recipiente onde se encontra armazenado o dado a ser catalogado, como dos dados já armazenados no próprio catálogo ou em outro repositório disponível. Em se tratando do domínio de sistemas de informação geográfica, temos duas valiosas ferramentas para abordar esse problema. Primeiro, vários sistemas de geo-referenciamento associam a cada entidade geográfica sua posição na superfície terrestre, o que funciona como um identificador universal para a entidade, ou pelo menos uma aproximação. Em segundo, muitos dicionários de nomes geográficos têm sido desenvolvidos e disponibilizados na Web nos últimos anos. É possível generalizar a solução do problema de localização e acesso a dados geográficos para outros tipos de dados. A diferença encontra-se nas técnicas utilizadas para a geração dos metadados.

13 Introdução 13 Neste trabalho propomos uma estratégia de geração e catalogação automática de metadados e uma arquitetura de software para implementá-la. A arquitetura foi concebida de maneira que gerasse como subproduto um framework para catalogação automática de dados de quaisquer naturezas. Não abordamos, no entanto, estratégias de geração de metadados para dados não geográficos Trabalhos relacionados Para encaminhar o problema da catalogação de dados geográficos, inúmeras soluções têm sido propostas na comunidade científica. A seguir são brevemente apresentados alguns trabalhos relacionados que serviram e podem vir a servir, sobremaneira, como inspiração e fontes de informação para o desenvolvimento desta pesquisa. Figura 1 Esquema do processo de identificação de áreas de alagamento ao redor de um rio Em The Role of Spatial Relations in Automating the Semantic Annotation of Geodata, Klien e Lutz [2] propõem um procedimento para descrição semiautomática de dados geográficos com o propósito de identificar áreas de alagamento ao redor de rios. As descrições são produzidas a partir da identificação de relacionamentos topológicos, através de operações GIS, entre dados de referência e dados que se deseja descrever. Em seguida, uma

14 Introdução 14 ontologia geo-espacial é utilizada para classificar os dados e associá-los entre si através dos relacionamentos topológicos identificados. Por fim, técnicas de mineração de dados sobre a ontologia e seus dados são empregadas para identificar as áreas de interesse. Um esquema dessa abordagem pode ser visto na Figura 1. Em Semantic Annotation of Image Collections, Hollink et al. [4] apresentam uma ferramenta para registro de descrições e busca de dados em uma coleção de imagens de arte. As descrições são produzidas baseadas em um vocabulário restrito e definido por quatro dicionários: The Art and Architecture Thesaurus (AAT), WordNet, IconClass e The Union list of Artist Names (ULAN). O esquema de metadados é derivado do VRA 3.0, que é uma especialização do Dublin Core para aplicações de imagens de arte. A qualidade e precisão das descrições baseiam-se em duas técnicas. Na primeira, o domínio de cada atributo da imagem é limitado a um vocabulário especifico de um ou mais dos quatro dicionários, dessa forma padroniza-se o vocabulário empregado. Por exemplo, o nome do artista autor da obra é selecionado, pela ferramenta, do ULAN, a descrição da cena pode ser obtida no IconClass, etc. A segunda técnica presta-se a registrar sentenças de descrição da obra. É proposta uma sintaxe na forma: agente ação objeto recipiente. Um exemplo dessa abordagem é um quadro de Chagal que poderia ser descrito pela seguinte sentença: Chagal, Mark kiss wives. Também aqui, é empregado um vocabulário controlado oferecido pelos dicionários. Para o mecanismo de busca é proposto o alinhamento dos dicionários pela implementação de relacionamentos entre termos. Três tipos de relacionamentos são definidos: equivalência, subclasse e domínio específico. Uma equivalência ocorre quando dois termos de dicionários diferentes são equivalentes. Uma subclasse é quando um termo em um dicionário define um conceito que pode ser visto como uma subclassificação de um conceito em outro dicionário. Por fim, o domínio específico mapeia conceitos que, embora diferentes, estão relacionados de alguma forma, por exemplo, técnicas de pintura e materiais utilizados. Essa técnica permite utilizar o vocabulário de todos os dicionários para formular-se consultas aos dados.

15 Introdução 15 Em The Role of Gazetteers in Geographic Knowledge Discovery on the Web, Ligiane Souza et al. [3] descrevem a arquitetura do dicionário geográfico LOCUS e seu mecanismo de consulta. Propõem que essa ferramenta seja utilizada em conjunto com motores de busca de páginas Web para permitir a seleção de dados com base em informações geográficas. Apresentam, também, uma estratégia para popular o dicionário a partir de páginas Web disponíveis. Um agente percorre várias URL s procurando por informações que se encaixam em padrões previamente especificados pelo usuário e extraem deles fragmentos de informação para compor uma entrada do dicionário. Exemplificam o processo com a home page de um hotel da qual são extraídos o nome do hotel, seu endereço e telefones. O endereço capturado é, então, cruzado com informações prévias contidas no dicionário para agregar-lhe referências geográficas e finalmente cadastrado no dicionário. Em GeoReferencing the Semantic Web: ontology based markup of geographically referenced information, Hiramatsu et al. [5] apresentam duas ferramentas para tratamento de informações geo-referenciadas. A primeira permite ao usuário editar graficamente formas geométricas geo-referenciadas e produz um arquivo RDF contendo todos os relacionamentos topológicos entre elas. Para esse processo, Hiramatsu desenvolveu uma ontologia de descrição de relacionamentos topológicos e outra para classificação de locais geográficos, como estado, continente, país, etc. A segunda ferramenta seleciona, em um repositório de objetos, duas entradas e calcula o relacionamento topológico entre elas. Os objetos são previamente descritos em RDF, utilizando a ferramenta anterior, e armazenados no repositório. Serviços Web para consulta ao repositório e cálculo de relacionamento foram especialmente desenvolvidos Organização do trabalho Esse trabalho está organizado da seguinte forma. O capítulo 2 apresenta as principais tecnologias utilizadas para catalogação automática de dados geográficos: catálogos de metadados e dicionários geográficos. Para catálogos, são indicados padrões internacionais de esquemas de dados e interfaces de serviços. Para dicionários, são descritos brevemente alguns dicionários existentes e feita uma análise mais detalhada para o ADL Gazetteer. O capítulo 3 especifica um método para correlacionar dados geográficos com objetos de um

16 Introdução 16 dicionário de modo a obter uma descrição do dado. Apresenta, também, uma arquitetura de software para aplicar esse método na catalogação automática dos dados. O capítulo 4, como prova dos conceitos apresentados, especifica um projeto de software para catalogação automática de dados geográficos. Ao final do capítulo os conceitos de catalogação automática são generalizados em um framework que pode ser customizado para tratar outros tipos de dados. Por fim, o capítulo 5 apresenta algumas conclusões sobre esta dissertação e indica algumas linhas de pesquisa a serem desenvolvidas a partir do exposto aqui.

17 2 Dicionários e catálogos A crescente disseminação de informações geográficas digitais como, por exemplo, cartas geográficas e imagens de satélite, aliada à crescente oferta de sistemas de informações geográficas, requerem métodos para melhor entendimento de dados geográficos disponíveis. Dados geográficos digitais têm o propósito de representar o mundo real para análise por computador. São representações da realidade onde aproximações, simplificações e omissões podem ocorrer. Para garantir que um dado não será erroneamente utilizado as suposições e limitações envolvendo sua produção devem ser completamente documentadas. Metadados permitem que os produtores dos dados os descrevam apropriadamente, de modo que os usuários possam avaliar mais precisamente sua aplicabilidade e uso. Dados geográficos são, normalmente, utilizados por terceiros, ou seja, pessoas, organizações, etc. Documentação apropriada permite, àqueles não familiarizados com os dados, utilizá-los corretamente. Metadados, por definição, são dados sobre dados, isto é, dados que descrevem outros dados. Fornecem informações sobre o conteúdo de um dado, informações históricas, modo de obtenção do dado, sua qualidade, etc. Iremos assumir que dados geográficos terão ao menos uma escala e uma descrição da área da superfície terrestre coberta por ele. Essa descrição é frequentemente um retângulo ou um paralelogramo cujos vértices são definidos por coordenadas em um dado sistema de referência (CRS). A escala, a descrição da área coberta e o CRS utilizado são tratados como metadados dos dados. Catálogos de metadados geográficos contém metadados de dados geográficos [8]. São a estratégia mais simples de compartilhamento de dados geográficos entre aplicações. Tais catálogos oferecem serviços de consulta e

18 Dicionários e catálogos 18 manipulação de metadados, bem como, serviços de intermediação de recuperação de dados geográficos. Catálogos não armazenam o dado geográfico em si, mas possuem uma referência para o seu local de armazenamento. Assim, na recuperação de um dado, o serviço é redirecionado para o sistema de armazenamento do dado que o localiza e o retorna ao cliente. Para um compartilhamento efetivo de dados, não é suficiente a disponibilidade de descrições detalhadas. É necessário que o esquema de metadados e as interfaces de consulta e recuperação sejam internacionalmente padronizadas. Duas autoridades propõem esquemas de metadados para dados geográficos: US Federal Geographic Data Comittee (FGDC) 1 e o International Organization of Standards (ISO) 2. O FGDC é um comitê dos EUA que coordena o compartilhamento de dados geográficos através do portal Geodata 3. Utiliza dados da National Spatial Data Infraestructure (NSDI) Clearing Network. Essa rede é uma coleção de catálogos de metadados conhecida como Clearinghouse Nodes. Cada nó é hospedado por uma organização diferente e contém metadados que descrevem dados sob sua área de responsabilidade. O FDGC está, atualmente, conduzindo o desenvolvimento de uma adaptação para os EUA do padrão ISO 19115:2003 que veremos a seguir. A ISO é uma organização internacional, formada por representantes de diversas empresas e governos, para estabelecer padrões internacionais. Seu trabalho é, normalmente, conduzido por comitês técnicos. Cada membro da organização interessado em algum assunto para o qual foi estabelecido um comitê tem o direito de se fazer representar nele. Organizações internacionais, governamentais e não governamentais, em colaboração com a ISO, também tomam parte no trabalho

19 Dicionários e catálogos 19 O comitê técnico ISO/TC211, Geographic Information/ Geomatic foi constituído para especificar um esquema de metadados para dados geográficos. Esse esquema foi apresentado na norma ISO 19115:2003. O Open Geospatial Consortium (OGC) 4 é uma organização não lucrativa, internacional, que está conduzindo o desenvolvimento de padrões para serviços geo-espaciais e serviços baseados em localização. A OGC atua com governos, indústria e universidades para criar interfaces de programação abertas e extensíveis para Sistemas de Informações Geográficas (GIS). O OGC desenvolveu uma especificação, atualmente na versão 2.0, para a interface de serviços de catálogo que suporta a publicação e consulta de metadados para dados e serviços geográficos, bem como a localização e recuperação de recipientes de dados geográficos selecionados Padrões de metadados Padrão ISO A ISO 19115:2003 propõe um padrão de metadados para dados e serviços geográficos digitais. A norma define elementos de metadados (identificação, extensão, qualidade, esquema temporal e espacial, referência espacial e distribuição do dado) e fornece um esquema e uma terminologia de metadados comum. Ela faz referência a outras normas da série 191xx que devem ser consultadas para esclarecimentos mais específicos. Estruturas de dados básicas organizam os dados e seus relacionamentos com metadados. A Figura 2 apresenta o esquema dessas estruturas. Dados geográficos (DS_Dataset) são coleções de dados identificáveis. Podem representar abstrações menores do mundo real que, limitadas por alguma restrição como extensão espacial ou tipo de objeto, estão fisicamente localizados dentro de outra representação maior do mundo real ou outro dado. 4

20 Dicionários e catálogos 20 Dados podem representar tanto um único objeto geográfico, quanto um mapa, imagem geográfica, ou qualquer outro dado geográfico. Uma agregação de dados é uma abstração para agrupar conjuntos de dados geográficos relacionados. Pode ser especificada como um agrupamento de uso geral (DS_OtherAggregate), uma série de dados (DS_Series) 5 ou como uma atividade especial (DS_Initiative). Por sua vez, uma série de dados pode ser do tipo plataforma de sensoriamento (DS_Platform), sensor (DS_Sensor) ou uma produção em série (DS_ProductionSeries). Uma agregação pode agrupar outras agregações e, assim formar uma hierarquia de dados. GF_FeatureType 0..* +featuretype GF_AtributeType 0..* +propertytypemetadata 0..* +propertytype GF_PropertyType 0..* 1..* +featuretypemetadata Serializable MD_Metadata +seriesmetadata 0..* +featureatribute 0..* +featureatributemetadata 1..* +has MultipleAggregation 0..* +superset 0..* +subset 0..* +series Serializable DS_Aggregate 0..* 1..* +partof +composedof 0..* +describes Serializable DS_DataSet DS_OtherAggregate DS_Series DS_Initiative DS_StereoMate DS_Platform DS_Sensor DS_ProductionSeries Figura 2 Esquema de organização de dados geográficos definidos pela ISO Os metadados são normalmente associados ao conjunto de dados, que deve possuir pelo menos uma estrutura de metadados. Ao tratar-se de séries de 5 Um conjunto de dados do tipo série é uma coleção de dados que compartilham a mesma especificação de produto.

21 Dicionários e catálogos 21 dados a norma propõe que a agregação dos dados possua pelo menos uma estrutura de metadados. Os metadados estão distribuídos por várias estruturas de dados que organizam as informações segundo sua natureza. O esquema geral dessas estruturas pode ser visto na Figura 3. O conjunto principal de metadados (MD_Metadata) pode ser complementado com metadados sobre a representação espacial (MD_SpatialRepresentation) do dado geográfico, sistemas de geo-referenciamento (MD_ReferenceSystemInformation), qualidade do dado (MD_DataQuality), identificação do dado (MD_Identification), etc. MD_ReferenceSystem Serializable MD_SpatialRepresentation MD_MetadaExtensionInformation 0..* +spatialrepresentationinfo 0..* +referencesysteminfo 0..* +metadataextensioninfo DQ_DataQuality MD_Distribution MD_ContentInformation 0.. +dataqualityinfo distributioninfo 0..* +contentinfo Serializable MD_Metadata +featuretype:gf_featuretype +atributetype:gf_atributetype +fileidentifier:string +language:string +characterset:string +parentidentifier:string +hierarchylevel:md_scopecode +hierarchylevelname:string +contact:ci_responsibleparty +datestamp:date +metadatastandardname:string +metadatastandardversion:strin +dataseturi:string +series:ds_aggregate -describes:ds_dataset metadatamaintenance 0..* +resourcemaintenance 1..* +identificationinfo MD_MaintenanceInformation MD_Identification 0..* +portrayalcatalogueinfo MD_PortrayalCatalogueReferenc 0..* +metadataconatraints MD_Conatraints 0..* +resourceconstraints 0..* +applicationschemainfo MD_ApplicationSchemaInformatio Figura 3 Esquema geral de metadados geográficos definidos pela ISO19115 Existe um conjunto extenso de elementos de metadados, do qual somente um subconjunto é, normalmente, utilizado. Entretanto, é essencial que um conjunto básico, mínimo, de elementos de metadados seja utilizado para

22 Dicionários e catálogos 22 descrever um conjunto de dados. A Tabela 2 lista os elementos de metadados principais para identificar dados geográficos, tipicamente para propósitos de catalogação. Os elementos com o símbolo (M) são definidos como obrigatórios, aqueles com (O) são opcionais e aqueles com (C) são obrigatórios em algumas circunstâncias. Essa lista contém elementos para responder às seguintes questões: Existe dado sobre um tópico específico ( O que )?, Sobre algum lugar ( Onde )?, Em alguma data ou período ( Quando )? e Qual o ponto de contato para obter mais informações sobre o dado ou obter cópia ( Quem )?. Elemento de metadado MD_Metadata>MD_DataIdentification.citation >CI_Citation.title MD_Metadata>MD_DataIdentification.spatial RepresentationType MD_Metadata>MD_DataIdentification.citation >CI_Citation.date MD_Metadata>MD_ReferenceSystem MD_Metadata>MD_DataIdentification.pointOf Contact>CI_ResponsibleParty MD_Metadata>DQ_DataQuality.lineage>LI_Li neage MD_Metadata>MD_DataIdentification.extent> EX_Extent>EX_GeographicExtent>EX_Geog raphicboundingbox or EX_GeographicDescription MD_Metadata>MD_Distribution>MD_DigitalTr ansferoption.online>ci_onlineresource MD_Metadata>MD_DataIdentification.langua ge Dataset title (M) Descrição Spatial representation type (O) Dataset reference date (M) Reference system (O) Dataset responsible party (O) Lineage (O) Geographic location of the dataset (by four coordinates or by geographic identifier) (C) On-line resource (O) Dataset language (M) MD_Metadata.fileIdentifier MD_Metadata>MD_DataIdentification.charact erset Metadata file identifier (O) Dataset character set (C) Tabela 1 Conjunto de metadados principal definidos pela ISO 19115

23 Dicionários e catálogos 23 Elemento de metadado Descrição MD_Metadata.metadataStandardName MD_Metadata>MD_DataIdentification.topicCa tegory MD_Metadata.metadataStandardVersion MD_Metadata>MD_DataIdentification.spatial Resolution>MD_Resolution.equivalentScale or MD_Resolution.distance MD_Metadata.language MD_Metadata>MD_DataIdentification.abstrac t MD_Metadata.characterSet MD_Metadata>MD_Distribution>MD_Format. nameandmd_format.version MD_Metadata.contact>CI_ResponsibleParty MD_Metadata>MD_DataIdentification.extent> EX_Extent>EX_TemporalExtent or EX_VerticalExtent MD_Metadata.dateStamp Metadata standard name (O) Dataset topic category (M) Metadata standard version (O) Spatial resolution of the dataset (O) Metadata language (C) Abstract describing the dataset (M) Metadata character set (C) Distribution format (O) Metadata point of contact (M) Additional extent information for the dataset (vertical and temporal) (O) Metadata date stamp (M) Tabela 2 Conjunto de metadados principal definidos pela ISO (cont.) A utilização de itens opcionais, além dos itens obrigatórios aumentará a interoperabilidade entre aplicações, permitindo aos usuários compreender os dados geográficos e os metadados relacionados livres de ambigüidades. Versões customizadas do conjunto de metadados devem incluir os últimos Padrão FGDC O Content Standard for Digital Metadata (CSDGM) (FGDC 1998) estabelece um conjunto de terminologias e definições para a documentação de dados geográficos digitais, incluindo elementos de metadados para os seguintes tópicos: Identificação: nome, desenvolvedor, área geográfica coberta, temas de informação incluídos, restrições de acesso. Qualidade de dado: precisão de posição e de atributos, integridade, consistência, procedência.

24 Dicionários e catálogos 24 Organização espacial do dado: modelo de dados espacial utilizado para codificar o dado geográfico, número de objetos geográficos, métodos além de coordenadas, utilizados para codificar localizações, tais como ruas e endereços. Referências espaciais: codificação das localizações das coordenadas, projeção de mapa ou sistema grade utilizado, parâmetros para converter o dado para outro sistema de coordenadas. Informação de entidade e atributos: informação geográfica (estradas, casas, elevação, temperatura, etc.) Distribuição: agência de distribuição, formatos e mídias disponíveis, preço, distribuição on-line. Referência dos metadados: timestamp e agência responsável pela compilação dos metadados. A Tabela 3, a Tabela 4 e a Tabela 5 mostram os elementos de metadados obrigatórios no padrão FGDC. Data Originator XML Tag Elemento de Metadado /metadata/idinfo/citation/citeinfo/origin/ Data Title /metadata/idinfo/citation/citeinfo/title/ Abstract /metadata/idinfo/descript/abstract/ Progress Descrição O nome de uma organização ou de um indivíduo que gerou o dado O nome pelo qual o dado é conhecido Um a breve resumo sobre o dado O estado do dado /metadata/idinfo/status/progress West Bounding Coordinate /metadata/idinfo/spdom/bounding/westbc/ East Bounding Coordinate /metadata/idinfo/spdom/bounding/eastbc/ North Bounding Coordinate /metadata/idinfo/spdom/bounding/northbc/ Tabela 3 Elementos de metadado obrigatórios no padrão FGDC Coordenada mais a oeste da area coberta pelo dado expressa em longitude Coordenada mais a leste da área coberta pelo dado expressa em longitude Coordenada mais ao norte da área coberta pelo dado expressa em latitude

25 Dicionários e catálogos 25 XML Tag Elemento de Metadado South Bounding Coordinate /metadata/idinfo/spdom/bounding/southbc/ Theme Keyword /metadata/idinfo/keywords/theme/themekey/ Metadata Contact Organization /metadata/metainfo/metc/cntinfo/cntorgp/cntorg/ Metadata Contact Person /metadata/metainfo/metc/cntinfo/cntperp/cntper/ Metadata Contact Address City Metadata Contact Address State or Province /metadata/metainfo/metac/cntinfo/cntaddr/state/ Metadata Contact Address Postal Code Descrição Coordenada mais ao sul da área coberta pelo dado expressa em latitude Palavra ou frase mais frequentemente utilizada para descrever o conteúdo do dado O nome da organização para a qual o tipo de contato se aplica O nome do indivíduo para o qual o tipo de contato se aplica A cidade do endereço O estado ou provincial do endereço Código postal do endereço /metadata/metainfo/metac/cntinfo/cntaddr/postal/ Publication Date /metadata/idinfo/citation/citeinfo/pubdate/ Purpose /metadata/idinfo/descript/purpose/ Time Period of Content: Single Date /metadata/idinfo/timeperd/timeinfo/sngdate/caldate A data de liberação para publicação ou data de publicação Um resumo do propósito de geração do dado O período de tempo pelo qual o dado corresponde à referência Time Period of Content: Range of Dates, Beginning Date /metadata/idinfo/timeperd/timeinfo/rngdates/begdate/ Time Period of Content: Range of Dates, Ending Date /metadata/idinfo/timeperd/timeinfo/rngdates/enddate/ Currentness Reference /metadata/idinfo/timeperd/current/ A base de tempo sob a qual o período de tempo é determinado Maintenance and Update Frequency /metadata/idinfo/status/update A freqüência com a qual alterações e adições são realizadas sobre o dado após sua primeira produção Tabela 4 Elementos de metadado obrigatórios no padrão FGDC (cont.)

26 Dicionários e catálogos 26 XML Tag Elemento de Metadado Theme Keyword Thesaurus /metadata/idinfo/keywords/theme/themekt/ Access Constraints /metadata/idinfo/accconst/ Use Constraints /metadata/idinfo/useconst/ Metadata Contact Address Type Descrição Referência a um tesauro formalmente registrado ou a uma autoridade similar Restrições e pré-requisitos para acesso ao dado Restrições e pré-requisitos legais para utilizar o dado Tipo de endereço /metadata/metainfo/metc/cntinfo/cntaddr/addrtype/ Metadata Contact Phone number /metadata/metainfo/metc/cntinfo/cntvoice/ O número de telefone do contado Metadata Date Data de criação ou última atualização do dado Tabela 5 Elementos de metadado obrigatórios no padrão FGDC (cont.) 2.2. Interface de serviço de catálogos OpenGIS Services Framework As especificações OGC seguem uma arquitetura de referência, chamada OpenGIS Services Framework (OSF) [19], que identifica serviços, interface e protocolos de troca de dados que as aplicações podem utilizar. Resumidamente o OSF consiste no seguinte (Figura 4): Padrões de codificação: padrões que especificam intercâmbio e armazenamento de dados geográficos, incluindo sistemas de referenciamento espacial e topologia e geometria de objetos geográficos. Incluem a Geography Markup Language (GML). Interface de serviços: componentes que, no lado cliente, interagem com usuários e no lado servidor, interagem com a aplicação de catálogo e servidores de dados.

27 Dicionários e catálogos 27 Serviços de registro: componentes que oferecem mecanismos para classificar, registrar, descrever, procurar, manter e acessar dados sobre recursos disponíveis. Incluem Web Registry Service (WRS). Serviços de visualização: componentes que oferecem suporte específico para visualização de dados geográficos na forma de mapas, perspectivas tridimensionais de terreno, imagens anotadas, etc. Incluem o Web Map Service (WMS), o Coverage Portrayal Service (CPS) e o Style Management Service (SMS). Serviços de dados: componentes que fornecem serviços básicos de acesso a dados geográficos. Incluem o Web Object Service (WOS), o Web Feature Service (WFS), o Sensor Collection Service (SCS), o Image Archive Service (IAS) e o Web Coverage Service (WCS). Serviços de processamento: componentes que operam sobre dados geográficos e fornecem serviços especiais às aplicações. Incluem serviços de dicionários geográficos. Figura 4 Componentes do OpenGIS Services Framework

28 Dicionários e catálogos Geospatial Web Services Architecture O OSF foi desenvolvido independentemente da arquitetura de protocolo para Web services do W3C. Somente recentemente, uma série de propostas de especificações coletivamente chamada de OpenGIS Web Service 2 Initiative, definiram interfaces que seguiam os padrões W3C. A OGC também iniciou uma experiência para testar o conceito de Web Geo-espacial Semântica. A arquitetura OGC Web Services (OWS) é uma arquitetura orientada a serviço, com todos os componentes fornecendo um ou mais serviços para outro serviço ou clientes. Essa arquitetura é baseada nos conceitos fundamentais de provedor e consumidor de serviço dentro de um sistema computacional distribuído. Trata, também, de interações entre componentes definindo requisições se serviço (service requests), respostas de serviços (service responses) e exceções ocorridas nas requisições (service exceptions). De acordo com Whiteside [20], definimos: um serviço é uma parte distinta de funcionalidade que é fornecida por uma entidade através de interfaces; uma interface é um conjunto nomeado de operações que caracterizam o comportamento de uma entidade; uma operação é uma especificação de uma transformação ou consulta que um objeto pode ser solicitado a executar. A operação tem um nome e listas de dados de entrada e saída. As OGC Web service interfaces utilizam padrões abertos e fornecem algumas poucas operações estáticas por serviço. Formatos de codificação de dados e linguagens padrões baseados em XML são utilizados em muitas transferências de dados entre clientes e servidores. Serviços fracamente organizados em quatro camadas, como mostra a Figura 5. A camada de serviços de gerenciamento de informação contém adaptadores que encapsulam fontes de dados. Os serviços nessa camada normalmente incluem algum processamento sobre os dados recuperados. Por exemplo, WMS, WCS, e WFS podem executar transformação de coordenadas e

29 Dicionários e catálogos 29 conversão de formatos. A camada de processamento de serviço contém serviços projetados para o processamento dos dados. A camada de serviços de aplicação contém serviços projetados para suportar clientes, especialmente clientes magros como Web browsers. Figura 5 Camadas de serviços na arquitetura OWS OGC Catalogue Service 2.0 A especificação OGC Catalogue Service (CS) 2.0 define interfaces que devem estar disponíveis em aplicações de catálogo de metadados sobre dados e serviços geográficos. Define operações para consulta e manutenção de metadados, localização e recuperação de recursos 6 de dados e serviços e controle de sessão. Para auxiliar no processo de consulta dos metadados o CS traz, ainda, a especificação de uma linguagem de consulta de metadados baseada na sintaxe SQL. Toda a especificação é extensível de modo a acomodar heterogeneidade de ambientes e variedade de áreas de conhecimento. A especificação OGC CS apresenta um conjunto completo de operações de catálogo. Um serviço de catálogo para ser compatível com a OGC CS 2.0 deve implementar ao menos um subconjunto das operações de interface. Assim 6 Um recurso de um dado ou serviço geográfico é o local onde está armazenado o dado geográfico ou o ponto de acesso ao serviço. No caso de dados geográficos, o recurso é o recipiente do dado.

30 Dicionários e catálogos 30 um serviço de catálogo poderá implementar operações de consulta, outro poderá permitir consulta e atualização de metadados, outro ainda poderá implementar consultas em federações de catálogos e assim por diante. Figura 6 Arquitetura interna de um serviço de catálogo A Figura 6 ilustra a arquitetura interna do serviço de catálogo proposto. Além da interface, o esquema apresenta os componentes internos do serviço. A consulta ou a manutenção de metadados se faz por meio das interfaces de catálogo OGC. Nesse caso o serviço de catálogo irá utilizar seu próprio repositório de metadados ou desviará a operação para outro serviço de catálogo, como em uma federação de serviços. A recuperação de recursos de informação ocorre quando o recurso não está disponível ao cliente via rede e pode ser feito por meio de interfaces OGC ou proprietárias. O conjunto completo das operações de um serviço de catálogo é: Interface de serviço de catálogo getcapabilities retorna metadados sobre o próprio serviço de catálogo. Interface de consulta query procura no conjunto de metadados disponível (local ou em outros serviços) aqueles que atendam à consulta definida pelo usuário e retorna ao cliente um conjunto contendo referências aos dados e serviços descritos pelos metadados selecionados. Opcionalmente, o conjunto resultado poderá conter também metadados selecionados na consulta.

31 Dicionários e catálogos 31 present retorna metadados selecionados referentes a dados previamente selecionados por uma consulta. describerecordtype retorna a definição de tipo para metadados. getdomain retorna valores válidos para algum metadado. Interface de transação initialize inicia uma transação. close encerra uma transação. status retorna o estado atual da transação. cancel termina uma transação previamente iniciada. Interface de gerenciamento transaction executa um conjunto especificado de operações de inclusão, alteração e atualização de metadados. harvestrecords carrega no repositório de metadados um conjunto de metadados de uma origem especificada. Interface de intermediação. order retorna um dado ou endereço de serviço identificado registrado no catálogo mas não acessível ao usuário. A especificação define, ainda, um conjunto de metadados mínimo como retorno de consultas para favorecer a interoperabilidade entre aplicações de diferentes características e ambientes. A Tabela 7 mostra a lista desses elementos utilizando a sintaxe Dublin Core (ISSO 15836). Elemento dc:title dc:creator dc:subject Um nome dado ao recurso Descrição Uma entidade responsável por produzir o conteúdo do recurso Um tópico do conteúdo do recurso É o lugar onde uma taxonomia de classificação poderia ser utilizada dct:abstract dc:publisher Um resumo do conteúdo do recurso Uma entidade responsável por tornar o recurso disponível Tabela 6 Conjunto de metadados mínimo

32 Dicionários e catálogos 32 Elemento dc:contributor dc:date dc:type dc:format dc:identifier dc:source dc:language dc:relation dct:spatial Descrição Uma entidade responsável por fazer contribuições ao conteúdo do recurso Data de criação ou atualização Natureza do conteúdo do recurso Manifestação física ou digital do recurso Identificador não ambíguo em um contexto Referência a um recurso de origem Língua do conteúdo do recurso Referência a recursos relacionados Extensão espacial do conteúdo do recurso dc:rights Direitos sobre o conteúdo do recurso Tabela 7 Conjunto de metadados mínimo (cont.) 2.3. Dicionários geográficos Exemplos de dicionários geográficos O sistema mais comum para identificação de objetos geográficos é a atribuição de um nome para cada objeto. Essa forma de referência geográfica é normalmente utilizada por muitos dicionários geográficos. Eles contém listas de nomes de objetos geográficos, suas respectivas localizações geográficas e outras informações descritivas. Muitos Atlas possuem uma seção de dicionário geográfico para auxiliar na localização das páginas que fazem referência a um nome específico. Dicionários geográficos disponíveis na Web têm sido desenvolvidos para atender às necessidade de sistemas de informação. Eles armazenam nome, tipo, coordenadas que representam o objeto, e uma área administrativa que contém o objeto para cada objeto. Eles também oferecem serviços para manipulação dos dados armazenados. A seguir, são apresentadas descrições breves de alguns dicionários geográficos disponíveis na Web.

33 Dicionários e catálogos 33 Getty Thesaurus of Geospatial Names (TGN) 7 É um vocabulário estruturado de abrangência mundial com cerca de 1,3 milhões de nomes e objetos geográfico desenvolvido pelo Getty Research Institute. Tem o objetivo de auxiliar a criação de catálogos de arte e literatura de arquitetura. Para cada objeto, o TGN possui um identificador único, nome preferido, um conjunto de classificações obtido do Art Architecture Thesaurus (AAT), nomes alternativos, localização geográfica, entre outros. U. S. Geographic Names Information System (GNIS) 8 Desenvolvido pelo U. S. Geological Survey (USGS) em cooperação com o U.S. Board on Geographic Names (BGN), contém informações sobre cerca de 2 milhões de objetos geográficos culturais e físicos, atuais e históricos dos Estados Unidos e de seus territórios. Alguns dos atributos mantidos são a localização geográfica, nome oficial, classificação segundo tipos definidos pelo BGN, entre outros. GEOnet Names Server (GNS) 9 Desenvolvido pela National Geospatial-Intelligence Agency (NGA), possui cerca de 4 milhões de objetos geográficos com 5,5 milhões de nomes provenientes da NGA e BGN com abrangência mundial. Alguns atributos mantidos para cada objeto são identificador único, nome oficial, região, coordenadas geográficas classificação segundo o BGN, entre outros. Alexandria Digital Library Gazetteer (ADL Gazetteer) 10 Desenvolvido no contexto do projeto Alexandria Digital Libray da Universidade da Califórnia em Santa Bárbara, possui cerca de 5.9 milhões de nomes provenientes do GNIS, GNS e outros dicionários, classificados segundo o ADL Feature Type Thesaurus (ADL FTT). Mantém para cada entrada um identificador único, nome oficial, nomes alternativos, classificação segundo o ADL FTT, coordenadas geográficas, descrição, entre outros

34 Dicionários e catálogos Classificação de objetos geográficos Um objeto é uma abstração de um fenômeno do mundo real e um objeto geográfico é um objeto associado a uma localização sobre a superfície terrestre [18]. Um objeto geográfico representa um lugar, tal como a cidade do Rio de Janeiro. No jargão familiar da Ciência da Computação possui um atributo especial que descreve sua posição na superfície da terra, usando um dado sistema de geo-referenciamento (Coordinate Reference System CRS). São normalmente classificados por tipos como, por exemplo, baías, rios, cidades, etc. que por sua vez são organizados de acordo com alguma característica como, por exemplo, rios e riachos são objetos hidrográficos e cidades e estados são unidades administrativas. Dados geográficos como, por exemplo, mapas e imagens de sensoriamento remoto, normalmente se referem a um conjunto de objetos geográficos. Atributo Abrev. Descrição Scope Note SN Descrição do significado do conceito Use USE o termo que se segue ao símbolo é o termo preferido quando é utilizado como sinônimo ou quase-sinômino 11 Use For UF O termo que se segue ao símbolo não é o termo preferido quando é utilizado como sinônimo ou quase-sinômino Top Term TT O termo que se segue ao símbolo é o termo mais geral ao qual o termo anterior ao símbolo pertence Broader Term BT o termo que se segue ao símbolo é um termo de significado mais amplo do que o termo anterior ao símbolo Narrower Term NT o termo que se segue ao símbolo é um termo de significado mais específico do que o termo anterior ao símbolo Related Term RT o termo que se segue ao símbolo é um termo associado ao termo anterior ao símbolo mas não é um sinônimo ou quase-sinônimo Tabela 8 Relacionamentos entre conceitos de um tesauro 11 Um quase-sinônimo é um termo com significado semelhante porém mais abrangente, por exemplo, rio pode ser um quase-sinônimo de riacho.

35 Dicionários e catálogos 35 Um tesauro [9] é o vocabulário de uma linguagem controlada de indexação, formalmente organizada, de tal forma que os relacionamentos entre termos são feitos explícitos. São utilizados por dicionários geográficos para classificar suas entradas. Um tesauro usualmente fornece seis tipos de propriedades para cada termo (Tabela 8), cinco das quais expressam relacionamentos entre termos e uma é a descrição do significado do termo. O ADL Gazetteer Feature Type Thesaurus (FTT) é o resultado da mistura de vários vocabulários de classificação de vários dicionários geográficos. O FTT versão 2.0 de julho de 2002 contém perto de 200 termos e 3000 relacionamentos. A fig mostra um fragmento desse tesauro ilustrando a hierarquia entre os termos. regions. agricultural regions. biogeographic regions.. barren lands.. deserts.. forests... petrified forests... rain forests... woods.. grasslands.. habitats.. jungles.. oases.. shrublands.. snow regions.. tundras.. wetlands regions (cont.). climatic regions. coastal zones. economic regions. land regions.. continents.. islands... archipelagos.. subcontinents. linguistic regions. map regions.. chart regions.. map quadrangle regions.. UTM zones Figura 7 Fragmento da hierarquia de termos do ADL Gazetteer Feature Type Thesaurus Padrões para dicionários geográficos Da mesma forma que catálogos utilizam especificações padrões para permitir interoperabilidade de aplicações e compartilhamento de dados,

36 Dicionários e catálogos 36 dicionários também se beneficiam de padrões internacionalmente aceitos. O comitê técnico ISO/TC211, Geographic Information/ Geomatic publicou um padrão para dicionários geográficos, o ISO 19112:2003 Spatial Referencing by Geospatial Identifiers, que define um esquema conceitual de dados (Tabela 9) e linhas gerais para a descrição de sistemas de referenciamento indireto. O ADL Gazetteer Content Standard suporta descrições de dados geográficos bastante ricas que vão muito além de alguns dicionários geográficos tradicionais. A Tabela 10 contém as principais seções do ADL Standard, que pode ser subdividido em subseções para codificar informações mais detalhadamente. Por exemplo, streetaddresssection é dividido em streetaddress, city, stateprovince, postalcode e country. Attribute Comment geospatial identifier alternative identifiers name type description position temporal extent geospatial extent administrator parent child a unique identifier for the feature taken from a given identifier space one or more alternative identifiers the preferred name for the feature the type of the feature, typically taken from a feature type thesaurus a description of the feature coordinates of a representative point of the feature a description of the temporal extension of the feature a description of the geospatial extension of the feature organization responsible for maintaining the feature s name identifier of the parent feature of which the entry is a subdivision identifiers of the features that the entry is a parent Tabela 9 Alguns atributos selecionados do esquema conceitual da ISO 19112

37 Dicionários e catálogos 37 Attribute Comment featureid featurename classsection codesectiontype spatiallocation streetaddresssection relatedfeature description featuredata featurelink supplementalnote entrymetadata unique identifier for the feature the names for the feature the primary type of the feature the code associated with the feature the map location of the feature the street address of the feature relationships of the feature with other features a short narrative description of the feature data about the feature, such as population or elevation website which provides information on the features note explaining unusual circumstance of the feature documents about entry and modification dates Tabela 10 Alguns atributos selecionados do ADL Gazetteer Content Standard O Open GIS Consortium desenvolveu um padrão para serviços de dicionários geográficos [22] para acesso distribuído. A interface de serviço especifica quatro operações que podem ser solicitadas por um cliente e executadas pelo serviço de dicionário. GetCapabilities: permite que um cliente recupere metadados sobre o service de dicionário sendo oferecido. DescribeFeatureType: permite que um cliente obtenha um esquema XML descrevendo um objeto geográfico. GetFeature: permite que um cliente obtenha instâncias de objetos geográficos. Além disso, o cliente pode escolher os atributos a recuperar e condições de seleção de objetos. GetGMLObject: permite ao cliente obter instâncias através de referências aos identificadores de objetos geográficos.

38 Dicionários e catálogos Alexandria Digital Library Gazetteer A Alexandria Digital Library (ADL) é uma biblioteca digital distribuída contendo coleções de materiais geo-referenciados. O projeto visa modelar, prototipar e avaliar arquiteturas de bibliotecas digitais aplicações de dicionários geográficos, aplicações de educação e componentes de software. O ADL Gazetteer é um dicionário geográfico, disponível via Web, que utiliza a ADL como infra-estrutura. Oferece uma interface HTTP/XML para ser utilizada em aplicações geográficas. As entradas desse dicionário são classificadas segundo três tesauros independentes: ADL Feature Type Thesaurus (ADL FTT) É uma coleção de termos que classifica o tipo do objeto descrito por uma entrada do ADLGazetteer. Todas as entradas são classificados segundo o FTT. Nele existem termos hierarquicamente definidos como, por exemplo, canais e estruturas hidrográficas. O último é um subtipo do primeiro. Todas as entradas classificadas como canais são, também, uma estrutura hidrográfica. Diz-se que estrutura hidrográfica é o Broader term de canal. Entretanto, pode haver mais de uma hierarquia de conceitos admitida por um tipo. Tomemos o exemplo anterior do canal, segundo a visão apresentada um canal é um tipo de estrutura hidrográfica, mas poderíamos ainda pensar em uma outra classificação de objeto como dispositivos de transporte para a qual um canal estaria hierarquicamente subordinado, como uma espécie de dispositivo. Para acomodar esse conceito, uma vez que só é possível definir uma hierarquia no modelo do FTT, existem os Related terms. São todos os tipos que por alguma semântica se relacionam com o primeiro. Diz-se, então, que dispositivos de transporte é um Related term de canal. Gazetteer type terms of U.S. Geological Survey apenas algumas entradas são classificadas segundo esse dicionário U.S. Geospatial-Intelligence apenas algumas entradas são classificadas segundo esse dicionário

39 Dicionários e catálogos 39 Cada entrada do ADL Gazetteer descreve único lugar geográfico conceitual. Seus atributos e cardinalidades, são: um identificador String que identifica univocamente a entrada. É único dentro do dicionário, mas não universalmente único. Zero ou mais códigos Identifica o lugar em um esquema de código específico, namespace ou sistema. um status de lugar Status da existência do lugar, pode ser: former (o lugar não existe mais), current (o lugar existe) ou proposed (o lugar não existe, mas sua criação foi antecipada). um nome de exibição um ou mais nomes coordenadas da diagonal de um retângulo de contorno um ou mais footprints É uma aproximação, expressa em coordenadas de latitude e longitude, de uma região da superfície terrestre, coberta pelo lugar. Não precisa ser contínuo. zero ou mais classes Classifica o lugar conforme o dicionário utilizado. Zero ou mais relacionamentos Os atributos nome, footprint e classes são qualificados por quatro descritores: primary indica que o valor do atributo é oficial ou preferido former indica que o valor do atributo não existe mais current indica que o valor do atributo existe proposed indica que o valor do atributo ainda não existe, mas foi criado antecipadamente. As seguintes condições devem existir para cada entrada do dicionário: Exatamente um nome precisa ser marcado como primary. Exatamente um footprint precisa ser marcado como primary. Se houver classificação, ao menos uma delas precisa ser marcada como primary.

40 Dicionários e catálogos 40 Os nomes geográficos do dicionário podem ser consultados através de um serviço Web utilizando-se o protocolo ADL Gazetteer Service Protocol, versão Trata-se de um protocolo leve, sem estado, baseado em XML sobre HTTP. O protocolo suporta consulta ao dicionário (por nome de lugar, por área geográfica, por classe de objeto, por relacionamento entre nomes de lugares), recuperação de relatório padrão de nomes de lugares e download das entradas do dicionário. Os serviços oferecidos são: get-capabilities retorna um resumo de todos os recursos do dicionário: os tipos de serviços e consultas, o dicionário que o dicionário usa, etc. query retorna um relatório (padrão ou estendido) das entradas do dicionário selecionadas por uma consulta expressa em GQL (Gazetteer Query Language). download semelhante à query na seleção do tipo de relatório mas retorna todas as entradas do dicionário. Esses serviços são invocados enviando-se requisições HTTP POST, contento a descrição do serviço desejado codificada em XML, para uma URL que representa o ponto de acesso comum a todos os serviços. O Apêndice A apresenta o esquema XML utilizado na comunicação com dicionário pela Web. Uma consulta freqüente ao dicionário seria: Quais os objetos contidos em uma região geográfica específica?. O fragmento de código a seguir apresenta uma consulta ao dicionário, de acordo com o protocolo, buscando todos os objetos contidos na região geográfica de forma retangular cujas coordenadas da diagonal do retângulo são (latitude = -22,892, longitude = -43,26) e (latitude = -22,932, longitude = -43,203). 12

41 Dicionários e catálogos 41 <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" /> <gazetteer-service xmlns=" xmlns:gml=" version="1.2"> <query-request> <gazetteer-query> <footprint-query operator="within"> <gml:box> <gml:coordinates> , , , </gml:coordinates> </gml:box> </footprint-query> </gazetteer-query> <report-format>standard</report-format> </query-request> </gazetteer-service>

42 3 Arquitetura de software para catalogação automática de dados geográficos Este capítulo apresenta uma arquitetura de software para catalogação automática de dados geográficos. A seção 3.1 apresenta uma estratégia para geração automática de metadados. A seção 3.3 apresenta os requisitos de uma arquitetura de software, baseada em agentes, para catalogação automática. A seção 3.4 apresenta o detalhamento dos componentes responsáveis pela geração da descrição. Por fim, a seção 3.5 apresenta o esquema de metadados utilizado para armazenamento de metadados e os componentes responsáveis por distribuir essa descrição pelo esquema Estratégia de catalogação Propomos uma estratégia que combina um dicionário geográfico com um catálogo de metadados. Mostraremos como utilizar o tesauro do dicionário para classificar dados geográficos e como utilizar entradas do dicionário para descrever dados geográficos. Seja GA um dicionário geográfico e assuma que cada entrada E em GA, representando um objeto geográfico F, tem uma representação geo-refernciada geo(e) de uma localização de F e um type(e) para E, cujo valor é um termo extraído do tesauro I[GA]. Seja MC um catálogo de metadados geográficos e assuma que cada entrada C em MC, representando um dado geográfico R, possui uma representação geo-referenciada geo(c) da área coberta por R e uma descrição scale(c) da escala de geo(c). Argumentamos que: Q1. I[GA] pode ser estendido para prover também uma classificação para entradas de catálogo, isto é, para prover um type(c) para C.

43 Arquitetura de software para catalogação automática de dados geográficos 43 Q2. Uma descrição desc(c) de C pode ser gerada relacionando-se C às entradas do dicionário de maneira adequada. Intuitivamente, assumindo que um dado geográfico R cobre uma área na superfície terrestre, podemos descrever R por uma coleção de objetos que ocorrem nessa área. Utilizamos somente os objetos cujos tipos são consistentes com a interpretação pretendida de R ou cujas extensões são menores do que a escala de R. Além disso, o tipo do objeto deve fornecer suficiente indicação se a escala do objeto é compatível com a escala de R. Por exemplo, seja R um dado. Se R deve ser interpretado como um mapa político, então R deve ser relacionado com cidades e divisões políticas de uma dada área. Dependendo da escala do mapa, somente cidades acima de determinada população devem, na verdade, ser incluídas. Se R deve ser interpretado como um mapa hidrográfico relacionamo-no com rios e riachos. Mais ainda, se o mapa possui uma grande escala, utilizamos somente os rios e suprimimos os riachos. Como um terceiro exemplo, se R é uma imagem de satélite de uma dada área, então R potencialmente representa todos os objetos que ocorrem na área. Entretanto, objetos cujas extensões são menores do que a resolução de R, não devem ser relacionados a R. Em geral, sugerimos: a. classificar os dados geográficos também utilizando I[GA]; b. indicar a escala que é compatível com cada termo em I[GA]. Isso é formalizado com uma função s: I[GA] R* que mapeia cada termo de I[GA] em um número Real não negativo. Para cada t I[GA], se s(t)>0, interpretamos s(t)=n como indicação de que todos os objetos do tipo t são compatíveis com a escala 1:n, ou menores (no sentido de que podem ser representadas naquela escala). Se s(t)=0, interpretamos s(t) como indicação de que t pode ser utilizada para classificar dados geográficos.

44 Arquitetura de software para catalogação automática de dados geográficos 44 Como um exemplo, considere o fragmento do ADL Feature Type Thesaurus mostrado na Figura 8 (a). Podemos então definir: S( creek )= para indicar que objetos do tipo creek devem somente ser representados em escalas 1: ou menores; S( hydrographic features )=0 para indicar que o termo hydrographic features podem ser utilizados para classificar dados. Em certas situações, a função s: I[GA] R* pode ser parcialmente calculada a partir de outros atributos de termos do tesauro do dicionário. Por exemplo, se cada termo t sob streams possui um atributo w indicando a largura do rio que é classificado como t, então o valor w para t pode ser utilizado para definir s(t). Para a questão Q2, primeiro definimos que uma entrada E do dicionário, representando um objeto geográfico F, é relevante para uma entrada C do catálogo, representando um dado R, se e somente se: geo(e) e geo(c) são relacionadas por um dos relacionamentos topológicos usuais toca, dentro, cruza, superpõe-se [1]; Type(E) é compatível com scale(c). Definimos então desc(c) como o conjunto de pares (E,r) tais que E é relevante à C e geo(e) e geo(c) são relacionados por um relacionamento topológico r. Alguns dicionários geográficos também incluem o conceito de lugar conhecido, tal como uma atração turística, uma importante cidade, etc. [13]. Se o dicionário adotado implementa esse conceito, podemos expandir a noção relevância previamente definida para incluir lugares famosos como uma informação importante. Por exemplo, considere uma imagem de satélite da cidade de Friburgo, a qual se situa a noroeste da cidade do Rio de Janeiro.

45 Arquitetura de software para catalogação automática de dados geográficos 45 Então, em vez de somente associar a imagem com a cidade de Friburgo, podemos também indicar que a imagem cobre uma área a noroeste da cidade do Rio de Janeiro, que é um lugar conhecido. Note que ao relacionarmos lugares conhecidos com recursos de informação, adotamos relacionamentos direcionais a norte de, a sul de, a leste de, etc. ou relacionamentos qualitativos, tal como perto. Como um exemplo da geração de desc(c), suponha que adotamos o ADL Gazetteer e o ADL Feature Type Thesaurus. Considere um fragmento de imagem da cidade do Rio de Janeiro, retirada do website Brasil visto do espaço 13 [14], mostrado na Figura 8. Essa imagem será processada da seguinte forma: 1. Extrair os parâmetros de geo-referenciamento do dado geográfico. Nesse caso, o fragmento de imagem é consistente com a escala 1: e tem como retângulo de borda definido pelo par de coordenadas ((43 o 15 W, 22 o S), (43 o W, 23 o S)). 2. Assuma que o usuário escolha relacionar o fragmento de imagem com hydrographic features, um termo do ADL FTT que, em nosso exemplo, pode ser usado para classificar dados geográficos. 3. Como as entradas do ADL Gazetteer não têm nenhuma informação de escala, ela será ignorada. 4. Acesse o ADL Gazetteer, usando os parâmetros extraídos no passo 1 e os termos ADL FTT sob hydrographic features, selecionado no passo 2. A consulta retornará nove entradas, das quais as três primeiras são: 4.1. Objeto ( Rodrigo de Freitas, Lagoa Brazil, lakes, within ) 4.2. Objeto ( Comprido, Rio Brazil, streams, within ) 4.3. Objeto ( Maracanã, Rio Brazil, streams, within ) 5. Armazene o resultado da consulta como uma descrição do dado, isto é, como uma lista de pares (N,r), onde N é o objeto geográfico recuperado no passo 4 e r é o relacionamento topológico entre a imagem e N (nesse exemplo r é within ). 13

46 Arquitetura de software para catalogação automática de dados geográficos 46 Esse breve exemplo ilustra algumas das idéias básicas desse trabalho. Primeiro, o uso do dicionário para também classificar dados geográficos, evita adotar um segundo esquema de classificação, tal como, ISO19115 Topic Categories [10]. Entretanto, requer a definição de uma função de compatibilidade s: I[GA] R*. hydrographic features.... lakes. seas.. oceans... ocean currents... ocean regions. streams.. rivers... bends (river)... rapids... waterfalls.. springs (hydrographic) c a b Figura 8 Um fragmento do ADL Feature Type Thesaurus e uma imagem da cidade do Rio de Janeiro Segundo, uma descrição útil de um dado geográfico R pode ser criada como uma lista de pares (N,r), onde N é um objeto geográfico e r é o relacionamento topológico entre R e N, obtido pela consulta ao dicionário. Além disso, a lista contém somente objetos cujos tipos são compatíveis com a escala de R Requisitos da arquitetura Para compreendermos o processo de catalogação automática e identificarmos os requisitos de software necessários, consideremos a situação de uma empresa que recebe, periodicamente, imagens de satélite e deseja armazená-las de modo a poder selecionar aquelas que são adequadas a um projeto. Freqüentemente, imagens de satélite são gravadas em arquivos utilizandose padrões de compactação como, por exemplo, o GeoTIFF que permitem

47 Arquitetura de software para catalogação automática de dados geográficos 47 anexar aos dados da imagem, contidos no arquivo, as coordenadas geográficas da região na superfície terrestre coberta pela imagem. Tais imagens podem ser obtidas de várias fontes e serem utilizadas em vários setores da empresa. Por exemplo, poder-se-ia obter imagens da EMBRAPA 14 e do LANDSAT 15 para um departamento que desejasse analisar recursos hidrográficos. Outro departamento, no entanto, poderia estar interessado nos municípios cobertos pelas mesmas imagens. Podemos, então, conforme a seção 3.1, definir um algoritmo para catalogação automática de dados geográficos: catalogação de dados geográficos enquanto (interrupção não for solicitada) faça Obter novo dado; se houver novo dado então Extrair metadados do seu conteúdo; Criar descrição parcial; Classificar dado; para cada dicionário geográfico configurado faça Buscar metadados relacionados com o dado; Eliminar metadados incompatíveis com escala e classificação do dado; Acrescentar metadados à descrição; se houverem metadados provenientes dos dicionários então Catalogar dado; Para implementar o algoritmo propomos dois agentes de software. O primeiro deles, o agente rastreador (CrawlingAgent), é responsável por inspecionar repositórios de dados, buscando novos dados a serem catalogados. Uma vez encontrados, o agente extrai metadados do seu recipiente 16 e, em seguida, envia uma mensagem a outro agente, o agente catalogador, Recipiente de um dado é a sua unidade elementar de armazenamento. Dados são freqüentemente armazenados em arquivos ou registros de bancos de dados.

48 Arquitetura de software para catalogação automática de dados geográficos 48 solicitando a catalogação da imagem. Não limitamos o agente rastreador a somente uma instância. Podem ocorrer situações em que várias instâncias independentes estejam ativas para garantir robustez e flexibilidade ao processo. Poderíamos, por exemplo, configurar um agente para buscar as imagens geradas pela EMBRAPA e outro para as do LANDSAT. O agente catalogador (CataloguingAgent) é o agente responsável por buscar, em um dicionário geográfico, objetos relacionados ao dado geográfico e, caso seja bem sucedido, armazená-los no catálogo. Periodicamente, o agente verifica, em um canal de comunicação comum, se existem novos dados a serem catalogados. Em caso afirmativo, recupera suas coordenadas geográficas e extrai de dicionários objetos relacionados às coordenadas. Com base nos dados dos dicionários, cria descrições dos dados e as armazena no catálogo. Esperamos que um processo de catalogação manipule somente um catálogo, portanto, sugerimos somente uma instância do agente catalogador. repositories:list gazetteers:list 1:*[for each repository] 1.4:*[for each dataset] 1.1: repository:=get(index) 2.1: gazetteer:=get(index) Assinchronous communicatio 1.5: catalog(datasetdesc) 3: put(datasetdesc) :Catalog :CrawlingAgent :CataloguingAgent 1.2: datasetidlist:=listuri 1.3: datasetdesc:=getdescription(datasetid) 2:*[for each gazetteer] 2.3: filterdescription(featurelist) 2.2: featurelist:=getdescription(datasetdesc) :Repository :Gazetteer Figura 9 - Arquitetura de agentes para o processo de catalogação Outros catálogos podem ser alimentados utilizando-se outros processos de catalogação, cada qual com seu próprio conjunto de agentes e configurações específicas. Um esquema dessa arquitetura é mostrado na Figura 9. Os repositórios (Repository), na figura, são os locais nos quais se encontram novos recipientes de dados geográficos. Note que não está

49 Arquitetura de software para catalogação automática de dados geográficos 49 representado no esquema o processo para captura desses dados do provedor. Por exemplo, se a EMBRAPA disponibiliza as imagens em algum endereço na internet e os arquivos são transferidos para o cliente, esse procedimento não está representado. O local em questão é o local final dos arquivos de imagens que os agentes irão consultar. Os dicionários (Dictionary) são os dicionários geográficos dos quais serão obtidos objetos geográficos relacionados ao dado. Pelo exposto até aqui podemos listar os seguintes requisitos funcionais para um software de catalogação automática: 1. Permitir a criação de processos de catalogação informando: repositórios, dicionários, catálogo e um identificador para o processo de catalogação; 2. Permitir a alteração das configurações dos processos de catalogação; 3. Permitir remover configurações de processos de catalogação; 4. Permitir armazenar as configurações dos processos de catalogação; 5. Permitir iniciar e interromper cada processo independentemente; 6. Exibir uma lista de falhas ocorridas nos processos de catalogação; 7. Exibir o estado dos processos de catalogação; Propomos, ainda, alguns requisitos não funcionais para flexibilizar o processo como um todo e garantir o bom desempenho dos equipamentos hospedeiros dos agentes. Uma atenção especial deve ser dedicada à questão do desempenho. A natureza da operação de catalogação pode produzir grande carga de processamento dos agentes. Para minimizar os efeitos do consumo excessivo de recursos do ambiente computacional os agentes devem ser capazes de interromper seu processamento por alguns instantes em intervalos regulares de tempo ou mesmo identificar períodos de ociosidade dos recursos e aproveitá-los. Um formato de imagem frequentemente utilizado na geração de imagens geográficas é o GeoTIFF, como já mencionado. Entretanto, podem ocorrer situações onde outros formatos para codificação de dados geográficos são

50 Arquitetura de software para catalogação automática de dados geográficos 50 utilizados, por exemplo o ESRI Shapefile. É desejável que o software possa ser facilmente adaptado a novos padrões de arquivos contendo dados geográficos. Na arquitetura apresentada anteriormente os Agentes Rastreadores têm o papel de procurar por novos dados em repositórios previamente especificados no processo de catalogação. Tais repositórios podem estar disponíveis sob vários protocolos. Poderiam ser diretórios no sistema de arquivos, sites FTP, URL s acessadas através de conexões HTTP, ou outro tipo de repositório qualquer. Deseja-se flexibilizar os tipos de repositórios com os quais o agente pode se comunicar. Finalmente, analogamente aos repositórios de dados, o software deveria poder se adaptar a diferentes dicionários, com protocolos de comunicação diferentes. Note que esses três últimos requisitos não se tratam de adaptação dinâmica, mas sim de conferir ao software uma arquitetura flexível o suficiente de modo que possa ser facilmente modificado para se compatibilizar com os novos componentes externos Processo de catalogação A Figura 10 apresenta um esquema dos componentes responsáveis pelo processo de catalogação. Podemos definir, de acordo com a seção 3.2, que um processo de catalogação (CataloguingProcess) possui as seguintes propriedades: nome (name), estado (state), coleção de repositórios (repositories), coleção de dicionários (dictionaries), catálogo (catalog) e repositório de falhas (fails). Ao iniciar-se a execução de um processo de catalogação (operação start( )), os agentes são criados e configurados. Os repositórios podem ser distribuídos entre vários agentes catalogadores, no entanto, cada agente catalogador deve consultar todos os dicionários. A cooperação entre eles ocorre na concorrência para catalogar os novos dados geográficos identificados. Para podermos distribuir a consulta aos dicionários entre vários agentes seria preciso definir

51 Arquitetura de software para catalogação automática de dados geográficos 51 regras de interação entre os catalogadores de modo a garantir que, para cada novo dado todos os dicionários seriam consultados e que seria possível identificar quando isso teria ocorrido, permitindo, assim, a catalogação do dado. Essa coordenação, no entanto, não será tratada nesse trabalho. Ao menos um agente de cada tipo deve ser criado, mas a arquitetura não limita o número máximo. Há que se estudar cada situação para optar por um conjunto adequado de agentes e implementar o algoritmo apropriado. No protótipo foi implementado apenas um agente de cada tipo. SubjectImp Serializable CataloguingProcess Runnable <<abstract>> Agent +commhandler <<abstract>> interface Comm MsgChannel +start:void +stop:void +reporterror:void dictionaries:string[][] catalog:string fails:string repositories:string[] name:string state:string 2..* CataloguingAgent +sendmessage:void +readmessage:messag +agentbehavior:void CrawlingAgent LocalComm 0..* contains <<abstract>> Message query searches NewDataset 1..* DescriptionSourc <<abstract>> Dictionary +getdescription:datasetdescriptio +catalog +fails +tempcatalog +tempcatalog <<abstract>> interface Catalog +put:datasetdescription +get:datasetdescription +catalog +fails 1..* DescriptionSourc <<abstract>> Repository +listuri:string[] +getdescription:datasetdescriptio Figura 10 - Processo de catalogação automática Um catálogo temporário comum a todos os agentes serve para identificar os dados que ainda não foram catalogados, mas já foram carregados, evitandose o seu reprocessamento. Cada agente rastreador solicita em intervalos regulares de tempo a lista dos identificadores de recipientes de dados existentes nos repositórios (operação Repository->listURI( )). Cada recipiente contém um dado geográfico a ser descrito e catalogado. O identificador do recipiente assumirá o papel de identificador da descrição do dado no sistema. Os identificadores que não

52 Arquitetura de software para catalogação automática de dados geográficos 52 existirem no catálogo, nem no repositório temporário ou de falhas são considerados novos e os metadados do conteúdo dos respectivos recipientes são capturados (operação Repository->getDescription(String uri)). Uma descrição parcial do dado é criada, a partir dos metadados capturados, e enviada (operação CrawlingAgent->sendMessage(Message message)) ao agente catalogador em uma mensagem do tipo novo dado (NewDataset). Entre outras informações extraídas do conteúdo do arquivo estão as coordenadas geográficas da região na superfície terrestre coberta pela imagem. Cada agente catalogador solicita continuamente ao canal de comunicação uma mensagem do tipo novo dado (operação CataloguingAgent-> readmessage(new NewDataset( ))). Havendo mensagem, o agente consulta cada um dos dicionários para recuperar objetos geográficos contidos na área coberta pela imagem. Não ocorrendo nenhuma falha, os objetos são incluídos na descrição do dado e esta é incluída no catálogo. Caso não exista nenhuma mensagem o agente interrompe o processamento e aguarda até que uma nova mensagem seja enviada. Uma falha ocorre quando não é possível recuperar nenhuma informação sobre um dado geográfico de um dicionário. Nesse caso, o dado é armazenado no repositório de falhas. Erros fatais detectados durante o processamento de qualquer agente são imediatamente reportados ao processo de catalogação (operação CataloguingProcess->reportError( )) que interrompe a execução de todos os agentes do processo (operação CataloguingProcess->stopAgents( )) e notifica os observadores do processo (operação CataloguingProcess->notifyObservers( ) do ancestral SubjectImpl de CataloguingProcess vide padrão Observer na seção 4.3). Alguns exemplos de erros são: endereço de serviço do dicionário inválido, repositório inválido, falha na comunicação de rede, catálogos inválidos, etc Geração de metadados A Figura 11 apresenta o esquema dos componentes envolvidos na geração automática de metadados.

53 Arquitetura de software para catalogação automática de dados geográficos 53 Existem dois tipos de fontes de descrição (DescriptionSource) de dados geográficos: o próprio recipiente do dado em um repositório (Repository) e dicionários geográficos (Dictionary). O procedimento de captura da descrição baseia-se em dois elementos abstratos: decodificador (Parser) e construtor (Builder). O decodificador é responsável por identificar os elementos de metadados tanto no recipiente do dado, quanto na resposta de uma consulta a um dicionário. Assumiremos, para facilitar o entendimento no momento, que tanto os metadados armazenados nos recipientes dos dados geográficos, quanto aqueles obtidos de um dicionário geográfico serão codificados em XML. O componente XMLParser, extensão do decodificador, implementa um algoritmo para identificação dos elementos XML. Caso fosse necessário interpretar metadados armazenados no formato GeoTIFF poderíamos criar um GeoTIFFParser que implementasse o algoritmo apropriado. Uma fonte de descrição pode possuir vários decodificadores de metadados. A escolha apropriada do decodificador, na geração de uma descrição, depende da identificação do formato no qual os metadados serão obtidos. Com a possibilidade de termos várias estratégias diferentes de decodificação, pela extensão do componente decodificador, obtemos flexibilidade na variedade recipientes e dicionários. Esse ponto é fundamental para que, como veremos na seção 4.6, possamos generalizar o mecanismo de catalogação automática para dados não geográficos. Um decodificador transforma os metadados obtidos de uma fonte de descrição em uma coleção de elementos de metadados (MetadataElement). Para informações codificadas em formato XML cada elemento de metadado representa uma tag com seu nome, valor e atributos e valores de atributos. A coleção também poderia representar metadados em recipiente GeoTIFF. Nesse caso, os atributos assumiriam valor nulo.

54 Arquitetura de software para catalogação automática de dados geográficos 54 Serializable <<abstract>> DescriptionSource <<abstract>> Dicionary url:string MetadataElement qname:string localname:string value:string uri:string attributes:attributes decodes metadata elements using 1..* DefaultHandle <<abstract>> Parser +parse:metadataelement[ uses +build:void +getdescription:datasetdescript <<abstract>> Builder organize desc using datasetdescription:datasetdescriptio XMLParser GeoTIFFParser RepositoryDescBuilde DictionaryDescBuilder <<abstract>> Repository organize desc using ISO19115ImageBuilder ISO19115ADLFeaturesBuilde +listuri:string[] +getdescription:datasetdescriptio Figura 11 - Recuperação de informações O segundo componente no processo de geração de metadados, o construtor, é responsável por receber uma coleção de elementos de metadados e os organizar em um esquema de metadados específico. Caso os metadados estejam sendo recuperados de um recipiente de dado geográfico, um construtor de descrição de recipiente (RepositoryDescBuilder) processa a coleção. Se estamos recuperando metadados de um dicionário geográfico, um construtor de descrição de dicionário (DictionaryDescBuilder) se encarrega da organização. Cada decodificador de fonte de descrição possui uma referência ao construtor associado à essa fonte, isto é, um XMLParser associado a um repositório possui um RepositoryDescBuilder e um XMLParser associado a um dicionário contém um DictionaryDescBuilder. Pode ocorrer que se deseje organizar as informações em mais de um tipo de esquema. Nesse caso, haveriam diferentes especializações do construtor. A Figura 11 apresenta construtores que utilizam somente o esquema de metadados definido pela ISO 19115, conforme exposto na seção O componente ISO19115ImageBuilder organiza metadados de recipientes e o

55 Arquitetura de software para catalogação automática de dados geográficos 55 ISO19115ADLFeaturesBuilder organiza metadados a partir de objetos recuperadas do ADL Gazetteer. Para obter metadados em um recipiente o agente rastreador informa ao repositório o identificador do recipiente (operação Repository-> getdescription(string identifier)). O repositório identifica o formato de codificação do recipiente, escolhe o decodificador apropriado, e solicita a ele a decodificação do conteúdo do recipiente (operação XMLParser-> parse(inputsource source)). O decodificador, ao final do seu processamento, solicita ao construtor para organizar os elementos de metadados (operação RepositoryDescBuilder-> build(metadataelement[ ] metadataelements). Ao final, o repositório solicita ao seu construtor a descrição resultante (operação RepositoryDescBuilder-> getdatasetdescription( )). Para obter metadados em um dicionário o agente catalogador informa ao dicionário a descrição parcial do dado obtida do seu recipiente (operação ADLGazetteer-> getdescription(datasetdescription datasetdescription)). O dicionário obtém da descrição as informações relativas às coordenadas geográficas e faz uma consulta ao repositório físico do ADL Gazetteer que recupere todos os objetos contidos na área geográfica do dado. A resposta da consulta é decodificada (operação XMLParser-> parse(inputsource source)) e enviada ao construtor para organização (operação DictionaryDescBuilder-> build(metadataelement[ ] metatadaelements)). Ao final, o dicionário solicita ao seu construtor a descrição resultante (operação DictionaryDescBuilder-> getdatasetdescription( )) Esquema de metadados A Figura 12 apresenta o esquema de metadados utilizado para armazenar a descrição de um dado geográfico e os componentes responsáveis por distribuir essa descrição pelo esquema. Os metadados de um dado geográfico são organizados segundo um esquema conceitual determinado pela norma ISO Segundo ela, um dado geográfico (DS_Dataset) pode ser uma imagem, um mapa ou até mesmo um simples objeto geográfico. Cada dado está associado a um conjunto de

56 Arquitetura de software para catalogação automática de dados geográficos 56 elementos de metadado (MD_Metadata) que o descreve. A norma unifica, portanto, os conceitos de dado geográfico e objeto geográfico utilizados na arquitetura de catalogação. Introduz, ainda, o conceito de agregação de dados (DS_Aggregate) que correlaciona dados geográficos afins. No nosso caso, definiremos que correlaciona o dado geográfico com os objetos geográficos obtidos dos dicionários. O agregado pode, também, estar associado a um conjunto de elementos de metadados para sua descrição. Foi utilizado, apenas, um subconjunto das estruturas de metadados definidas pela norma, suficiente para a compreensão da arquitetura, são elas: DS_Dataset, DS_Aggregate, DS_OtherAggregate, MD_Metadata, MD_SpatialRepresentation, MD_gridSpatialRepresentatin, MD_Georectified e GM_Point. Os componentes que não pertencem à ISO e apresentados no esquema são responsáveis por capturar os metadados e distribuí-los pelas estruturas da norma. Essa estratégia permite flexibilidade na alteração do esquema de metadados e até mesmo da forma de armazenamento. Podemos armazenar os metadados descritos pela ISO em um banco de dados orientado à objeto ou como instâncias de uma ontologia. As estruturas de dados definidas pela ISO são manipuladas por meio do componente OOISO19115GeoImage. Suas operações fornecem ao software de catalogação uma interface para armazenamento dos metadados. O componente OntISO19115GeoImage foi apresentado somente como ilustração de variações possíveis para armazenamento de metadados. Com ele pretendemos sugerir que os conceitos ISO poderiam ser traduzidos para uma representação em forma de ontologia permitindo armazenar os metadados em bancos de dados semânticos. A generalização desses dois componentes até DatasetDescription pretende apoiar o framework, de que falamos, para catalogação de dados não geográficos.

57 Arquitetura de software para catalogação automática de dados geográficos 57 Serializable DatasetDescription GeoImageDesc interface GeoImageInterface +aggregatedescription:vo identifier:string uri:string MultipleAggregation 0..* +subset 0..* +superset Serializable DS_Aggregate Serializable OOISO19115GeoImage +incrementdatasetcapacity:vo +aggregatedescription:void uri:string identifier:string name:string leftuppercornerpointx:double leftuppercornerpointy:double rightlowercornerpointx:doubl rightlowercornerpointy:doubl datasets:ds_dataset[] manipulates +composedof:ds_dataset[] 0..* 1..* +subset:ds_aggregate[] +partof +composedof +seriesmetadata:md_metadata OntISO19115GeoImage +aggregatedescription:void name:string leftuppercornerpointx:double leftuppercornerpointy:double rightlowercornerpointx:double rightlowercornerpointy:double datasets:ds_dataset[] 0..* +spatialrepresentationinfo Serializable DS_DataSet +has:md_metadata[] feature:string name:string leftuppercornerpointx:double leftuppercornerpointy:double rightlowercornerpointx:double rightlowercornerpointy:double datasets:ds_dataset[] Serializable MD_SpatialRepresentatio MD_GridSpatialRepresentation +numberofdimensions:int +axisdimensionproperties:md_dimension[ +cellgeometry:string +transformationparameteravailability:boole 0..* +series 0..* +describes DS_OtherAggregate 1..* +seriesmetadata 1..* Serializable MD_Metadata +featuretype:gf_featuretype +atributetype:gf_atributetype +identificationinfo:md_identification[] +fileidentifier:string +language:string +characterset:string +parentidentifier:string +hierarchylevel:md_scopecode +hierarchylevelname:string +contact:ci_responsibleparty +datestamp:date +metadatastandardname:string +metadatastandardversion:string +dataseturi:string +series:ds_aggregate -describes:ds_dataset +has MD_Georectified +checkpointavailability:boolean +checkpointdescription:string +cornerpoints:gm_point[] +cornerpoint:gm_point +pointinpixel:md_pixelorientationcode +transformationdimensiondescription:strin +transformationdimensionmapping:string Serializable GM_Point +x:double +y:double +cornerpoint 0..* +cornerpoints Figura 12 - Esquema de metadados

58 4 Implementação do GeoCatalog Esse capítulo apresenta o projeto detalhado do GeoCatalog, um protótipo de um software para catalogação automática de dados geográficos, como ilustração da arquitetura apresentada. O projeto foi elaborado de forma a gerar como subproduto um framework para catalogação automática de dados genéricos (dados geográficos ou não) cujas características serão descritas na seção 4.6. Assumimos as seguintes premissas de desenvolvimento: 1. Os dados geográficos são arquivos, contendo a descrição de uma imagem geográfica (um identificador e dois pares de coordenadas geográficas), em formato XML; 2. Os objetos relacionados à imagem são obtidos do ADL Gazetteer. 3. A interface de usuário é uma aplicação desktop desenvolvida em Java versão 1.5_ Não haverá comunicação remota entre os agentes. Todos os agentes envolvidos do processo de catalogação serão objetos em uma mesma aplicação. A seção 4.1, com base nos requisitos funcionais identificados na seção 3.3, apresenta a descrição dos casos de uso do software. A seção 4.3 apresenta o projeto detalhado dos componentes da interface de usuário. A seção 4.4 apresenta a implementação da operação de inicialização de um processo de catalogação e a infra-estrutura para a implementação dos agentes. A seção 4.5 apresenta os componentes responsáveis por capturar descrições de um dado geográfico. E, por fim, a seção 4.6 generaliza o projeto para se adaptar a qualquer tipo de dado.

59 Implementação do GeoCatalog Casos de uso O GeoCatalog utiliza o conceito de Área de Trabalho. Cada Área de Trabalho tem a função de repositório de configurações de processos de catalogação. Da mesma forma como softwares de edição de texto permitem abrir vários documentos em uma mesma instância de execução do editor, também é possível abrir várias Áreas de Trabalho para organizar convenientemente as configurações de catalogação. Cada processo poderá ser alterado, iniciado e interrompido independentemente uns dos outros. Isso significa que, enquanto um processo pode estar ativo, outro pode não estar. Nesse contexto, o diagrama de Casos de Uso da Figura 13 apresenta as funcionalidades disponíveis no GeoCatalog. Criar área de trabalh SystemBoundary Avrir área de trabalh Usuario Criar catalogado <<include>> Editar catalogado Excluir catalogado <<include>> Alterar dados Catalogar imagem Iniciar catalogado Parar catalogado <<include>> Obter descriçã Agente catalogado Carregar novas imagen Agente rastreado Figura 13 Diagrama de Casos de Uso A seguir, os quadros especificam cada um dos Casos de Uso identificados no diagrama.

60 Implementação do GeoCatalog 60 Caso de Uso: Criar área de trabalho Ator Primário: Usuário Pré-condições: Nenhuma Fluxo Normal 1 Usuário seleciona local do arquivo 2 Usuário Informa nome do arquivo 3 Usuário confirma operação 4 Sistema cria e abre a área de trabalho Fluxo Alternativo não há Caso de Uso: Abrir área de trabalho Ator Primário: Usuário Pré-condições: Nenhuma Fluxo Normal 1 Usuário seleciona o arquivo correspondente à área de trabalho desejada 2 Usuário confirma seleção 3 Sistema abre a área de trabalho selecionada Fluxo Alternativo: Área de trabalho já está aberta 1a Sistema informa que o arquivo já está aberto 1b Sistema retorna ao passo 1 do fluxo normal

61 Implementação do GeoCatalog 61 Caso de uso: Criar catalogador Ator Primário: Usuário Pré-condições: Área de trabalho aberta Fluxo Normal 1 Usuário escolhe solicita a inclusão de um novo processo 2 Sistema executa caso de uso Alterar Dados 3 Usuário solicita a salva da Área de Trabalho 4 Sistema salva Área de Trabalho Fluxo Alternativo: Existem locais onde os objetos serão procurados que não estão acessíveis 2a Usuário corrige o nome dos locais não acessíveis 2b Sistema retorna ao passo 3 do fluxo normal Fluxo Alternativo: Existem enciclopédias não acessíveis 2a Usuário corrige os dados de acesso às enciclopédias 2b Sistema retorna ao passo 3 do fluxo normal Fluxo Alternativo: O banco de dados não está acessível 2a Usuário corrige os dados de acesso ao banco de dados do catálogo 2b Sistema retorna ao passo 3 do fluxo normal

62 Implementação do GeoCatalog 62 Caso de uso: Editar catalogador Ator Primário: Usuário Pré-condições: Área de trabalho aberta Fluxo Normal 1 Usuário solicita a alteração dos parâmetros de um processo de catalogação 2 Usuário confirma alterações 3 Sistema salva área de trabalho Fluxo Alternativo: Existem locais onde os objetos serão procurados que não estão acessíveis 2a Usuário corrige o nome dos locais não acessíveis 2b Sistema retorna ao passo 3 do fluxo normal Fluxo Alternativo: Existem enciclopédias não acessíveis 2a Usuário corrige os dados de acesso às enciclopédias 2b Sistema retorna ao passo 3 do fluxo normal Fluxo Alternativo: O banco de dados não está acessível 2a Usuário corrige os dados de acesso ao banco de dados do catálogo 2b Sistema retorna ao passo 3 do fluxo normal

63 Implementação do GeoCatalog 63 Caso de uso: Alterar dados Ator Primário: Usuário Pré-condições: Um dos casos de uso Criar catalogador ou Editar catalogador iniciados Fluxo Normal 1 Usuário altera parâmetros de configuração do catalogador (diretórios de imagens, URL ADL, nome do arquivo para o catálogo e nome do arquivo para as imagens com falhas) 2 Usuário confirma informações Fluxo Alternativo: não há Caso de uso: Excluir catalogador Ator Primário: Usuário Pré-condições: Catalogador estar parado Fluxo Normal 1 Usuário seleciona catalogador 2 Usuário escolhe opção Remove process 3 Usuário confirma operação 4 Sistema salva área de trabalho Fluxo Alternativo: não há

64 Implementação do GeoCatalog 64 Caso de uso: Iniciar catalogador Ator Primário: Usuário Pré-condições: Catalogador corretamente configurado Fluxo Normal 1 Usuário seleciona o catalogador desejado 2 Usuário solicita a execução do catalogador Fluxo Alternativo: Há algum erro de configuração no catalogador 1a Usuário executa caso de uso Editar Catalogador 1b Sistema retorna ao passo 1 do fluxo normal Caso de uso: Parar catalogador Ator Primário: Usuário Pré-condições: Catalogador em execução Fluxo Normal 1 Usuário seleciona o catalogador desejado 2 Usuário solicita interrupção do catalogador Fluxo Alternativo: não há

65 Implementação do GeoCatalog 65 Caso de uso: Carregar novas imagens Ator Primário: Agente rastreador Pré-condições: Nenhuma Fluxo Normal 1 Para cada objeto no local configurado no catalogador como fonte de imagens 1.1 Agente obtém lista de arquivos disponíveis 1.2 Para cada arquivo Se o arquivo não estiver catalogado nem estiver na lista de arquivos com falhas e nem no catálogo temporário Agente carrega metadados da imagem Agente adiciona objeto ao catálogo temporário Agente envia mensagem Nova imagem para o Agente Catalogador com os metadados Fluxo Alternativo: Local fonte de objetos configurado no catalogador não está acessível 1.1a Agente solicita ao processo de catalogação a interrupção de todos os agentes 1.1b Sistema acusa erro de configuração

66 Implementação do GeoCatalog 66 Caso de uso: Catalogar imagem Ator Primário: Agente catalogador Pré-condições: Nenhuma Fluxo Normal 1 Para cada mensagem Nova imagem 1.1 Agente executa caso de uso Carregar anotações para a imagem enviada na mensagem 1.2 Agente salva objeto no banco de dados do catálogo 1.3 Agente retira imagem do catálogo temporário Fluxo Alternativo: Não há anotações disponíveis para a imagem 1.1a Agente salva objeto no banco de dados de falhas 1.1b Agente continua o processamento com a próxima mensagem Fluxo Alternativo: Não é possível salvar objeto no catálogo 1.2a Agente solicita ao processo de catalogação a interrupção de todos os agentes 1.2b Sistema acusa erro de configuração

67 Implementação do GeoCatalog 67 Caso de uso: Obter descrição Ator Primário: Agente catalogador Pré-condições: Os gazetteers terem sido corretamente configurados Fluxo Normal 1 Recupera coordenadas da imagem 2 Para cada gazetteer do catalogador 2.1 Recupera features contidas na área geográfica coberta pela imagem 2.2 Associa features à imagem Fluxo Alternativo: Gazetteer configurado no catalogador não está acessível 2.1a Agente solicita ao processo de catalogação a interrupção de todos os agentes 2.1b Sistema acusa erro de configuração 4.2. Padrão arquitetural da aplicação Arquitetura dos componentes do software O projeto utilizou o padrão arquitetural Model View Controller (MVC) que propõe a divisão funcional dos componentes do software em três pacotes: a. Modelo (model) componentes encarregados de executarem as regras de negócio e controle de estado da aplicação. b. Visão (view) componentes para interface de usuário. c. Controlador (controller) componentes que mediam a comunicação entre componentes dos dois primeiros grupos. (segundo esse padrão não deve haver comunicação direta entre um componente do modelo e outro da visão) Essa organização tem por finalidade aumentar a coesão dos componentes do software. Uma das suas principais vantagens é o aumento da flexibilidade nas manutenções, pois evita o entrelaçamento de procedimentos de regras de

68 Implementação do GeoCatalog 68 negócios com de interface de usuário. Se, por exemplo, houver necessidade de substituir os mecanismos de interface de usuário, somente os componentes do pacote visão deverão sofrer manutenção. Se, por outro lado, for necessário alterar regras de negócio, então, somente as classes do pacote modelo serão alteradas. Os componentes de controle desempenham o papel de ligação entre os outros dois pacotes e só serão alterados quando houver modificação na interface de comunicação da visão com o modelo. A Figura 14 mostra a divisão dos componentes do GeoCatalog segundo a arquitetura MVC. O pacote modelo foi dividido em duas partes para separar os componentes diretamente ligados com o processo de catalogação (pacote model) daqueles que controlam a aplicação, as áreas de trabalho e as configurações de processos (pacote appmodel). model +Parser +NewDataset +FileSystemDirectory +LocalFileCatalog +Builder +CrawlingAgent +DatasetSite +Dataset +InvalidDatasetSiteException +CataloguingAgent +AnnotationsBuilder +MemoryCatalog +InvalidDatasetException +CataloguingProcess +InformationSource +DatasetBuilder +Thesaurus +Catalog +FrameworkFactory +InvalidThesaurusException +FileSystemDirectoryTest appmodel +Workspace +Application +Document +CatAppImpl +WspImpl view +WspWindow +CatAppWindow +CatApp +CurrentWsp controller +NewDocumentAction +OpenDocumentAction +UpdateProcessAction +RemoveProcessAction +AddProcessAction +NewDocMenuItemAction +AddProcMenuItemAction +OpenDocMenuItemActio +StartProcessAction +StopProcessAction +UpdProcMenuItemAction +SaveDocumentAction +ExitApplicationAction Figura 14 - Divisão de componentes do GeoCatalog segundo o padrão MVC 4.3. Interface de usuário A Figura 15 apresenta os componentes de software da interface de usuário. Os componentes principais são as janelas principal (CatAppWindow) e de área de trabalho (WspWindow).

69 Implementação do GeoCatalog 69 interface Application interface Document interface Workspace SubjectImpl +createdocument:docume +newdocument:document +loaddocument:document +getdocument:document +open:void +close:void +save:void filename:string +addprocess:boolean +removeprocess:boolean processlist:cataloguingproces +attach:void +deattach:void +notifyobservers:vo +finalize:void state:object 0..* CatAppImpl CurrentWsp WspImpl +createdocument:documen +newdocument:document +loaddocument:document +opendocument:document +getdocument:document +addprocess:boolean +updateprocess:void +removecurrentprocess:boole +startprocess:void +stopprocess:void #in:fileinputstream +addprocess:boolean +removeprocess:boolean +open:void +close:void +save:void filename:string 0..* CatApp CatAppWindow WspWindow CataloguingProcess +newdocument:void +opendocumentp:void newmenuitem:jmenuitem filenamedialog:jdialog newopenbutton:jbutton openmenuitem:jmenuitem processdialog:jdialog datasetsite:jtextfield thesaurus:jtextfield catalog:jtextfield fails:jtextfield processname:jtextfield addupdatebutton:jbutton cancelbutton:jbutton addmenuitem:jmenuitem updatemenuitem:jmenuite startmenuitem:jmenuitem stopmenuitem:jmenuitem removemenuitem:jmenuit filename:jtextfield +closewspwindow:void +savewspwindow:void +update:void +updateprocesstree:void processtree:jtree fails:jlist interface Observer +update:void +current +start:void +stop:void +reporterror:void +listfails:collection +tostring:string factory:frameworkfacto agents:arraylist dictionaries:string[][] repositories:string[] name:string state:string Figura 15 Componentes da interface de usuário do GeoCatalog A janela principal é a janela que inicia a aplicação e contém os componentes para manipulação das áreas de trabalho e processos de catalogação. São eles: a. os itens de menu que executam os casos de uso do usuário; b. uma janela de dialogo para obter o nome do arquivo de área de trabalho a ser criado ou aberto e c. uma janela de diálogo para obter os parâmetros de configuração de um processo de catalogação: nome do processo, diretório para busca de imagens, endereço Web do ADL Gazetteer, nome do arquivo de catálogo e nome do arquivo de falhas.

70 Implementação do GeoCatalog 70 A janela de área de trabalho (Figura 16) exibe informações sobre os processos de catalogação contidos na área de trabalho. Uma árvore de processos na metade à esquerda da janela exibe os nomes e o estado de cada processo de catalogação. Na metade à direita da janela, são listadas as falhas encontradas durante a execução do processo que estiver selecionado pelo usuário. Figura 16 - Janela de área de trabalho Interação com usuário Client Invoker Command +execute:void Receiver ConcreteCommand +action:void +execute:void state:int Figura 17 - Estrutura do padrão de projeto Command

71 Implementação do GeoCatalog 71 Existem três interfaces de software: aplicação (Application), documento (Document) e área de trabalho (Workspace), que definem as operações disponíveis aos usuários. A primeira contém operações para a criação e carga de um documento 17. A segunda contém operações sobre os documentos abertos. A última contém operações para manipulação de processos de catalogação em uma área de trabalho. Client Invoker Abstract Comman JFrame CatAppWindow javax.swing.abstractbutt javax.accessibility.access javax.swing.menuelem javax.swing.jmenuitem java.awt.event.actio interface javax.swing.actio newopenbutton:jbutto datasetsite:jtextfield thesaurus:jtextfield catalog:jtextfield fails:jtextfield processname:jtextfie addupdatebutton:jbutt cancelbutton:jbutton currentwsp:currentws filename:jtextfield javax.swing.abstractbutt javax.accessibility.access javax.swing.jbutton NewDocumentAction +actionperformed:void java.lang.objec java.lang.cloneabl java.io.serializabl...swing.abstractaction StartProcessAction +actionperformed:void OpenDocumentAction StopProcessAction Receiver +actionperformed:void Concrete command +actionperformed:void CatApp AddProcessAction UpdateProcessAction Receiver +newdocument:void +opendocumentp:void +actionperformed:void +actionperformed:void RemoveProcessAction CurrentWsp +actionperformed:void +addprocess:boolean +updateprocess:void +removecurrentprocess:boole +startprocess:void +stopprocess:void Figura 18 - Padrão Command no GeoCatalog A implementação do acionamento das operações dessas interfaces foi baseada no padrão Command. Esse padrão tem como principal objetivo parametrizar a ação de um item de menu. A estrutura do padrão Command, segundo Erich Gamma [15], é apresentada na Figura Documento para, essa aplicação, é uma área de trabalho.

72 Implementação do GeoCatalog 72 Os componentes CatAppImpl e WspImpl do modelo implementam as operações das interfaces que são acionadas através dos receptores (Receiver) de comandos CatApp e CurrentWsp do pacote de controle, respectivamente. Como uma instância da aplicação pode conter várias áreas de trabalho abertas, o componente CurrentWsp executa as operações solicitadas, na área de trabalho que estiver selecionada pelo usuário. As operações dos receptores, por sua vez, são acionadas por comandos (ConcreteCommand) associados aos itens de menu da janela da aplicação. 18. A estrutura do padrão Command no GeoCatalog é apresentado na Figura Atualização das informações de interface de usuário A janela de área de trabalho exibe uma lista com o nome e o estado 18 de todos os processos de catalogação nela contidos e uma lista das falhas de catalogação ocorridas no processo selecionado pelo usuário. Para manter tais informações atualizadas na janela foi utilizado o padrão Observer, cuja estrutura segundo Erich Gamma [15], é apresentada na Figura 19. interface Subject interface Observer +attach:void +deattach:void +notifyobservers:void +finalize:void 0..* +update:void SubjectImpl ObserverImpl +attach:void +deattach:void +notifyobservers:void +finalize:void state:object +update:void state:object Figura 19 - Estrutura do padrão de projeto Observer 18 Os estados possíveis de um processo de catalogação podem ser: executando, parado e interrompido por erro.

73 Implementação do GeoCatalog 73 Nesse padrão objetos (Subject) são componentes cujas propriedades desejam ser monitoradas por um observador (Observer). Caso ocorra alguma alteração no conteúdo dessas propriedades, então, todos os observadores que se declararam interessados devem ser notificados. O funcionamento do mecanismo é o seguinte. Em primeiro lugar, um observador se declara interessado no estado de um objeto solicitando a ele sua inclusão na lista de interessados. Para isso, o observador executa operação attach(this) do objeto passando como parâmetro uma referência para ele próprio. Quando o objeto sofre alguma alteração em seu estado, ele percorre a lista de observadores interessados e notifica cada um deles sobre a mudança. Essa notificação é implementada pela execução da operação update( ) de cada observador na lista de interessados. Essa operação em cada observador irá solicitar do objeto o seu novo estado e executar os procedimentos adequados de atualização do observador. Nesse padrão toda a seqüência de troca de mensagens é síncrona. Para compreendermos a vantagem desse padrão imaginemos outra estratégia para atualização de dados nos observadores. Se ao invés de receber notificações, o próprio observador, periodicamente, solicitasse aos objetos seu estado, o efeito prático seria o mesmo. Entretanto, poderia ocorrer que o observador solicitasse o estado do objeto muitas vezes sem que houvesse alteração alguma. Por outro lado, caso a freqüência com que um observador solicitasse informações sobre o estado fosse pequena em relação à freqüência com que ele se alterasse, muitos efeitos da mudança de estado seriam perdidos nos observadores. No GeoCatalog a janela de Área de Trabalho é um observador dos processos de catalogação (CataloguingProcess), e da implementação de regras de negócio da área de trabalho (WspImpl). Quando há alteração do estado de um desses componentes o seu método update( ) é executado para atualizar a lista de processos e de falhas do processo corrente. Os eventos que disparam a notificação da janela de área de trabalho são: a. alteração do status do processo de catalogação para Running na sua inicialização

74 Implementação do GeoCatalog 74 b. alteração do status do processo de catalogação para Stoped na sua interrupção c. alteração do status do processo de catalogação para Error quando ocorre erro de comunicação ou de acesso a arquivo d. alteração do nome do processo de catalogação e. inclusão de nova falha de catalogação na lista f. inclusão de processo de catalogação na Área de Trabalho g. remoção de processo de catalogação da Área de Trabalho Configuração de um processo de catalogação Um processo de catalogação possui cinco parâmetros de configuração: a. seu nome; b. o nome de um diretório onde serão procurados novos arquivos de dados geográficos para serem catalogados; c. o endereço de serviço de um dicionário geográfico; d. o nome de um arquivo para catálogo; e. o nome de um arquivo para catálogo de falhas. Note que a limitação de um diretório de busca e um dicionário, tem a finalidade de simplificar a implementação. Essa limitação não está prevista na arquitetura apresentada anteriormente. Tais informações serão armazenadas no processo de catalogação (CataloguingProcess) e mais tarde serão utilizadas para criar objetos que encapsulam funções de acesso ao conteúdo de arquivos, ao serviço de dicionário e ao conteúdo de catálogos, como veremos, mais adiante, na seção Inicialização de processo de catalogação A inicialização de um processo de catalogação começa pela criação de seus agentes. Eles são recriados a cada vez que o processo é iniciado pela primeira vez em cada execução do GeoCatalog. O primeiro passo é criar os objetos que encapsulam as operações de acesso aos dados, dicionários e

75 Implementação do GeoCatalog 75 catálogos (temporário, falhas e definitivo) que são FileSystemDirectory, ADLGazetteer e LocalFileCatalog, respectivamente. Cada objeto é construído com uma fábrica de objetos que implementa o padrão Factory Method. Esse padrão é fundamental para permitir a customização do framework de catalogação que será discutido na seção 4.6. Product Creator +factorymethod:produ ConcreteProduc ConcreteCreator public Product factorymetho return new ConcrteProduct() } +factorymethod:produc Figura 20 - Estrutura do padrão de projeto Factory Method A estrutura básica do padrão Factory Method, segundo Erich Gamma [15], é apresentado na Figura 20. Interfaces abstratas da fábrica (Creator) e dos produtos (Product), conhecidas pelo framework, permitem utilizar, na implementação do comportamento do framework, todos os objetos que serão customizados pelo usuário. Quando os produtos concretos estiverem definidos, sua criação ficará delegada para uma fábrica concreta que implementa as operações abstratas de fábrica. No GeoCatalog a fábrica abstrata de objetos é FrameworkFactory (Figura 21) e a fábrica concerta é CustomFactory. O próximo passo é a criação e inicialização dos agentes. Para criar o agente rastreador informa-se um identificador, uma lista de repositórios, um catálogo temporário, um catálogo de falhas e um catálogo definitivo. Para criar o agente catalogador informa-se os mesmos parâmetros exceto que a lista repositórios é substituída por uma lista de dicionários. Agentes são componentes de software que executam threads diferentes e que podem se comunicar através de mensagens. Cada agente executa instruções específicas, mas os mecanismos para troca de mensagem e para execução das threads são genéricos e compartilhados entre todos. Por isso, foi definida uma infra-estrutura básica para comunicação e execução de cada agente.

76 Implementação do GeoCatalog 76 SubjectImp Serializable CataloguingProcess FrameworkFactory Serializable +CataloguingProcess +start:void +stop:void +reporterror:void +listfails:collection +tostring:string agents:arraylist dictionaries:string[][] catalog:string fails:string repositories:string[] name:string state:string +createrepositories:repository[] +createfilecatalog:catalog +creatememorycatalog:catalog +createdictionaries:dictionary[] +createparsers:hashmap +createrepositorydescbuilder:repositorydescbuild +createdictionarydescbuilder:dictionarydescbuilder CustomFactory +ADL_DICTIONARY:String +createparsers:hashmap +createdictionaries:dictionary[] +createrepositorydescbuilder:repositorydescbuilde +createdictionarydescbuilder:dictionarydescbuilder Figura 21 Fábrica de objetos do GeoCatalog A Figura 22 ilustra os componentes para a comunicação de agentes. O mecanismo baseia-se na troca de mensagens (Message) não endereçadas, ou seja, cada mensagem é enviada para todo o grupo de agentes através de um canal de comunicação (MsgChannel) comum. As mensagens específicas de cada aplicação serão subtipos da classe abstrata Message. O fluxo de processamento de cada agente é responsável por obter do canal de comunicação mensagens do tipo apropriado à sua atividade, interpretar apropriadamente o objeto genérico do seu corpo e dar tratamento a ele. A implementação de um agente faz-se pela extensão da classe Agent que encapsula métodos de controle da execução (start( ) e stop( )) e de comunicação (sendmessage( ) e readmessage(message msg)). O método abstrato agentbehavior( ), implementado no agente concreto, determinará o comportamento desse agente. As funções de comunicação são delegadas à uma classe que implementa a interface Comm. Isso permite flexibilidade para, por exemplo, acrescentar comunicação distribuída ao sistema. Poder-se-ia criar uma classe DistributedComm, que implementasse Comm, para gerenciar a troca de mensagens entre componentes remotos. No GeoCatalog foi implementada somente a classe LocalComm para comunicação local entre os agentes.

77 Implementação do GeoCatalog 77 <<abstract>> Agent +sendmessage:void +readmessage:message +start:void +stop:void +run:void +agentbehavior:void thread:thread id:string +commhandler LocalComm +readmessage:message +sendmessage:void <<abstract>> interface Comm +readmessage:messa +sendmessage:void DistributedComm +readmessage:message +sendmessage:void <<abstract>> Message body:object 0..* contains MsgChannel -messages:arraylist -threadstate:hashmap +putmessage:void +getmessage:message Figura 22 - Infra-estrutura para criação de agentes No componente de comunicação local, implementado no protótipo, o canal de comunicação (MsgChannel) é protegido contra acessos simultâneos de dois agentes para evitar inconsistências do repositório de mensagens. Os métodos sendmessage( ) e readmessage( ) da interface de comunicação são sincronizados de modo que cada agente aguardará o canal estar desocupado para efetuar sua comunicação. Como forma de otimizar processamento, existe um dispositivo que interrompe a thread de um agente caso, ao tentar recuperar uma mensagem, o canal de comunicação não retorne nenhuma mensagem. Sua atividade é reiniciada tão logo se acrescente uma nova mensagem no canal de comunicação Geração de metadados No GeoCatalog os repositórios são implementados pela classe FileSystemDirectory que é responsável por extrair metadados de um arquivo armazenado no sistema de arquivos do computador. Sua operação getdescription(string uri) toma como parâmetro um nome de arquivo, decodifica seu conteúdo, extrai os metadados disponíveis, os armazena nas estruturas de metadados com o componente OOISO19115GeoImage e os devolve ao agente

78 Implementação do GeoCatalog 78 rastreador. A identificação do tipo de decodificador apropriado ao dado é feita pela extensão do arquivo de dados. Os decodificadores são armazenados em uma coleção do repositório identificados pela extensão de arquivo que eles são capazes de decodificar. Os arquivos contendo descrições de dados geográficos, de acordo com as premissas de projeto apresentadas no princípio do capítulo, são arquivos XML cujo esquema é o seguinte: <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace=" elementformdefault="qualified" xmlns=" xmlns:gml=" xmlns:gct=" <include schemalocation="geometrybasic2d.xsd" /> <element name="resource"> <complextype> <sequence> <element name="identifier" type="string" minoccurs="1" maxoccurs="1"> </element> <element name="bounding-box" type="gml:envelopetype" minoccurs="1" maxoccurs="1"> </element> </sequence> </complextype> </element> </schema> Os metadados extraídos do repositório são: 1. URI do repositório da imagem; 2. identificador da imagem;

79 Implementação do GeoCatalog coordenadas geográficas dos pontos da diagonal do retângulo de contorno da imagem. Os dicionários são implementados pela classe ADLGazeteer que é responsável por extrair objetos do dicionário geográfico ADL Gazetter. Sua operação getdescription(datasetdescription description) toma como parâmetro a descrição de dado obtida do repositório, elabora uma consulta ao dicionário, conforme descrito na seção 3.1, armazena os metadados obtidos, também, com o componente OOISO19115GeoImage e devolve o resultado para o agente catalogador. A consulta ao dicionário ADL é codificada segundo o protocolo de serviço ADL 19. Segundo a estratégia de catalogação apresentada serão recuperados os objetos do dicionário contidos na área geográfica retangular definida pelas coordenadas da imagem, cujos valores foram armazenados na descrição do repositório. A consulta ao dicionário assume a seguinte forma: 19 Vide Apêndice A Protocolo de serviço do ADL Gazetteer (p. 101).

80 Implementação do GeoCatalog 80 <?xml version="1.0" encoding="utf-8"?> <gazetteer-service xmlns= xmlns:gml=" version="1.2"> <query-request> <gazetteer-query> <footprint-query operator="within"> <gml:box> <gml:coordinates> Longitude esquerda superior, Latitude esquerda superior, Longitude direita inferior, Latitude direita inferior </gml:coordinates> </gml:box> </footprint-query> </gazetteer-query> <report-format>standard</report-format> </query-request> </gazetteer-service> Os metadados extraídos do dicionário são (para cada objeto): 1. Identificador do objeto no dicionário; 2. Nome de exibição da objeto; 3. coordenadas geográficas do objeto Framework de catalogação de dados Um framework é um projeto reutilizável de software. Define um conjunto de classes e um padrão de colaboração entre elas para um domínio específico de aplicação. Por exemplo, um framework para editores gráficos pode ser criado independentemente do tipo de editor que se deseja implementar. Editores de partituras musicais, circuitos eletrônicos e desenhos, são exemplos de aplicações que poderiam utilizá-lo. Para permitir tal generalidade deve-se determinar quais pontos do projeto podem ser customizados em cada tipo de aplicação e para cada um deles definir

81 Implementação do GeoCatalog 81 interfaces abstratas. O projeto do framework utiliza tais interfaces genéricas para compor a colaboração entre as classes e, assim, definir o comportamento básico dos componentes. Ao aplicá-lo na construção de um software específico, as operações, antes abstratos, irão incorporar o comportamento adequado para o tipo de aplicação. De acordo com Pree (1994) [16], um framework consiste em frozen spots e hot spots. Frozen spots são as classes e colaborações pré-definidas que não podem ser alteradas na customização. Hot spots são os pontos de extensão, pontos abstratos no projeto que serão customizados. Analogamente a uma instância de uma classe diz-se que um framework customizado para uma determinada aplicação é uma instância do framework original. O princípio fundamental que norteia o projeto desses artefatos de software é o seguinte: Não nos chame. Chamaremos você (Larman 2002). Isso significa que as classes definidas pelo usuário não devem chamar as classes prédefinidas. Elas receberão chamadas destas. Com a abordagem descrita é possível aumentar o grau de confiabilidade do software e diminuir o esforço de desenvolvimento, uma vez que código fonte e até mesmo código objeto, já testados, são reutilizados. Framework para catalogação de dados genéricos Da mesma forma como um grande volume de dados geográficos está disponível em grande variedade de repositórios e formatos, dados de outras naturezas, como áudio e vídeo, imagens e documentos também estão e compartilham os mesmos problemas de localização. A recuperação de alguns desses dados, no entanto, apresenta problemas adicionais. Dados multimídia, por exemplo, necessitam de sincronismo e velocidade constante de recuperação para a sua correta apresentação. Nesse trabalho, não trataremos dessa última categoria de problemas. Concentraremos a atenção no problema comum de localização do dado. A solução do problema para todos os tipos de dados também são catálogos de metadados. Um exemplo da utilização desses catálogos em outro domínio de aplicação é apresentado por Hollink et al. [4] em Semantic

82 Implementação do GeoCatalog 82 Annotation of Image Collections, onde eles descrevem uma técnica para descrição de uma coleção de arte. Surge, então, a idéia de um framework para catalogação automática de dados, onde o fluxo de processamento: obter novos dados, obter metadados e catalogar dado, é comum em todas as áreas aplicação. As regras de geração dos metadados, no entanto, devem ser customizadas em cada caso. É claro que só faz sentido falarmos em framework de catalogação automática se houver algum algoritmo para geração automática de metadados. No caso dos dados geográficos, vimos que dicionários geográficos capazes de identificar objetos contidos em determinada área geográficas fornece um mecanismo eficiente para a geração automática de metadados. Teoria análoga deve ser apresentada para cada domínio de aplicação do framework. Nesse trabalho, no entanto, não abordaremos essa questão. A Figura 23 apresenta um esquema do framework para catalogação automática de dados.

83 Implementação do GeoCatalog 83 Figura 23 Framework de catalogação automática

84 Implementação do GeoCatalog 84 Os frozens spots desse framework são determinados pelo processo de catalogação e interface de usuário que podem ser reutilizados nas diferentes áreas de aplicação. seguintes: Os hot spots, que devem ser customizados pelos usuários são os a. Estrutura para armazenamento de metadados; A classe DatasetDescription é a classe genérica que representa os metadados do dado a ser catalogado. Define propriedades básicas como identificador e URI (identificador do recipiente do dado) e um único método para agregação de objetos relacionados passados como parâmetro. public abstract class DatasetDescriptin { private String identifier = null; private String uri = null; public abstract void aggregatedescription (DatasetDescription datasetdescription); public String getidentifier( ) { return identifier; } public void setidentifier(string identifier) { this.identifier = identifier; } public String geturi( ) { return uri; } public void seturi(string uri) { this.uri = uri; } } No GeoCatalog essa classe foi estendida pela classe GeoImage que implementa outra interface para capturar metadados de arquivos de

85 Implementação do GeoCatalog 85 descrição de imagens geográficas. Subclasses de GeoImage determinam a forma de armazenamento dos metadados. Em OOISO19115GeoImage os metadados são armazenados em estruturas orientadas a objeto. Ela é a extensão de DatasetDescription realmente utilizada na aplicação. Em OntISO19115GeoImage os metadados são armazenados segundo a norma ISO19115, porém, utilizando-se um modelo semântico definido em uma ontologia. Ela foi implementada somente a título de ilustração das variações possíveis na instanciação desse framework. b. Os dicionários de termos; A classe Dictionary é a classe genérica que representa o ponto de acesso aos dados de um dicionário. Define um único comportamento para obtenção de metadados que recebe como parâmetro metadados obtidos de um repositório e devolve objetos relacionados a eles armazenados em um dicionário. public abstract class Dictionary extends DescriptionSource{ Private transient DictionaryDescBuilder builder = null; public Dictionary(String url) { super(url); } public abstract Dataset getdescription (DatasetDescription datasetdescriptin); public Builder getbuilder( ) { if (builder == null){ builder = getfactory( ). createdictionarydescbuilder( ); return builder; } } } No GeoCatalog essa classe foi estendida em ADLGazetteerService que implementa a consulta ao dicionário geográfico ADL.

86 Implementação do GeoCatalog 86 c. A codificação com que os metadados e as consultas aos dicionários são fornecidos ao software. Os procedimentos de geração de metadados baseia-se, conforme apresentado na seção 3.4, em dois componentes: Parser Builder. O primeiro, é utilizado na decodificação do conteúdo de um repositório ou das informações obtidas de um dicionário. Define uma única operação para obtenção das informações: parse( ). public abstract class Parser extends DefaultHandler { private Builder builder = null; public Parser(Builder builder) { this.builder = builder; } public abstract MetadataElement[ ] parse (InputSource source); public Builder getbuilder( ) { return builder; } } Na instância para catalogação de dados geográficos assumimos que tanto os dados geográficos quanto o protocolo de serviço do dicionário forneceriam informações em XML. Por isso, foi implementado somente um XMLParser. Como ilustração de variações possíveis, foi criado o componente GeoTIFFParser que seria responsável por encapsular algoritmos de decodificação de arquivos de imagens geográficas em formato GeoTIFF. O segundo componente, o Builder, tem dois propósitos: construir um descrição de dados para armazenar os metadados extraídos do repositório do dado (RepositoryDescBuilder) e construir uma descrição de dados para armazenar objetos obtidos de um dicionário (DictionaryDescDescription).

87 Implementação do GeoCatalog 87 public abstract class Builder { public abstract void build(object datasetelements); public abstract Dataset getdataset( ); } No GeoCatalog RepositoryDescBuilder foi estendida em ISO19115ImageBuilder que constrói um GeoImage a partir de um vetor MetadataElement[ ], segundo o esquema de metadados definido pela ISO A DictionaryDescBuilder foi estendida em ISO19115ADLFeaturesBuilder que constrói, também a partir de um vetor com a mesma estrutura, um GeoImage contendo objetos obtidas de um dicionário, segundo esquema da ISO Para que o framework seja capaz de instanciar as classes definidas pelo usuário, uma fábrica de objetos, FrameworkFactory, baseada no padrão de projeto Factory Method foi utilizada. Os métodos abstratos foram implementados na classe de usuário CustomFactory Métricas e organização do código A seguir a listagem mostra os pacotes de organização das classes Java e algumas métricas de código do GeoCatalog. Legenda: LOC = linhas de código NOC = número de classes NOA = número de atributos NOO = número de operações Item LOC NOA NOC NOO <total> br br.pucrio br.pucrio.inf

88 Implementação do GeoCatalog 88 br.pucrio.inf.catfwk br.pucrio.inf.catfwk.appmodel br.pucrio.inf.catfwk.controller br.pucrio.inf.catfwk.model br.pucrio.inf.catfwk.view br.pucrio.inf.geocat br.pucrio.inf.lib br.pucrio.inf.lib.agent br.pucrio.inf.lib.command br.pucrio.inf.lib.factorymethod br.pucrio.inf.lib.observer br.pucrio.inf.lib.util iso iso.iso iso.iso19109.metadata iso.iso iso.iso19115.appliation_schema iso.iso19115.application_schema iso.iso19115.citation iso.iso19115.constraint iso.iso19115.content iso.iso19115.data_quality iso.iso19115.distribution iso.iso19115.identification iso.iso19115.maintenance iso.iso19115.metadata iso.iso19115.metadata_extension iso.iso19115.portrayal_catalogue iso.iso19115.reference iso.iso19115.reference_system iso.iso19115.spatial_representation iso.iso iso.iso19139.dataset

89 Implementação do GeoCatalog Exemplo de utilização Como exemplo de catalogação, tomemos um repositório de dados geográficos que contém três arquivos arquivos XML como definidos a seguir. <?xml version="1.0" encoding="utf-8"?> <resource xmlns:gml=" <identifier>rio de Janeiro (região do Maracanã) </identifier> <bounding-box> <gml:coord> <gml:x>-43.26</gml:x> <gml:y> </gml:y> </gml:coord> <gml:coord> <gml:x> </gml:x> <gml:y> </gml:y> </gml:coord> </bounding-box> </resource> Figura 24 Arquivo contendo a descrição de área geográfica do entorno do estádio do Maracanã (Rio de Janeiro)

90 Implementação do GeoCatalog 90 <?xml version="1.0" encoding="utf-8"?> <resource xmlns:gml=" <identifier>região vazia (coordenadas repetiodas) </identifier> <bounding-box> <gml:coord> <gml:x>-42.8</gml:x> <gml:y>-22.2</gml:y> </gml:coord> <gml:coord> <gml:x>-42.8</gml:x> <gml:y>-22.2</gml:y> </gml:coord> </bounding-box> </resource> Figura 25 Arquivo contendo a descrição de uma região vazia <?xml version="1.0" encoding="utf-8"?> <resource xmlns:gml=" <bounding-box> <gml:coord> <gml:x>-42.8</gml:x> <gml:y>-22.2</gml:y> </gml:coord> <gml:coord> <gml:x>-42.8</gml:x> <gml:y>-22.2</gml:y> </gml:coord> </bounding-box> </resource> Figura 26 Arquivo com erro de estrtura (falata o identificador)

91 Implementação do GeoCatalog 91 Definamos um processo de catalogação com a seguinte configuração: Figura 27 Configuração de processo de catalogação no GeoCatalog Os parâmetros de configuração do processo de catalogação acima definem que os dados geográficos serão procurados no diretório corrente, e o gazetteer a ser utilizado é o ADL Gazetteer. Além disso, são informados os nomes dos arquivos de catálogos para os dados que sofrerem alguma falha no processo de geração de metadados e para aqueles sem nenhuma exceção. Ao executarmos esse processo sobre os três arquivos anteriores será produzida uma imagem do catálogo de dados geográficos (exemplo1.dat), em formato XML, contendo somente os metadados do primeiro arquivo XML e os objetos do gazetteer contidos na região definida pelo arquivo. Os demais arquivos não poderão ser catalogados uma vez que apresentam irregularidades. O segundo arquivo contém a descrição de uma região espacial vazia, ou seja, correspondente a um ponto. Por isso, não será possível encontrar, no Gazetteer, nenhum objeto contido nessa região, a não ser que seu ponto de representação coincida com aquele descrito no arquivo, o que não é o caso nesse exemplo. O terceiro arquivo contém uma falha estrutural, não possui o identificador (tag <\identifier> e será desprezado sem que o processo tente obter alguma informação do ADL Gazetteer. Assim, o arquivo produzido pelo processo de catalogação será como mostrado a seguir.