GABRIEL NIERO DE CARVALHO
PROPOSTA DE TRATAMENTO E MODELAGEM DE DADOS
ESPACIAIS PARA USO EM INFRAESTRUTURA DE DADOS
ESPACIAIS - IDEs: ESTUDO DE CASO DE MACROBENTOS PARA A
ÁREA COSTEIRA DA BAIXADA SANTISTA
GABRIEL NIERO DE CARVALHO
PROPOSTA DE TRATAMENTO E MODELAGEM DE DADOS
ESPACIAIS PARA USO EM INFRAESTRUTURA DE DADOS
ESPACIAIS - IDEs: ESTUDO DE CASO DE MACROBENTOS PARA A
ÁREA COSTEIRA DA BAIXADA SANTISTA
Dissertação de Mestrado apresentada à Escola Politécnica da Universidade de São Paulo para obtenção do título de Mestre em Engenharia.
Área de Concentração:
Engenharia de Transportes –
Geoprocessamento
Orientador: Prof. Dr. José Alberto Quintanilha
GABRIEL NIERO DE CARVALHO
PROPOSTA DE TRATAMENTO E MODELAGEM DE DADOS
ESPACIAIS PARA USO EM INFRAESTRUTURA DE DADOS
ESPACIAIS - IDEs: ESTUDO DE CASO DE MACROBENTOS PARA A
ÁREA COSTEIRA DA BAIXADA SANTISTA
Dissertação de Mestrado apresentada à Escola Politécnica da Universidade de São Paulo para obtenção do título de Mestre em Engenharia.
Área de Concentração:
Engenharia de Transportes –
Geoprocessamento
Orientador: Prof. Dr. José Alberto Quintanilha
Este exemplar foi revisado e alterado em relação à versão original, sob responsabilidade única do autor e com a anuência de seu orientador.
São Paulo, de Setembro de 2013
Assinatura do autor ____________________________
Assinatura do orientador ________________________
FICHA CATALOGRÁFICA
Carvalho, Gabriel Niero de
Proposta de tratamento e modelagem de dados espaciais para uso em infraestrutura de dados espaciais – IDEs: estudo de caso de macrobentos para a área costeira da Baixada Santista / G.N. de Carvalho. – versão corr. -- São Paulo, 2013.
120 p.
Dissertação (Mestrado) - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Transportes.
AGRADECIMENTOS
A toda minha família que sempre me apoiou em todos os aspectos.
A minha namorada por ter muita paciência na elaboração deste mestrado.
Ao Prof. Dr. José Alberto Quintanilha primeiramente por acreditar na minha capacidade, além do apoio e amizade.
A Profa. Dra. Sílvia Sartor, que me ajudou diretamente a definir o tema do meu mestrado e me ensinar um pouco da área ambiental, Macrobentos, etc.
A Profa. Dra. Karla Borges, por suas sábias palavras e conhecimento que muito agregaram neste trabalho.
A Mari, do LabGeo (USP), pela transmissão de conhecimento e incentivo nos estudos e a Patrícia Santana, do Programa de Pós Graduação PTR, por sempre me ajudar nas questões de matrícula, etc.
Gostaria também agradecer a algumas pessoas específicas que me ajudaram de alguma forma na construção deste trabalho, em especial: Wolmar Sabino – me ensinou o “mundo” de SIG; Eduardo Nakamura - grande amigo e altamente capaz; Eduardo Kenzo – pela ajuda em vários momentos de dificuldade técnica; André Strauss – por sempre me incentivar a concluir esta tese.
RESUMO
As zonas costeiras são áreas complexas que contemplam ambientes terrestres e marinhos que, além de possuírem enorme riqueza ambiental, também são áreas atrativas aos seres humanos por oferecer alimentos, lazer, negócios, transporte, entre outros. Algumas dificuldades de gerenciamento ocorrem pela complexidade, conflito de interesses e pelo fato de não haver padronização no levantamento de dados e disponibilização para a comunidade científica, órgãos públicos, etc. O uso de geotecnologias pode auxiliar na organização, padronização e compartilhamento destas informações em Atlas Web além de apoiar no planejamento e tomada de decisão pois agregam, em um único ambiente, diversos dados provenientes de fontes distintas. A construção de um modelo de dados espacial voltado à área ambiental, para ser utilizada em Infraestrutura de Dados Espaciais (IDE) é exemplificada a partir da modelagem de um bioindicador, Macrobentos, de qualidade de sedimentos. Este trabalho apresenta as etapas necessárias para a construção de modelo de dados espacial de Macrobentos e emprega a Região Metropolitana da Baixada Santista como referência, além de ilustrar e discutir as principais dificuldades para organizar os dados não padronizados. Conclui-se que a estruturação do conhecimento quando se trabalha com dados ambientais em um modelo é essencial para sua posterior integração em IDE. Constatou-se no processo de modelagem que questões metodológicas relativas ao processo de coleta podem dificultar ou até mesmo inviabilizar a integração de dados provenientes de diferentes estudos. A construção de um modelo de dados espacial e sua posterior publicação via Geoportal, como o apresentado neste estudo, poderá ser utilizado como referência para novas pesquisas com objetivos semelhantes.
ABSTRACT
Coastal zones are complex areas that include marine and terrestrial environments. Besides its huge environmental importance, they also attract humans because they provide food, recreation, business, transportation, among others. Some difficulties to manage these areas are related with their complexity, diversity of interests and the absence of standardization to collect and share data to scientific community, public agencies, among others. The use of geo-technologies can be used in the organization, standardization and sharing of this information through Atlas Web and assists planning and decision making issues because it aggregates different files from distinct sources. The construction of a spatial database integrating the environmental business, to be used on Spatial Data Infrastructure (SDI) is illustrated by a bioindicator, Macrobenthos, that indicates the quality of the sediments. This research shows the required steps to build Macrobenthos spatial database based on Santos Metropolitan Region as a reference. Besides, it tries to illustrate the problems related to organize non standardized data. It can be concluded, when working with environmental data, that the structuring of knowledge in a conceptual model is essential for their subsequent integration into the SDI. During the modeling process it can be noticed that methodological issues related to the collection process may obstruct or make impracticable the data integration from different studies of the same area. The development of a database model and its subsequent publication in a Geoportal can be used as a reference for further research with similar goals.
LISTA DE ILUSTRAÇÕES
Figura 1. Hierarquia de IDE, adaptado de (Rajabifard, 2006). ... 9
Figura 2. Diagrama representando as etapas da IDE, adaptado de (Hjelmager et al., 2008). ... 10
Figura 3. Arquitetura de uso de serviços, adaptado de (OGC, 2011). ... 13
Figura 4. Mapa resultante da requisição no browser de um serviço WMS. ... 14
Figura 5. Arquitetura de requisição de serviço, adaptado de (OGC, 2011). ... 16
Figura 6. Arquitetura resumida de um Geoportal dentro de uma IDE. ... 18
Figura 7. Composição das seções referentes ao padrão FGDC e suas obrigatoriedades, adaptado de (FGDC, 2011). ... 20
Figura 8. Processo de Abstração para a construção do Modelo de Dados (Câmara et al., 2005). ... 27
Figura 9. Níveis de Abstração de Dados Geográficos (Câmara et al., 2005). ... 27
Figura 10. Notação gráfica do Diagrama de Classe UML (Lisboa Filho, 2000). ... 29
Figura 11. Diferenciação entre Classes Geográficas e Convencionais (Câmara et al., 2005). ... 30
Figura 12. Exemplos de Representações de Geo-Campo (Câmara et al, 2005). ... 30
Figura 13. Exemplo de Representação de Geo-Objeto (Câmara et al., 2005). ... 30
Figura 14. Armazenamento de Dados Espaciais utilizando CAD (Davis e Oliveira, 2002). ... 31
Figura 15. Sistema Gerenciador de Banco de Dados. ... 33
Figura 16. Fluxo de um ETL, adaptado de (Trujillo e Luajn-Mora, 2003). ... 36
Figura 17. Aplicação de ETL para dados espaciais (Farley, 2009). ... 37
Figura 18. Exemplo de utilização de ETL Espaciais (Pestana e Silva, 2003). ... 38
Figura 19. ETL como padronizador de dados para IDE (Hintz, 2009). ... 39
Figura 20. Contexto Espacial da Região Metropolitana da Baixada Santista no Estado de São Paulo composta pelos municípios: Bertioga, Cubatão, Guarujá, Itanhaém, Mongaguá, Peruíbe, Praia Grande, Santos e São Vicente. ... 43
Figura 21. Resumo da Metodologia. ... 49
Figura 22. Esquema Conceitual de dados de Macrobentos. ... 51
Figura 23. Parte 1 do Esquema Físico de Dados dos Macrobentos. ... 54
Figura 24. Parte 2 do Esquema Físico de Dados dos Macrobentos ... 55
Figura 26. Interface Administrativa da ferramenta GeoNetwork. ... 66
Figura 27. Perfil MGB sumarizado (CONCAR, 2009). ... 67
Figura 28. Interface de pesquisa no GeoNetwork. ... 71
Figura 29. Resultado de requisição URL feita ao Catálogo de Metadados GeoNetwork. ... 72
Figura 30. Arquitetura do Geoportal e suas principais funcionalidades (GeoMedia SDI, 2012). ... 73
Figura 31. Consultas simultâneas da ferramenta (GeoMedia SDI, 2012). ... 74
Figura 32. Associação de feições espaciais a um único registro de metadados. ... 76
Figura 33. Menu acesso online integrando o registro de metadados com o dado espacial via URL OGC WMS. ... 77
Figura 34. Visão Geral do Geoportal. ... 78
Figura 35. Interface de busca de metadados e janela com descrição detalhada. ... 78
Figura 36. Adição de serviços externos do IBGE ao Geoportal. ... 79
Figura 37. Imagens do Google Maps como plano de fundo somado aos pontos de coleta de Macrobentos. ... 80
Figura 38. Imagens do Google Maps como plano de fundo somado aos pontos de coleta de Macrobentos. ... 80
Figura 39. Medições de distância entre determinados pontos de coleta. ... 81
LISTA DE TABELAS
LISTA DE ABREVIATURAS E SIGLAS
AMA - African Marine Atlas
AMBIS - Australian Marine Boundary Information System AODCJF - Australian Ocean Data Centre Joint Facility BCG - The Boston Consulting Group
BI - Business Intelligence
CEMG - Comitê de Estruturação de Metadados Geoespaciais CGDI - Canadian Geospatial Data Initiative
CSDI - Coastal Spatial Data Infrastructure
CMARIS - Coastal and Marine Resource Information System CONCAR - Comissão Nacional de Cartografia
CSW - Catalog Service Web DW - Data Warehouse
EML - Ecological Metadata Language
EPUSP - Escola Politécnica da Universidade de São Paulo ER - Entidade-Relacionamento
ET-EDGV - Especificação Técnica para a Aquisição de Dados Geoespaciais Vetoriais
ETL - Extract Transform and Load
Emplasa - Empresa Paulista de Planejamento Metropolitano FGDC - Federal Geographic Data Committee
FOSS - Free and Open Source Software Funai - Fundação Nacional do Índio GA - Geoscience Australia
GCE - Georgia Coastal Ecosystems GML - Geography Markup Language
GISER - Geographic Information System Entity Relational GPS - Global Positioning System
GSDI - Global Spatial Data Infrastructure Association GUI - Graphical User Interface
HTTP - Hypertext Transfer Protocol
ICMBIO - Instituto Chico Mendes de Conservação da Biodiversidade IDE - Infraestrutura de Dados Espaciais
IFO - Modelo Semântico Formal de Banco de Dados INDE - Infraestrutura Nacional de Dados Espaciais
INSPIRE - European Commission’s INfrastructure for SPatial InfoRmation in Europe IOC - International Oceanographic Data
IODE - Information Exchange Committee of the Internacional Oceanographic Commission
ISO - International Organization for Standardization LTER - Long Term Ecological Research Network MBAR - Monterrey Bat Aquarium Research Institute MDIP - Marine Data and Information Partnership
MEDIN - Marine Environmental Data and Information Network MGDI - Marine Geospatial Data Infrastructure
MIDA - Marine Irish Data Atlas
MIML - Marine Information Mark-up Language MMA – Ministério do Meio Ambiente
MSCC - Marine Science Coordination Committee NCEAS - National Center for Ecological Analysis
NOAA - National Oceanic and Atmospheric Administration OBIS - Ocean Biogeographic Information System
Odinafrica - Ocean Data and Information Network for Africa OGC - Open Geospatial Consortium
OLAP - On-line Analytical Processing OMG - Ocean Mapping Group
OMT-G - Object Modeling Technique for Geographic Applications OO - Orientado a Objeto
OWL - Web Ontology Language OWS - OGC Web Services
RDF - Resource Description Framework
RMBS - Região Metropolitana da Baixada Santista SAD69 - South American 1969
SGBD - Sistema Gerenciador de Banco de Dados SIG - Sistema de Informações Geográficas
SOA - Service Oriented Architeture
UDDI - Universal Description, Discovery and Integration Protocol UML - Unified Modeling Language
URI - Uniform Resource Identifier URL - Uniform Resource Locator
UTM - Universal Transversal de Mercator WCS - Web Coverage Service
WFS - Web Feature Service
WFS-T - Web Feature Service Transaction WGS-84 - World Geodetic System
WMS – Web Map Service WMTS - Web Map Tile Service WPS - Web Processing Service
SUMÁRIO
1 INTRODUÇÃO ... 1
1.1 APRESENTAÇÃO ... 1
1.2 OBJETIVOS ... 3
1.3 JUSTIFICATIVA ... 3
1.4 ESTRUTURA DO TRABALHO ... 5
2 REVISÃO BIBLIOGRÁFICA ... 7
2.1 INFRAESTRUTURA DE DADOS ESPACIAIS ... 7
2.2 ARQUITETURA BASEADA EM SERVIÇOS ... 11
2.2.1 Serviços Web ... 11
2.2.2 Geo Serviços ... 12
2.2.3 Geoportal ... 16
2.3 CONCEITO E IMPORTANCIA DE METADADOS ... 18
2.3.1 Metadados na área ambiental ... 22
2.4 BANCO DE DADOS GEOGRÁFICOS ... 25
2.4.1 Modelagem Conceitual de Dados Geográficos ... 26
2.4.2 Implementação Física do Banco de Dados Espacial ... 31
2.4.3 Transformação e Importação de dados ... 35
2.5 REVISÃO DE APLICAÇÕES ESPACIAIS PARA A ÁREA AMBIENTAL ... 40
2.5.1 Gerenciamento de Áreas Costeiras e Marinhas ... 40
2.6 DEFINIÇÃO DA ÁREA DE ESTUDO ... 42
2.6.1 Região Metropolitana da Baixada Santista ... 42
3 MATERIAIS E MÉTODOS ... 48
3.1 INTRODUÇÃO ... 48
3.2 METODOLOGIA ... 48
3.3 CONSTRUÇÃO DO MODELO DE DADOS ... 50
3.3.1 Modelo Conceitual de Dados ... 50
3.3.2 Modelo Físico ... 54
3.4 IMPORTAÇÃO DE DADOS GEOESPACIAIS ... 56
3.4.1 Características dos Dados ... 56
3.4.2 Dificuldades Práticas ... 61
3.5 DEFINIÇÃO E PREENCHIMENTO DE METADADOS ... 64
3.5.1 Criação de Catálogo de Metadados ... 64
3.5.2 Preenchimento de Metadados ... 66
3.5.3 Compartilhamento de Informações ... 70
3.6 CONSTRUÇÃO DO ATLAS AMBIENTAL (GEOPORTAL) ... 72
3.6.1 Características Gerais... 72
3.6.2 Criação de Serviços Geoespaciais ... 75
3.6.3 Navegação pelo Portal ... 77
4 RESULTADOS ... 82
4.1 INTRODUÇÃO ... 82
4.2 CONSIDERAÇÕES ... 83
5 CONCLUSÃO ... 85
6 CONSIDERAÇÕES FINAIS ... 88
REFERÊNCIAS BIBLIOGRÁFICAS ... ...91
1 INTRODUÇÃO
1.1 APRESENTAÇÃO
As Zonas Costeiras são áreas complexas, compostas por ambientes terrestres e marinhos, que não somente constituem reservas de biodiversidades como também oferecem aos seres humanos desde alimentos até oportunidades de lazer, negócios, transporte marítimo, pesca, etc.
Segundo Rodríguez e Windevoxhel (1998), a Zona Costeira é:
“o espaço delimitado pela interface entre o oceano e a terra, ou seja, a faixa
terrestre que recebe influência marítima e a faixa marítima que recebe influência terrestre” (tradução do autor).
Já o Atlas Universal do Oceano Un Atlas (2012), estima-se que 60% da vida humana
encontra-se nestas regiões e que a taxa de crescimento da população humana nestas zonas costeiras é cerca do dobro em relação ao crescimento global, o que só faz aumentar a pressão sobre estas áreas.
Este cenário também intensifica as atividades vinculadas à degradação ambiental, variabilidade climática, entre outros. Como exemplo, o aumento da industrialização na Região Metropolitana da Baixada Santista potencializa a grande quantidade de agentes tóxicos que se acumulam no sedimento e influenciam diretamente as populações faunísticas que vivem nesta região. O impacto em um elo da cadeia trófica, neste caso em específico, Macrobentos, interfere diretamente na atividade pesqueira, por exemplo. Segundo o mesmo Un Atlas (2012), estima-se que cerca de
um bilhão de pessoas dependem da pesca como principal fonte de proteínas animais.
A informação geográfica em zonas costeiras é essencial, pois agrega o contexto espacial, permitindo a realização de análises. Estas indicam distribuição, concentração e tendências de indicadores ambientais que facilitam o planejamento costeiro. Entretanto, para ser possível utilizar esta potencialidade é imprescindível que fontes de dados sigam normas e padrões garantindo assim o correto compartilhamento e análise.
para a busca de uma informação que, quando pensado especificamente na área espacial, se trata de um conteúdo geográfico (geometria, imagem de satélite, metadado, etc.). Possibilita também que organizações, comunidades, etc., possam interagir distribuindo informações padronizadas com o principal objetivo de auxiliar nas tomadas de decisões.
As iniciativas de organização e compartilhamento de informações costeiras, principalmente as internacionais (Estados Unidos, Canadá, Irlanda, Reino Unido e Austrália), estão em processo de desenvolvimento e cada vez mais buscam construir uma ferramenta que possa auxiliar na gestão e na tomada de decisão, por meio da integração de dados e a sua rápida disponibilização por meio, por exemplo, de portais.
No Brasil as iniciativas para construção de Infraestruturas de Dados Espaciais (IDE) que contemplem as questões Costeiras e Marinhas ainda são incipientes. As Cartas de Sensibilidade Ambiental ao Óleo desenvolvidas pela Petrobras (Araujo et al., 2007) e pelo Ministério do Meio Ambiente Brasileiro (MMA), (Ghehardi et al., 2008), avançaram na questão, mas não tratam de aspectos relativos à padronização no levantamento de dados ambientais e disponibilização ampla para facilitar o planejamento costeiro.
A pesquisa desenvolvida pela Escola Politécnica da Universidade de São Paulo (EPUSP), pertencente ao projeto denominado “Atlas Ambiental e Socioeconômico da Baixada Santista, financiado pela FAPESP (Processo nº 2006/51780-2), no Programa de Políticas Públicas”, teve como objetivo desenvolver um atlas ambiental Web contemplando as principais fontes de informações existentes para a Região Metropolitana da Baixada Santista, voltado à fiscalização e licenciamento ambiental, baseado em tecnologias de IDE.
1.2 OBJETIVOS
O objetivo desta pesquisa é propor uma metodologia para organizar dados ambientais, espaciais e alfanuméricos, sem padronização, para que possam ser visualizados por meio de uma interface Web, denominado Atlas Ambiental (Geoportal). Para tanto, esta pesquisa pretende discutir e exemplificar a respeito das etapas necessárias para a construção de um modelo de dados espacial, além das principais dificuldades encontradas no entendimento e importação de dados ambientais.
Para ilustrar este processo foi eleito o tema Macrobentos como estudo de caso, considerado um indicador ambiental, a partir de fontes de dados distintas e sem padrão de codificação nos levantamentos. Além disso, é também objetivo demonstrar as etapas necessárias para a elaboração de um Atlas Ambiental, desde a importação de dados, preenchimento de metadados, construções de serviços geoespaciais até a disponibilização das informações de forma padronizada, seguindo os conceitos de uma Infraestrutura de Dados Espaciais.
A área escolhida para a construção do modelo de dados foi a Região Metropolitana da Baixada Santista (RMBS), por ser relevante sob diversos aspectos ambientais e socioeconômicos (Sartor et al., 2007 e 2009).
O modelo de dados consiste em uma forma estruturada de representar os dados que, posteriormente, pode ser utilizada como referência e estendida para outras regiões e/ou temas ambientais, que não necessariamente, apenas Macrobentos.
1.3 JUSTIFICATIVA
se torna um fato importante neste contexto, pois como mostra Rodríguez et al. (2008), é possível realizar a integração de diversos tipos de dados, de diferentes épocas e contexto possibilitando uma análise conjunta com fácil acesso às informações.
Especificamente no caso de Macrobentos, há uma escassez muito grande de estudos, principalmente que abordem a padronização de levantamentos, organização, documentação e disponibilização dos dados. A maioria das informações existentes na Região Metropolitana da Baixada Santista encontra-se em formato analógico (teses de mestrado e/ou doutorado, estudos técnicos específicos) ou formato digital (Microsoft Excel ou PDF), elaborados para propósitos específicos.
O fato de existir esta enorme lacuna na quantidade e disponibilização de informações sobre o tema Macrobentos na região, aumenta o interesse em propor uma metodologia que possibilite a agregação dos estudos existentes e também sirva como referência para futuras pesquisas com o intuito de respaldar avaliações e análises vinculadas à fiscalização, licenciamento, análise temporal de evolução da degradação ambiental, etc., por parte de órgãos públicos, cientistas, técnicos, entre outros.
A comunidade de organismos Macrobentos, estudo de caso desta pesquisa, é muito importante em estudos ambientais, pois é utilizada como indicador do grau de degradação/ conservação do ambiente. Por meio destes seres vivos é possível inferir se determinada área possui uma concentração de poluição, por exemplo. É essencial, portanto, que se entenda como se dá sua distribuição ao longo da Zona Costeira da Baixada Santista com o intuito de se planejar melhor políticas públicas vinculadas à preservação do Meio Ambiente.
Umas das formas encontradas para disponibilizar estas informações à sociedade em geral, que normalmente não é familiarizada com os conceitos de Sistema de Informações Geográficas, é através das Infraestruturas de Dados Espaciais. Esta estrutura deve ser a mais transparente de forma que seja possível compartilhar dados, processos, análises, entre outros.
comunidade, representada por órgãos públicos, pesquisadores e população em geral. A construção de uma metodologia se faz necessária para ilustrar as diversas etapas na construção de um modelo de dados espacial referente ao tema Macrobentos. Esta informação, uma vez organizada, poderá ser integrada por qualquer Geoportal que siga os conceitos da IDE.
1.4 ESTRUTURA DO TRABALHO
O capítulo introdutório busca resumir o que é apresentado na pesquisa, já o capítulo “2 Revisão Bibliográfica” aborda a revisão bibliográfica e a fundamentação teórica da pesquisa. Foi feita uma divisão em seis grandes temas expressos pelos itens: “2.1 Infraestrutura de Dados Espaciais” que trata dos conceitos envolvidos em uma IDE e as formas de estruturá-la; “2.2 Arquitetura baseada em serviços”, que discute sobre as principais tecnologias e arquiteturas utilizadas em geoserviços; “2.3 Conceito e importância de Metadados”, onde é feito um resumo sobre o conceito de metadados e alguns dos principais padrões de armazenamento com enfoque em dados espaciais; “2.4 Banco de Dados Geográficos” aborda, por meio de subitens, os conceitos envolvidos na construção e no armazenamento de dados espaciais em Sistema Gerenciador de Banco de Dados, além de destacar processos de transformação de dados, inerentes ao processo, quando se deseja integrar diversas fontes de dados distintas; “2.5 Revisão de aplicações espaciais para a área ambiental” é feita uma abordagem específica de algumas iniciativas de Infraestrutura de Dados Espaciais para a área ambiental; “2.6 Definição da Área de Estudo” é discutido acerca da área escolhida e os principais fatores que podem causar degradação ambiental, além da contextualização e destaque dos organismos Macrobentos como bioindicador ambiental.
2 REVISÃO BIBLIOGRÁFICA
2.1 INFRAESTRUTURA DE DADOS ESPACIAIS
A era da informação está em desenvolvimento; o rápido acesso a informações pode ser feito praticamente em qualquer lugar do mundo que exista acesso a Internet. Embora este seja um cenário interessante, a mudança de paradigma faz com que algumas novas dificuldades, nunca antes pensadas, se exacerbem e as resoluções das mesmas são parte da evolução da tecnologia.
Diante deste contexto, o dado geográfico se apresenta como um dos mais críticos elementos para rápido consumo entre diferentes pessoas, organizações, cientistas, etc. Interessante discussão é abordada no estudo realizado pelo grupo The Boston Consulting Group (BCG), que ilustra como a demanda por dados geoespaciais é
crescente no mercado americano, não só ambiente corporativo, mas também na população que utiliza de informação geográfica para tomar decisões rotineiras baseadas no contexto espacial, seja para buscar uma melhor rota para sua residência, um bom restaurante ou até mesmo a localização geográfica de entes próximos (Henttu et al., 2012).
Fatores como este exposto anteriormente só ilustram o aumento da demanda por dados geográficos, todavia, em um passado recente, a maioria das organizações provedoras de dados espaciais não tinham a real preocupação em produzir informações de uma forma que pudessem ser consumidas por pessoas que não as construíram. Fatores como: documentação falha de processos para construção de dados, armazenamento em formatos proprietários de softwares e, muitas vezes
desorganizados, fazem com que exista uma real dificuldade no compartilhamento e troca de informações espaciais.
Diante deste contexto, o advento do Spatial Data Infrastructure (SDI), ou em
Uma definição interessante sobre uma IDE pode ser encontrada no Global Spatial Data Infrastructure (GSDI), uma associação que promove a cooperação internacional e colabora com a criação de IDEs em diferentes escalas. Produz também GSDI Cookbook, espécie de guia para a construção de uma IDE, conforme
citação abaixo:
“O termo Infraestrutura de Dados Espaciais (IDE), é frequentemente usado para designar a coleção de tecnologias, políticas e arranjos institucionais que facilitem a viabilidade e o acesso aos dados geográficos. A IDE fornece uma base para a descoberta de dados geográficos, avaliação e aplicação para os usuários e provedores em todos os níveis de governo, setor comercial, setor sem fins lucrativos, universidades e cidadãos em geral.” (GSDI, 2004, tradução do autor).
Uma IDE é muito mais do que simplesmente um conjunto de amostras ou banco de dados e vai além do levantamento e mapeamento; na prática fornece um ambiente onde organizações/ nações interagem, via tecnologia, para promover o uso, gerenciamento e produção de mecanismos para busca, acesso à dados, além de serviços ou softwares para suportar a comunicação (GSDI, 2004; Rajabifard et al.,
2006).
Inicialmente, as Infraestruturas de Dados Espaciais contavam com uma metodologia de modelagem baseada na estrutura top-down (Rajabifard et al., 2006). Após alguns
desenvolvimentos, percebeu-se que esse modelo não mais satisfazia às necessidades intrínsecas a uma IDE. Neste momento houve uma evolução para a segunda geração de IDE, na qual a modelagem transformou-se à uma orientação a processos e sua visão denominada bottom-up, a partir de Infraestruturas de Dados
Espaciais locais para subsequente construção de uma estrutura nacional ou global (Rajabifard et al., 2006). Crompvoets et al. (2004) discorrem sobre algumas experiências desenvolvidas em diversos países e reafirmam esta tendência da mudança de estratégia da primeira geração de IDEs, orientada a produtos e dados, para uma estrutura mais orientadas às aplicações e seus usuários.
Iniciativas que privilegiam os conhecimentos locais são valorizadas pela riqueza de aplicações e diversidade de interesses impondo novos requisitos às IDEs. Diferentemente das questões relativas às propostas de IDE nacionais, as propostas locais requerem um maior detalhamento e, com isso, um maior acesso a diferentes fontes de dados, mantidas por diversos provedores (Davis e Alves, 2005).
recentemente, haja uma convergente demanda por modelos de Infraestruturas de Dados Espaciais locais orientadas a serviços (Davis e Alves, 2005; Vaccari et al., 2008; Chan et al., 2001). Os autores, ao analisarem as diversas definições de IDE, já mencionavam a falta de uma perspectiva de serviços nessas definições.
Masser et al. (2008) mencionam que o desenvolvimento de Infraestruturas de Dados Espaciais efetivas deve servir de forma transparente como suporte para a vasta maioria da sociedade que não é familiarizada com conceitos sobre consultas espaciais. Essas estruturas devem ser aprimoradas de tal forma que seja possível compartilhar, adicionalmente aos dados, estratégias, processos, operações, produtos de valor agregado, dentre outros.
As IDEs são construídas, portanto, para possibilitar a troca de informações em diversas escalas, conforme é possível observar na Figura 1 a seguir:
Figura 1. Hierarquia de IDE, adaptado de (Rajabifard, 2006).
Embora esta figura ajude a explicar a estrutura de uma IDE, é importante ressaltar que atualmente não existe uma real hierarquia entre as mesmas; de alguma forma, as Infraestruturas de Dados Espaciais se conectam e são construídas de forma paralelas.
Figura 2. Diagrama representando as etapas da IDE, adaptado de (Hjelmager et al., 2008).
Este usuário destacado na Figura 2 pode assumir diversos papéis, dependendo do tipo de interação que será feita com a IDE, segundo Hjelmager et al. (2008):
Produtor: usuário que produz dados para uma IDE;
Provedor: usuário que provê dados ou serviços para ser consumido por uma IDE;
Desenvolvedor: usuário que adiciona novas funcionalidades para um produto existente ou desenvolve um novo e torna isto disponível na IDE;
2.2 ARQUITETURA BASEADA EM SERVIÇOS
2.2.1 Serviços Web
A construção de uma IDE tem, conforme citado anteriormente, como um dos principais objetivos facilitar o acesso e a troca de informações espaciais provenientes de diversas fontes de dados. Além disso, deve conter ferramentas que permitam ao usuário realizar buscas por informações espaciais específicas, conforme interesse.
A heterogeneidade de dados espaciais atualmente não é uma exceção e pode ser classificada como: sintática (formatos distintos de dados), estrutural (diferenças de esquemas) e semântica (diferença de termos em contextos específicos). Tais informações espaciais são provenientes de diversas bases de dados, que na maioria das vezes, se encontram em distintos formatos (normalmente associados à softwares específicos), escalas e precisão cartográfica diferentes, o que torna a integração e o compartilhamento de dados espaciais algo não tão trivial (Vaccari et al., 2008).
Especificamente em relação à questão sintática, algumas tentativas foram desenvolvidas no sentido de se criar formatos neutros, independentes de tecnologia, como o OpenGIS e Geography Markup Language (GML), que permitisse que o SIG
escolhido dispusesse apenas de um leitor/conversor de um formato de dados específico à outro, como ilustra Câmara e Junior (2002). Todavia, esta metodologia, sem o apoio da organização e controle de um Sistema Gerenciador de Banco de Dados, faz com que múltiplas versões do mesmo dado sejam criadas gerando uma grave ingerência de informação.
Arquitetura Orientada a Serviços ou, em inglês, Service Oriented Architeture (SOA),
tem sido bastante utilizado por facilitar a integração dos serviços entre vários sistemas e também a possibilidade de escalonar o sistema sem modificar o núcleo da aplicação. Davis e Alves (2005) exemplificam este conceito:
“Serviços, acompanhados de suas descrições e operações fundamentais,
tais como descoberta, seleção e chamada, constituem a base da SOA. A arquitetura suporta sistemas grandes com compartilhamento de dados e de capacidade de processamento, através da alocação distribuída de aplicações e recursos computacionais através de redes de computadores. (...) Serviços podem ser primários, se programados em uma linguagem de programação qualquer e independentes de outros serviços, ou compostos,
se parte do seu processamento depender de outros serviços”.
Tais serviços Web ou também conhecidos como, em inglês, Web Services são parte
integrante desta arquitetura, utilizando os principais padrões abertos adotados mundialmente na Internet, e facilitam, portanto, o intercâmbio de dados entre sistemas, aplicativos, etc. Alguns dos principais formatos são:
Hypertext Transfer Protocol (HTTP): protocolo para conexão, distribuição,
colaboração, transferência e comunicação (HTTP, 2013).
eXtensible Markup Language (XML): formato baseado em texto simples para
representar/descrever informações estruturadas como documentos, dados, configuração, transações, entre outros (XML, 2013).
Web Services Definition Language (WSDL): é um arquivo no formato XML
usado para descrever os serviços (WSDL, 2001).
Universal Description, Discovery and Integration Protocol (UDDI): é um
protocolo que permite promover, usar e compartilhar serviços via Web (UDDI, 2006);
Uniform Resource Identifier (URI): é o pilar da arquitetura Web pois provê a
identificação única que é utilizada por todos na Web (URI, 2004).
2.2.2 Geo Serviços
Especificamente para a questão espacial, o Open Geospatial Consortium (OGC),
buscando, principalmente, garantir a interoperabilidade de dados permitindo que diferentes sistemas tenham a capacidade de trocar informações e instruções em tempo real, sem necessidade de transformação de dados.
Tal arquitetura aberta é comumente denominada de framework de serviços da OGC
e composta por três operações principais, como mostra a Figura 3:
Figura 3. Arquitetura de uso de serviços, adaptado de (OGC, 2011).
Serviços: publicação dos serviços e dados para um diretório (como registro e catálogo) e posterior fornecimento para os consumidores.
Consumidor de Serviços: realiza operações de descoberta no gerenciador (broker) para encontrar serviços específicos que necessita. Normalmente a
pesquisa é feita sobre os metadados para se buscar aquilo que se deseja.
Diretório de Serviços: uma espécie de intermediário entre o provedor do serviço e o consumidor.
O framework da OGC é responsável por identificar serviços, interfaces e
intercâmbios de protocolos que podem ser usados por qualquer aplicação que tenha sido desenvolvida para ler determinado padrão. Tais instruções seguem estrutura pré-definida no arquivo XML e as requisições também são padronizadas. Por exemplo, a URL abaixo mostra uma requisição sendo feita na interface cliente seguindo o padrão OGC, para um servidor específico do softwareMap Server:
http://demo.mapserver.org/cgibin/foss4g?&SERVICE=WMS&VERSION=1.1.1&REQ
A Uniform Resource Locator (URL) segue, como supracitado, o padrão OGC e cada
parâmetro tem uma função (instrução) específica, conforme detalhado abaixo:
http://demo.mapserver.org: servidor de onde está sendo feita a requisição;
SERVICE = WMS: representa o tipo de serviço OGC, neste caso, WMS;
VERSION = 1.1.1: versão do serviço;
REQUEST = GetMap: representa a requisição do mapa. Há também outras formas de requisição como o getcapabilities que descreve alfanumericamente as propriedades contidas no serviço específico;
LAYERS = OSM_Denver: descreve qual é a feição cartográfica desejada;
SRS = EPSG1: 4326: parâmetro que descreve o Sistema de Coordenadas, neste caso em específico, Sistema de Coordenadas Geográfico e Datum WGS84;
BBOX = -105.208290,39.542378,-104.769779,39.980889: definição da área geográfica desejada;
FORMAT = image/png: parâmetro que define o formato do resultado, que neste caso é png.
A Figura 4 representa o resultado da requisição:
Figura 4. Mapa resultante da requisição no browser de um serviço WMS.
Alguns dos principais serviços providos pela OGC, denominados também de OGC Web Services (OWS) ou mesmo Geoserviços, são:
Web Map Service (WMS) - retorna as feições geográficas no formato raster
(imagem);
Web Feature Service (WFS) - retorna as feições geográficas no formato
vetorial;
Web Feature Service Transaction (WFS-T) - é complementar ao WFS, porém
suporta operações de edição cartográficas como inserção, edição e exclusão;
Catalog Service for Web (CSW) - provê as informações contidas nos
metadados, permitindo a pesquisa, consumo, download, etc., de dados;
Web Coverage Service (WCS) - é representado pelo formato raster e
representam fenômenos com variação no tempo/espaço, como dados climáticos, por exemplo;
Web Processing Service (WPS) - pode-se ser resumido com uma sequência
de regras que devem ser seguidas a partir da requisição do usuário final. Tais requisições podem variar de análises raster, como uma detecção de mudança
temporal ou mesmo o cruzamento espacial de vetores;
Web Map Tile Service (WMTS) - semelhante ao WMS, porém tem como
principal objetivo pré-processar o dado raster (imagem), também denominado
de cache, para garantir o aumento de desempenho no consumo da informação.
Para mais detalhes sobre estes e outros serviços mais específicos no padrão OGC, atentar-se para OGC (2011).
A Figura 5 ilustra a arquitetura de requisição de um serviço específico feito pelo usuário cliente. Uma vez que o usuário, por exemplo, altera o valor de escala se aproximando ou se afastando do mapa, automaticamente uma requisição é enviada para o servidor de aplicações (normalmente um software de mercado ou livre como: Intergraph GeoMedia WebMap, Esri, MapServer, etc.) que é responsável em realizar
Figura 5. Arquitetura de requisição de serviço, adaptado de (OGC, 2011).
2.2.3 Geoportal
O conceito de Geoportal resume-se basicamente ao que foi previamente discutido no item “2.1 Infraestrutura de Dados Espaciais”, ou seja, como parte dos conceitos intrínsecos da construção de IDEs, pois contempla algumas características elementares como: arquitetura baseada em serviços, funcionalidades básicas para que os usuários possam visualizar, medir, etc., e também com o propósito de distribuir informações espaciais e alfanumérica de forma simples e rápida. De uma maneira geral, denominações como Portal de Informações Espaciais, Atlas Geográfico, Atlas Ambiental, etc., podem ser interpretados como parte dos conceitos de IDEs.
Portais são websites que podem ser entendidos como uma "porta de entrada" para a
busca das mais diversas informações como dados, notícias, tutoriais, ferramentas, etc., além de serem ambientes Web que permitem que organizações e comunidades possam interagir compartilhando e trocando informações pertinentes a determinado assunto (Maguire e Longley, 2005). Especificamente para a questão espacial, o Geoportal pode ser definido como um website que representa um ponto de entrada
A criação do European Commission’s INfrastructure for SPatial InfoRmation in Europe (INSPIRE), espécie de órgão regulador europeu, incentivou a criação de
diversas IDEs nas mais diferentes escalas: locais, regionais e nacionais (Masser 2010). Exemplos como (Poland Geoportal, 2013; Nature SDI Plus, 2013; Sakkopoulos et al., 2012; Geoportal de Chile, 2013) apenas ilustram a algumas implementações de portais ao redor do mundo.
Maguire e Longley (2005) chegam a ressaltar a possibilidade de dividir o Geoportal em dois grupos: Geoportais de Aplicações e Geoportais de Catálogo, na qual o primeiro contempla ferramentas de análise e consumo de informações geográficas via Web Services e o segundo é referente a organização e gerenciamento das
informações de forma estrutural. Para maiores detalhes sobre os conceitos e arquiteturas de Geoportais recorrer a (Bernard et al., 2005; Maguire e Longley, 2005; Tait, 2005).
Figura 6. Arquitetura resumida de um Geoportal dentro de uma IDE.
A arquitetura apresentada é composta por dois Banco de Dados, sendo o primeiro alfanumérico (metadados) e o segundo contendo informações geográficas (vetores e imagens de satélite e/ou fotografias aéreas) provenientes de importação via Extract, Transform and Load (ETL) e inserções manuais. Tais informações podem ser
utilizadas pelo usuário final do Geoportal por meio da interação entre a Camada de Serviços, responsável em disponibilizar as diversas funções e operações baseado em Web services, e a Camada de Aplicação (SOA) que recebe as requisições e
interage com os bancos de dados, retornando a informação requisitada; sendo possível ainda se definir controle de acesso às informações por parte do usuário.
2.3 CONCEITO E IMPORTANCIA DE METADADOS
todavia, sem estes detalhes praticamente se torna uma informação não valiosa, sem valor (GSDI, 2004).
Os Metadados representam as informações sobre o dado e qualquer descrição sobre quem, como, quando, porque, produziu um dado são exemplos destes. Segundo o Decreto Lei nº 6.666 de 27 de Novembro de 2008, instituída no âmbito do Poder Executivo Federal, metadados representa o:
“conjunto de informações descritivas sobre os dados, incluindo as características
de seu levantamento, produção, qualidade e estrutura de armazenamento, essenciais para promover a sua documentação, integração e disponibilização,
bem como possibilitar sua busca e exploração”.
A importância da existência de metadados é novamente abordada por GSDI (2004): Ajudam a organizar e manter o investimento de uma organização, como
também, provê informações sobre determinado dado; Evita a duplicação de esforços;
Possibilidade de localizar/ disponibilizar dados geoespaciais e associados relevantes; para a área de interesse;
Provedores de dados são capazes de informar e promover a disponibilidade de seus dados e agregar-se a serviços existentes (relatórios de texto, imagens, mapas na web).
Quando se pensa especificamente em metadados no contexto espacial, alguns outros parâmetros são agregados, como por exemplo:
Quem criou os dados?
Qual o conteúdo e porque foi criado?
Quando foi criado? (levando em consideração a época do levantamento do dado)
Qual sua localização espacial?
Qual é o Sistema de Coordenadas utilizado? Qual é sua precisão cartográfica?
Estes metadados para serem devidamente utilizados, devem seguir uma padronização de armazenamento internacional. Estes padrões auxiliam no entendimento, no acesso e na interoperabilidade por meio de softwares e aplicações
mas também distintos em outros aspectos como distintas regras de preenchimento (campos obrigatórios e opcionais), por exemplo.
O padrão Federal Geographic Data Committee (FGDC, 2000), desenvolvido em
1994 nos Estados Unidos, é comumente adotado no desenvolvimento de IDEs em países como Estados Unidos, Canadá e Reino Unido. Tal padrão organiza os dados em 7 (sete) diferentes seções, conforme Figura 7:
Figura 7. Composição das seções referentes ao padrão FGDC e suas obrigatoriedades, adaptado de (FGDC, 2011).
1. Identificação: Informações básicas sobre o conjunto de dados. Onde os dados originaram-se? Como está atualmente o dado? Para quais propostas foram criadas? Qual a área de cobertura do dado?
2. Qualidade do Dado: Uma avaliação da qualidade dos dados. Como está a precisão? Quais os passos foram seguidos para coletar os dados? Como foi à entrada de dados?
3. Organização dos Dados Espaciais: Como o dado espacial está representado? Quais objetos foram usados para representá-lo?
4. Referência Espacial: A descrição do sistema de referência, sistema de coordenadas e parâmetros de projeção utilizados.
5. Entidade e Atributos: Quais os tipos de entidade e atributos que fazem a descrição do dado?
7. Referência dos Metadados: Informação sobre os metadados. Quando foi que o registro de metadados foi criado? Quem é o responsável? Quando foi a última atualização?
Outro padrão muito popular de metadados é o ISO 19115:2003 (ISO, n2011), especificado pelo Comitê Técnico 211 (TC 211) da ISO. Utiliza de linguagem de modelagem Unified Modeling Language (UML) para representar suas seções,
entidades e elementos de metadados. Segundo CONCAR (2009):
“A norma ISO 19115:2003 combina aspectos de muitos outros padrões de
metadados, visando um padrão universal para o armazenamento e distribuição de metadados geoespaciais. (...) o padrão ISO 19115 apresenta diferenças marcantes em sua implementação, através do recurso de modelagem orientada a objetos (...) é um padrão verdadeiramente internacional; faz parte de um conjunto de normas afins (suíte) concernentes ao armazenamento, troca e manuseio de informações geográficas; prevê o apoio a diferenças culturais e linguísticas, contemplando culturas, áreas de aplicação, profissões, etc., não apenas
pela especificação da linguagem dos metadados”.
No Brasil, a Infraestrutura Nacional de Dados Espaciais (INDE) está em pleno desenvolvido, sob a tutela da Comissão Nacional de Cartografia (CONCAR) e dentre as diversas padronizações que estão vinculadas à INDE, uma delas é o uso de metadados seguindo a norma ISO 19115:2003, com o objetivo estrutural de garantir e identificar o produtor e responsabilidades técnicas de produção de dados, padronizar terminologia, possibilitar o compartilhamento e transferência de informação, entre outros.
A CONCAR, por meio de um comitê especializado denominado Comitê de Estruturação de Metadados Geoespaciais (CEMG) criou o Perfil de Metadados Geoespaciais do Brasil (Perfil MGB), que nada mais é do que um conjunto básico e obrigatório de elementos que retratem as características de determinada informação geoespacial de uma área específica e garanta sua identificação, avaliação e utilização consistente por todos aqueles que desejarem.
As seções que fazem parte do Perfil MGB (CONCAR, 2009), segundo a norma ISO 19115 são:
- MD_Metadata - Informações do Conjunto de Entidades de Metadados: define metadados de um produto e estabelece hierarquia;
- MD_Constraints - Informações de Restrições: restrições legais e de segurança no acesso e no uso dos dados;
- DQ_DataQuality - Informações de Qualidade dos Dados: descreve sua linhagem (fontes e processos de produção) e qualidade/ teste dos dados; - MD_MaintenanceInformation - Informações de Manutenção dos Dados:
descreve práticas de manutenção e atualização;
- MD_SpatialRepresentation - Informações de Representação Espacial: descreve mecanismo usado para representar os dados geoespaciais (matricial ou vetorial);
- MD_ReferenceSystem - Informações do Sistema de Referência: descreve sistema de referência espacial e temporal usado;
- MD_ContentInformation - Informações de Conteúdo: descreve conteúdo do(s) catálogo(s) de abrangência e de feições usado(s) para definir feições de dados geoespaciais;
- MD_Distribution - Informações do Distribuidor: informações do distribuidor e métodos de acesso.
Portanto, para o desenvolvimento desta pesquisa foi utilizada a norma ISO 19115:2003, especificamente o Perfil MGB, por se tratar de um padrão verdadeiramente internacional, além de contemplar conjunto de normas de armazenamento, troca e manuseio de informações geográficas e, sem dúvida, ser aderente aos desenvolvimentos que estão sendo realizados em âmbito nacional com a própria INDE.
2.3.1 Metadados na área ambiental
Como dito previamente, metadados são utilizados para documentar e disponibilizar informações sobre algum dado específico. Para se documentar determinado dado é imprescindível seguir algum tipo de padrão, metodologia, etc., mas que não ocorre na maioria das vezes.
Não padronização de metodologia no levantamento de dados ecológicos; Diferentes propósitos dos estudos;
Grande variação de extensão, detalhes e qualidades dos dados podem ser encontrados;
Amostras de tempo e espaço distintas;
Diversidade de formato de dados e sistemas proprietários;
Número cada vez maior de dados está sendo levantados por cientistas, instituições, etc., e precisam ser organizadas;
Dados armazenados informalmente em arquivos Microsoft Excel, anotações mentais ou cadernos, entre outros.
Com o objetivo de superar esta situação, algumas propostas foram estabelecidas. Dentre as diversas ações sobre o tema, vale a pena destacar a iniciativa desenvolvida pelo National Center for Ecological Analysis (NCEAS) e Long Term Ecological Research Network (LTER), que criaram a chamada Linguagem Ecológica
de Metadados (EML). O principal intuito é fornecer um método para formalizar e padronizar os conceitos que são essenciais para descrever os dados ecológicos. Com a padronização proposta, é possível que cientistas, ecólogos e o público em geral possam ter acesso à levantamentos realizados em diferentes áreas, épocas, projetos, entre outros, de uma maneira simples e rápida, através do principal portal de acesso desenvolvido para o projeto2.
A projeto desenvolvido pela The Georgia Coastal Ecosystems (GCE) se propõe a
integrar o modelo EML aos arquivos de metadados existentes no Banco de Dados atual. Além disso, foi criada uma interface chamada GCE Data ToolBox com o
objetivo de facilitar a busca por metadados, utilizando critérios tanto alfanuméricos (data, tipo, etc.), como espaciais.
Todavia, tal linguagem, por mais que se proponha a se integrar com os diversos padrões estabelecidos (FGDC, ISO), e também tenha possibilidade de armazenar algumas informações espaciais, ainda carece de soluções que agreguem a questão espacial dos dados. Iniciativas realizadas pela Universidade do Colorado e Prefeitura de Seattle (Van Buren, 2002), ambos nos Estados Unidos, tentaram
2
realizar uma integração entre EML e SIG, porém de maneira muito incipiente e os projetos foram descontinuados por questões de investimento econômico no projeto. Outras iniciativas como o MarineXML, desenvolvido pela International Oceanographic Data (IOC) e o Information Exchange Committee of the Internacional Oceanographic Commission (IODE) da UNESCO, tem como principais objetivos criar
uma linguagem comum que permita a troca de dados entre a comunidade marinha. Millard et al. (2005) descrevem de maneira bem interessante o desenvolvimento da linguagem denominada MarineXML, inclusive com sua integração com padrões espaciais como é o caso do GML. Tal estudo, também destaca os trabalhos desenvolvidos por outros grupos, como: Monterrey Bay Aquarium Research Institute
(MBARI), Marine Information Mark-up Language (MIML) e Ocean Biogeographic Information System (OBIS).
Estes padrões de metadados pré-estabelecidos possuem o mesmo fundamento, ou seja, são desenvolvidos a partir de uma linguagem comum XML, o que facilita a interoperabilidade entre eles, por se tratar de uma linguagem aberta. A maioria destes padrões de metadados, sejam eles voltados à área ambiental ou não, normalmente possuem interface para preenchimento de dados e posterior armazenamento. Se necessário for exportá-lo, usa-se a linguagem XML como formato de troca entre informações de distintos padrões.
De qualquer maneira, seja qual for o modelo de metadados utilizado, é necessário que os dados estejam preenchidos e documentados, com o intuito de possibilitar a troca e consumo destas informações em estudos futuros. (Bruce e Kroon, 2006; Mount e Bricher, 2008) seguem neste caminho e ilustram, entre outros assuntos, as informações significativas para serem inseridas nos metadados dos seus projetos. Exemplificam o preenchimento de valores específicos para cada tipo de dado, informando: origem, versão, extensão, sistema de coordenadas, entre outros dos dados existentes, vinculados a área ambiental.
Seeley et al. (2008) mostram, de maneira muito interessante, as melhores práticas para documentar e possibilitar a troca de informações espaciais marinhas. Sugerem quais são os metadados essenciais para as diversas fontes ambientais existentes, ilustrando como trabalhar e organizar arquivos provenientes de formatos Microsoft Excel - muito utilizado por pesquisadores para armazenar os frutos dos estudos
Dados Espaciais. Entre as informações comuns que, segundo os autores, devem ser preenchidos, estão:
Nome do Projeto e Data de construção; Arquivo Excel de origem;
Organização que gerou o dado, se aplicável; Data da origem;
Quando o dado foi processado; Quem processou o dado;
Referências usadas para identificar as versões dos dados; Quando o dado foi validado;
Quem validou o dado; Data da validação.
2.4 BANCO DE DADOS GEOGRÁFICOS
A evolução da tecnologia proporcionou um acesso mais rápido e fácil a dados espaciais. Este significativo aumento, por um lado, facilita o acesso à dados geoespaciais por parte do público em geral, mas por outro, influencia diretamente na dificuldade de intercâmbio destas informações produzidas, sob diferente perspectivas, àqueles que irão acessá-las, uma vez que estes dados podem estar em diferentes padrões de software, sem documentação de sua produção.
Câmara e Júnior (2002) evidenciavam suas preocupações com a busca por padrões no armazenamento e troca de informações espaciais entre os produtores:
“Um dos desafios mais importantes no uso das geotecnologias é o intercâmbio de dados espaciais, impulsionado principalmente pelo alto custo de produção deste tipo de dado. A falta de modelos conceituais comuns acarreta problemas na troca de dados entre organizações utilizando Sistema de Informação Geográfica (SIGs) distintos, que incluem distorção de dados, comprometimento de qualidade da informação, perda de
definições de atributos e georreferenciamento”.
crescente preocupação por padronização e acessibilidade de dados geoespaciais fez com que fosse criada a INDE. Dentre as atividades em andamento, uma delas é a definição do Perfil MGB para metadados, conforme já supracitado no item “2.3 Conceito e Importância de Metadados”.
Além disso, pode-se destacar a Especificação Técnica para a Aquisição de Dados Geoespaciais Vetoriais (ET-EDGV) que:
“tem por objetivo padronizar e orientar todo o processo de aquisição da geometria
dos vários tipos de dados geoespaciais vetoriais, presentes na Especificação Técnica para Estruturação de Dados Geoespaciais Vetoriais (ET-EDGV), da CONCAR, para qualquer que seja o insumo a ser utilizado (levantamento de campo, fotografias aéreas, imagens de sensores orbitais, etc.), visto que os
processos de aquisição são similares.” (Lunardi et al., 2009).
Diante deste contexto, será explanado a seguir a respeito da modelagem conceitual de dados geoespaciais, sua estruturação física e as necessidades de transformações de formatos para a adequação ao modelo definido.
2.4.1 Modelagem Conceitual de Dados Geográficos
Um modelo de dados, seja este com características geográficas ou não, é referente ao processo de abstração na qual apenas os elementos essenciais da realidade para um determinado estudo são considerados (Lisboa Filho e Iochpe, 1999).
Figura 8. Processo de Abstração para a construção do Modelo de Dados (Câmara et al., 2005).
Nível do Mundo Real: Contém os fenômenos reais a abstrair, como hidrografia, mancha urbana, vegetação, entre outros.
Nível de Representação: Conjunto de conceitos formais com os quais as entidades geográficas podem ser modeladas, da forma como são percebidas pelo usuário.
Nível de Apresentação: Define-se a questão simbológica de apresentação de como os fenômenos geográficos devem assumir em uma aplicação após sua modelagem.
Nível de Implementação: Ambiente que utiliza os três itens acima descritos para se definir a forma de armazenamento e relacionamento entre a estrutura de tabelas, além de funções e métodos necessários ao sistema. Este é o ambiente desenvolvido no item 2.4.2 Implementação Física do Banco de Dados Espacial.
Uma vez implantado, o modelo de dados se assemelha a Figura 9, a seguir:
Figura 9. Níveis de Abstração de Dados Geográficos (Câmara et al., 2005).
espaciais desde 1980, uma vez que, bem definidos, auxiliam substancialmente na construção do Banco de Dados Espacial. Algumas propostas de modelagem conceitual para SIG são citadas e discutidas por (Lisboa Filho e Iochpe, 1999; Borges et al., 2001; Câmara et al., 2005) como: Entidade-Relacionamento (ER), Orientado a Objeto (OO), OMT-G (Object Modeling Technique for Geographic Applications), IFO (Modelo Semântico Formal de Banco de Dados), GeoFrame,
GISER (Geographic Information System Entity Relational), entre outros.
Dentre os modelos citados, após revisão bibliográfica, notou-se que os mais utilizados são o GeoFrame e o OMT-G. Pelo fato da própria ET-ADGV ser definida sobre o modelo OMT-G, o presente estudo decidiu-se por seguir o mesmo caminho (Lunardi et al, 2009).
O OMT-G é um Modelo Orientado a Objetos estendido com a parte geográfica baseado no modelo UML e:
“provê primitivas para modelar a geometria e a topologia dos dados geográficos, oferecendo suporte a estruturas topológicas “todo-parte”,
estruturas de rede, múltiplas representações de objetos e relacionamentos espaciais. Além disso, o modelo permite a especificação de atributos alfanuméricos e métodos associados para cada classe. Os principais pontos do modelo são sua expressividade gráfica e sua capacidade de codificação, uma vez que anotações textuais são substituídas pelo desenho de relacionamentos explícitos, que denotam a dinâmica da interação entre os diversos objetos espaciais e não espaciais.” (Câmara et al., 2005).
Para se construir um diagrama de classes, que tem por objetivo representar um determinado modelo que seja aderente a um assunto específico, como o tema de Macrobentos, por exemplo, é necessário utilizar alguns conceitos, cada qual com sua simbologia específica, conforme Figura 10.
Objeto: entidade do mundo real;
Classe de objetos: representa entidades de mesma característica (atributos, operações);
Associações: relacionamento entre classes;
Figura 10. Notação gráfica do Diagrama de Classe UML (Lisboa Filho, 2000).
No modelo OMT-G, existem dois tipos distintos de classes de objetos: convencionais ou georreferenciadas. A primeira descreve um conjunto de objetos que possuem alguma relação com objetos espaciais, mas que não possuem propriedade geométrica e a segunda, descreve um conjunto de objetos que possuem representação espacial.
Ainda para este tema, (Borges et al., 2001; Câmara et al., 2005) sugerem uma especialização da classe georreferenciada, utilizando o conceito de herança da orientação a objetos, em classes do tipo geo-campo e geo-objeto, onde:
Geo-campo: correspondem a objetos distribuídos continuamente pelo espaço, como topografia (curvas de nível), tipos de solo, geologia, entre outros.
Geo-objeto: correspondem a objetos geográficos identificáveis e localizáveis que podem ser individualizados, como localização de árvores, eixos de ruas, quadras, entre outros.
Figura 11. Diferenciação entre Classes Geográficas e Convencionais (Câmara et al., 2005).
As Figura 12 e Figura 13 a seguir, ilustram as representações simbológicas definidas para as subclasses:
Figura 12. Exemplos de Representações de Geo-Campo (Câmara et al, 2005).
Figura 13. Exemplo de Representação de Geo-Objeto (Câmara et al., 2005).
2.4.2 Implementação Física do Banco de Dados Espacial
Atualmente o termo Banco de Dados é sinônimo para o termo Sistema Gerenciador de Banco de Dados (SGBD) que contempla, além dos próprios dados, uma interface (software) para acesso e manipulação das informações. Isto se dá principalmente
pelo fato de que a velocidade na produção e a enorme quantidade de dados, seja este espacial ou não, necessita não só um bom ambiente para armazenamento, mas que também possa ser de fácil acesso por parte do usuário final.
A implementação de um SGBD permite que seja feito o compartilhamento de dados, segurança de acesso, backup e recuperação à falhas, padronização de dados,
controle de acessos simultâneos, regras de integridades, facilidade de manutenção, desempenho, controle de redundância, entre outros (Câmara et al., 2005; Gutting, 1994). Atualmente, quando se imagina desenvolver soluções em ambientes corporativos que tenham estas características, o SGBD é utilizado.
No que tange ao armazenamento de dados espaciais, o uso de aplicações, como citadas anteriormente, fazem parte da arquitetura de um SIG. Na prática, o armazenamento espacial é uma extensão do SGBD que permite com que geometrias sejam armazenadas.
A Figura 14 ilustra um exemplo de uma arquitetura dual onde o armazenamento de
dados espaciais é integrado com SGBD:
Neste exemplo, os dados espaciais são armazenados separadamente dos dados alfanuméricos e a integração é feita utilizando um identificador comum, na qual o Núcleo SIG é responsável pela junção de ambos e a visualização é realizada pelo usuário por meio uma interface gráfica Graphical User Interface (GUI). Esta
arquitetura foi utilizada durante muito tempo por tecnologias como Intergraph MGE, AutoCAD, entre outras, e alguns problemas são intrínsecos a este modelo, como
(Davis e Oliveira, 2002; Câmara et al., 2005) ilustram:
Se um usuário acessar diretamente um arquivo CAD, este poderá inserir ou apagar um registro que não terá vínculo com o SGBD (observar linha tracejada entre usuário e arquivos CAD);
Da mesma forma, se um administrador acessar diretamente um SGBD e inserir ou apagar um registro, este não terá vínculo com o desenho armazenado;
A única maneira de manter a integridade das informações é por meio do Núcleo SIG;
O conceito de Indexação e Função espaciais não é gerenciado pelo SGBD; Dificuldade de interoperabilidade entre diferentes dados, pois normalmente as
geometrias são armazenadas de maneira proprietária, no padrão do software utilizado.
Conforme é possível observar, este modelo implementado possuía alguns problemas que necessitavam ser superados e com a evolução para uma arquitetura integrada, como define Câmara et al., (2005), foi possível realizar a junção das informações espaciais e alfanuméricas em um único SGBD.
Esta mudança possibilitou que dados espaciais, a partir deste momento, também fossem gerenciados pelo Sistema Gerenciador de Banco de Dados e, como vantagem, também usufruírem de todas as capacidades de um SGBD.
Figura 15. Sistema Gerenciador de Banco de Dados.
A arquitetura ainda pode ser mais bem aproveitada quando se tem a possibilidade de realizar operações de análises espaciais inerentes ao ambiente de SIG como cruzamento, intersecção, etc., no próprio Banco de Dados aumentando assim o desempenho. Sem a necessidade de processamento direto no ambiente cliente (desktop), permitirá que o usuário possua um computador com menor capacidade de
processamento.
Para evitar que o mesmo problema de interoperabilidade acontecesse nos casos de SGBD espaciais, ou seja, para garantir que as ferramentas não armazenassem as geometrias de uma forma proprietária, foi definido um padrão de armazenamento e acesso aos dados, independente de qual software SIG ou banco de dados se esteja
utilizando. O responsável pela definição e manutenção deste padrão é o próprio OGC. Este consórcio, também denominado de OpenGIS publica em seu Web Site a
relação de softwares e bancos de dados testados e considerados efetivamente
compatíveis (OGC, 2011).
Dentre os diversos Sistemas Gerenciadores de Bancos de Dados com Extensão Espacial estão o Oracle Spatial, PostGIS baseado no Postgresql, Microsoft Access, Microsoft SQL Server, IBM DB2 Spatial Extender e MySQL. Dentre as tecnologias
