Proposta de um Sistema de Informações Territoriais e Urbanas para as Políticas de Urbanismo, Habitação e Regularização Fundiária do DF

PROPOSTA DE SISTEMA DE INFORMAÇÕES TERRITORIAIS E URBANAS PARA AS POLÍTICAS DE URBANISMO, HABITAÇÃO E REGULARIZAÇÃO FUNDIÁRIA DO DF

MICHELLE URCINE DOS SANTOS MONOGRAFIA DE ESPECIALIZAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO DEPARTAMENTO DE ENGENHARIA ELÉTRICA

FACULDADE DE TECNOLOGIA UNIVERSIDADE DE BRASÍLIA

UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA ELÉTRICA

PROPOSTA DE SISTEMA DE INFORMAÇÕES TERRITORIAIS E URBANAS PARA AS POLÍTICAS DE URBANISMO, HABITAÇÃO E REGULARIZAÇÃO FUNDIÁRIA DO DF

MICHELLE URCINE DOS SANTOS

ORIENTADOR: ROMUALDO ALVES PEREIRA JÚNIOR

MONOGRAFIA DE ESPECIALIZAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO

PUBLICAÇÃO: MTARH.M - 017 A/99 BRASÍLIA/DF: AGOSTO DE 2015 ii

UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA ELÉTRICA

PROPOSTA DE UM SISTEMA DE INFORMAÇÕES TERRITORIAIS E URBANAS PARA AS POLÍTICAS DE URBANISMO, HABITAÇÃO E REGULARIZAÇÃO FUNDIÁRIA DO DF

MICHELLE URCINE DOS SANTOS

MONOGRAFIA DE ESPECIALIZAÇÃO EM GESTÃO DA TECNOLOGIA DA

INFORMAÇÃO

SUBMETIDA

AO

DEPARTAMENTO

DE

ENGENHARIA ELÉTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE BRASÍLIA COMO PARTE DOS REQUISÍTOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ESPECIALISTA.

APROVADA POR: _________________________________________________ PROF. DR. ROMUALDO ALVES PEREIRA JÚNIOR, D.SC., UNB (ORIENTADOR)

_________________________________________________ PROF. MANOEL FERNANDO DA MOTA TENORIO PHD., UOFSC (EXAMINADOR INTERNO)

_________________________________________________ ANDERSON PEREIRA DA SILVA MSc., UNICAMP (EXAMINADOR EXTERNO)

BRASÍLIA/DF, 07 DE AGOSTO DE 2015

iii

FICHA CATALOGRÁFICA SANTOS, MICHELLE URCINE DOS Proposta de um Sistema de Informações Territoriais e Urbanas para as políticas de urbanismo, habitação e regularização fundiária do DF [Distrito Federal] 2015. xvii, 78p., 297 mm (ENE/FT/UnB, Especialização, Engenharia Elétrica, 2015). Monografia de Especialização – Universidade de Brasília. Faculdade de Tecnologia. Departamento de Engenharia Elétrica. 1. Sistema de Informação Geográfica

2. Banco de Dados Geográfico

3. Computação Distribuída

4. Padrões Abertos

I. ENE/FT/UnB

II. Título (série)

REFERÊNCIA BIBLIOGRÁFICA SANTOS, MICHELLE URCINE DOS (2015). Proposta de um Sistema de Informações Territoriais e Urbanas para as políticas de urbanismo, habitação e regularização fundiária do DF. Monografia de Especialização em Gestão da Tecnologia da Informação, Publicação MTARH.M-17A/99, Departamento de Engenharia Elétrica, Universidade de Brasília, Brasília, DF, 76p.

CESSÃO DE DIREITOS AUTOR: Michelle Urcine dos Santos. TÍTULO: Proposta de um Sistema de Informações Territoriais e Urbanas para as políticas de urbanismo, habitação e regularização fundiária do DF. GRAU: Especialista

ANO: 2015

É concedida à Universidade de Brasília permissão para reproduzir cópias desta monografia e para emprestar ou vender tais cópias somente para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte dessa dissertação de mestrado pode ser reproduzida sem autorização por escrito do autor. ____________________________ Michelle Urcine dos Santos CCSW 02, Lote 04, apt. 156 – Sudoeste. 72.680-250 Brasília – DF – Brasil.

iv

AGRADECIMENTOS A Deus pela dádiva da vida. A minha família, meus amigos e meu namorado pela compreensão e apoio. Aos meus colegas da turma de Gestão da Tecnologia da Informação, em especial, à equipe do LabRedes e ao Prof. Dr. Romualdo pelas orientações, compartilhamento do seu conhecimento. À Secretaria de Habitação, Regularização e Desenvolvimento Urbano e aos meus ex-colegas de trabalho Rener Garcia, Rafael Oliveira, Litz Mary, Felipe Araújo, Victor Vitalino, Keno Teixeira, André Vinícius, Elton Charles, Agnelo Fernandes e toda a equipe da Unidade de Tecnologia e da Subsecretaria de Informações Urbanas, afinal sem a colaboração de vocês esse trabalho não seria possível. Obrigada por tudo.

v

RESUMO PROPOSTA DE UM SISTEMA DE INFORMAÇÕES TERRITORIAIS E URBANAS PARA AS POLÍTICAS DE URBANISMO, HABITAÇÃO E REGULARIZAÇÃO FUNDIÁRIA DO DF Autor: Michelle Urcine dos Santos Orientadora: Profa. Dr. Romualdo Alves Pereira Júnior Programa de Pós-graduação em Gestão da Tecnologia da Informação Brasília, agosto de 2015 Há 50 anos, a tecnologia da informação era pouco presente na administração pública, em razão, muitas vezes, dos altos os custos do investimento em tecnologia para melhorar a gestão e automatizar processos. No entanto, a partir da década de 90, esse cenário muda rapidamente com a queda dos custos de produção de hardware e software, permitindo os governos e as empresas se beneficiarem de múltiplas bases de dados, sistemas e computação distribuída. Recentemente, a possibilidade de integrar e unificar informações de diversas fontes, atrelada a uma massa de dados maior e disponível nas instituições e empresas, abre a oportunidade para as análises de padrões a partir da adoção mais forte de sistemas de informações geográficas. Dessa maneira, o futuro requer cidades inteligentes, levando em consideração tecnologias que verifiquem a qualidade do ar, a energia usada, o tráfego em tempo real, sensores, a participação da população, mapas em 2 e 3D. Sendo assim, este trabalho é resultado de estudo baseado nessa nova perspectiva da tecnologia da informação. Comunicar, integrar, analisar e entender para onde a cidade cresce e como ela cresce, por meio do uso de sistemas de informações geográficas; estudar os fenômenos, entender os padrões e o comportamento de uma cidade, da cidade real à cidade legal. Objetiva-se empoderar os gestores do Governo do Distrito Federal para um planejamento urbanístico e habitacional mais justo.

vi

ABSTRACT PROPOSAL OF AN INFORMATION SYSTEM FOR UBAN AND REGIONAL POLICIES OF URBAN PLANNING, HOUSING AND ADJUSTMENT OF FEDERAL DISTRICT. Author: Michelle Urcine dos Santos Supervisor: Prof. Dr. Romualdo Alves Pereira Júnior Programa de Pós-graduação em Engenharia Elétrica Brasília, August of 2015 Fifty years ago, information technology was not very present in the public administration to be expensive investment in technology to improve the management and automate processes. However, from the nineties, the drop in hardware production costs and software allowed governments and companies to benefit from multiple databases, systems and distributed computing. Recently, the possibility to integrate and unify information from various sources, along with a higher and most available data mass on institutions and companies, creates the standards of analysis from the stronger adoption of geographic information systems. The future requires smart cities, considering technologies to check air quality, energy use, traffic in real time sensors, the population's participation, maps in 2D and 3D. Thus, this paper is based on this new perspective of information technology: to communicate, integrate, analyze and understand where and how the city grows through the use of geographic information systems; study the phenomena, understand the patterns and the behavior of a city, the real city and a legal city. Finally, the objective is also to train and provide knowledge managers of the Federal District for an urban planning and fairer housing.

vii

SUMÁRIO 1

- INTRODUÇÃO ....................................................................................................... 1 1.1

- PROBLEMA ............................................................................................ 2 1.1.1 - Contextualização do problema ..................................................... 2 1.1.2 - Enunciado do problema ................................................................ 4

1.2

- JUSTIFICATIVA .................................................................................... 4

1.3

- DELIMITAÇÃO DO TEMA.................................................................. 5

1.4

- OBJETIVO GERAL ............................................................................... 6

1.5

- OBJETIVOS ESPECIFICOS ................................................................. 6

1.6

METODOLOGIA ...................................................................................... 6 1.6.1 - Classificação da Pesquisa .............................................................. 6 1.6.2 - Percurso Metodológico .................................................................. 6

2

- REFERENCIAL TEÓRICO .................................................................................. 10 2.1

- GEOINFORMAÇÃO ............................................................................ 10 2.1.1 - Engenharia de Software .............................................................. 11 2.1.2 - Sistema de Informação Geográfica – SIG ................................. 14 2.1.3 - Arquitetura: Sistema Informações Geográficas - SIG ............. 18 2.1.4 - Modelagem de Dados Geográficos ............................................. 20 2.1.5 - Banco de Dados Geográfico ........................................................ 22 2.1.6 - Sistema de Informação Territorial - SIT ................................... 26

2.2

- COMPUTAÇÃO DISTRIBUÍDA ........................................................ 27 2.2.1 - Arquitetura Orientada a Serviços – SOA .................................. 27 2.2.2 Web - Service .................................................................................. 29 2.2.3 Computação em Cluster ................................................................ 29

2.3

- PADRÕES ABERTOS .......................................................................... 31 2.3.1 Interoperabilidade dos dados Geográficos .................................. 31

3

- REFERENCIAL TECNOLÓGICO ...................................................................... 36 3.1

- FERRAMENTAS DE MERCADO PARA WEB SIG ....................... 36

3.2

- Sistema Gerenciador de Banco de Dados – PostgreSQL ................... 38

3.3

- Banco de Dados Geográfico .................................................................. 39

viii

3.3.1 PostGis ............................................................................................. 39 3.4

- Aplicativos Geográficos......................................................................... 40 3.4.1 - ArcGIS/ArcSDE ........................................................................... 40

3.5

- Servidor de Mapas - Geoserver ............................................................ 42

3.6

- Ferramentas para o Desenvolvimento de Aplicações Web ................ 47 3.6.1 - Hypertext Markup Language 5 - HTML5................................. 47 3.6.2 - JavaScript ..................................................................................... 48 3.6.3 - Hypertext Preprocessor - PHP ................................................... 50

3.7

- Servidores Web ...................................................................................... 50 3.7.1 - NGinx ............................................................................................ 50 3.7.2 Tomcat ............................................................................................. 51

4

- DESENVOLVIMENTO ....................................................................................... 52 4.1

- Arquitetura do Siturb ........................................................................... 52

4.2

- Requisitos do Sistemas de Informações Territoriais e Urbanas do DF

- Siturb 4.3 Siturb 5

57 Protótipo Sistemas de Informações Territoriais e Urbanas do DF 60

- CONCLUSÕES E RECOMENDAÇÕES ............................................................. 68 5.1

- CONCLUSÕES GERAIS ..................................................................... 68

5.2

SUGESTÕES PARA TRABALHOS FUTUROS ................................. 68

REFERÊNCIAS .................................................................................................................. 69

ix

LISTA DE TABELAS Tabela 3.1 exemplo de um pedido getmap a um wms via get do geoserver ....................... 47 Tabela 3.1 - requisição getmap ........................................................................................... 57

x

LISTA DE FIGURAS Figura 1.1 - diagrama de percurso metodológico .................................................................. 7 Figura 2.1: Esquema sequencial do ciclo de vida clássico de um software ........................ 13 Figura 2.2 – As seis partes de um SIG ............................................................................... 17 Figura 2.3 - Arquitetura Clássica 3 Camadas de um Sistema de Software SIG ................. 19 Figura 2.4 - Arquitetura de Bancos de Dados em SIG ....................................................... 24 Figura 3.1 - Arquitetura do ArcSDE .................................................................................. 42 Figura 3.2 – Modelo OGC de Disponibilização de Dados Geoespaciais ............................ 43 Figura 3.3 – Protocolos Suportados pelo GeoServer........................................................... 44 Figura 3.4 – Arquitetura do Geoserver ................................................................................ 45 Figura 4.1 – Arquitetura Siturb 2009 .................................................................................. 53 Figura 4.2 – Arquitetura Siturb ........................................................................................... 54 Figura 4.3 – Tela de Login .................................................................................................. 61 Figura 4.4 – Usuários Cadastrados no Sistema ................................................................... 62 Figura 4.5 – Criando Usuário .............................................................................................. 62 Figura 4.6 – Editando Usuário ............................................................................................. 63 Figura 4.7 – Grupo de Usuários........................................................................................... 63 Figura 4.8 – Criando um Grupo de Usuários....................................................................... 64 Figura 4.9 – Exportação de um mapa em formatos SHP, JPG e PNG ................................ 64 Figura 4.10 – Geração de áreas de Proximidade ................................................................. 65 Figura 4.11 – Medição de Área ........................................................................................... 65 Figura 4.12 – Consulta de Dados Alfanuméricos ................................................................ 66 Figura 4.13 – Gerenciamento de Camadas .......................................................................... 67 Figura 4.14 – Visualização de Geocodificação ................................................................... 67

xi

LISTA DE ACRÔNIMOS API

Application Programming Interface

CONCAR

Comissão Nacional de Cartografia

E-Ping

Programa do Governo Eletrônico Brasileiro

ESRI

Environmental Systems Research Institute

GDF

Governo do Distrito Federal

GeoJSON

Geographic JavaScript Object Notation

GeoOOA

Object-Oriented Analysis for Geographic Information Systems

GiST

Generalized Serach Tree

GML

Geography Markup Language

GPS

Global Positioning System

GUI

Interface Gráfica do Usuário

HTML

Hypertext Markup Language

IDE

Infraestrutura de Dados Espaciais

INDE

Infraestrutura Nacional de Dados Espaciais

KML

Keyhole Markup Language

MTG-A

Modeling Technique for Geographic Applications

NoSQL

Banco não Relacional

OGC

Open Geospatial Consortium

OGC

Open Geospatial Consortium

PDOT

Plano Diretor de Ordenamento Territorial do Distrito Federal

REST

Representational State Transfer

SEDHAB

Secretaria de Habitação, Regularização e Desenvolvimento Urbano do DF

SFSQL

Simple Features for SQL

SGBD

Sistema de Gerenciamento de Banco de Dados

SGDB

sistemas relacionais de gerência de bancos de dados

SIG

Sistema de Informação Geográfica

SIT

Sistemas de Informação Territorial

SLD

Styled Layer Descriptor

SOA

Service-Oriented Architecture

SOAP

Simple Object Access Protocol

UDDI

Universal Description, Discovery and Integration

xii

UML

Unified Modeling Language

WCS

Web Coverage Service

WFS

Web Feature Service

WMS

Web Map Service

WSDL

Web Service Definition Language

XML

eXtensible Markup Language

XSL

Extensible StyleSheet Language

xiii

1

- INTRODUÇÃO

O propósito de construir uma nova cidade para abrigar a Capital Federal do Brasil iniciouse em 1823 por José Bonifácio; plano que foi revisto, posteriormente, em 1892, pelo astrônomo Luiz Cruls, na missão Cruls, e só implantado, em 1956, pelo então presidente do Brasil, Jucelino Kubistchek. O quadrilátero projetado por Lúcio Costa e aquitetado por meio dos desenhos de Oscar Nieymeyer levou a cidade de Brasília em 1987 a receber o título de Patrimônio Mundial da Humanidade pela Unesco –Organização das Nações Unidas para a Educação, a Ciência e a Cultura, em razão do seu conjunto urbanístico contemporâneo tão singular. Desde o nascedouro, Brasília representava a possibilidade de criação de uma nova alternativa

de

cidade

que

pudesse

consolidar-se

e

expandir-se

para

atender

satisfatoriamente suas funções, superando os problemas emergentes dos centros urbanos brasileiros. Muito além de um espaço organizado, Brasília comprometia-se a representar a unidade nacional, a sede do governo federativo, ideia descrita e apresentada por Lucio Costa em seu relatório. Por outro lado, com a expansão do sistema capitalista, as cidades passaram a ter um novo papel estratégico, sendo responsáveis pelo desenvolvimento do setor terciário, da indústria e da economia. Em decorrência do crescimento do capitalismo e dos mercados globais, principalmente, em países de terceiro mundo como o Brasil, as cidades globais se espalharam pelo país com a esperança de trazer o desenvolvimento social e tecnológico, porém esse tipo de política gera as desigualdades sociais e as segregações espaciais, visto que as áreas onde concentram o desenvolvimento econômico de uma cidade se tornam demasiadamente valorizadas, empurrando as classes menos favorecidas para as periferias. É nesse aspecto que o Distrito Federal tem como desafios: continuar a estabelecer a capital do país, seguir normativos legais que lhe dão o poder de arrecadar e administrar como um município e estado, lidar com a preservação do conjunto urbanístico tombado, além de sofrer em função das pressões socioeconômicas que nela incidem. Para gerir esse desafio, foram instituídos pelo Governo do Distrito Federal diversos instrumentos urbanísticos alinhados ao uso de tecnologia da informação, por meio de um

1

sistema de informação territorial para subsidiar o planejamento e a formulação de políticas setoriais com intervenção no território, principalmente, aquelas relacionadas ao desenvolvimento urbano e ao controle urbanístico. Assim, o projeto ora apresentado visa propor à Secretaria de Habitação, Regularização e Desenvolvimento Urbano do DF – Sedhab um novo sistema de informação territorial e urbano para as políticas de urbanismo, habitação e regularização fundiária do DF que possa contribuir para a concepção de cidade e território vistos como uma obra tão singular e de grande importância para a história mundial. 1.1

- PROBLEMA

1.1.1 - Contextualização do problema A Secretaria de Estado de Habitação, Regularização e Desenvolvimento Urbano do Distrito Federal – Sedhab tem a missão de “elaborar, definir, implementar, coordenar, licenciar e fiscalizar as políticas de desenvolvimento urbano, habitação e regularização e de informações territoriais e urbanas do Distrito Federal”. Um dos principais sistemas que dá suporte às atividades da Secretaria é o Sistema de Informação Territorial e Urbana – Siturb, que atende às necessidades de informações para subsidiar o planejamento e a formulação de políticas setoriais com intervenção no território e, principalmente, àquelas relacionadas ao desenvolvimento urbano e ao controle urbanístico. Foi regulamentado pela Lei Complementar nº 17/97 e alterado pela Lei Complementar nº 803/2009 tornando-se, assim, o Sistema de Informações Urbanas oficial do Governo do Distrito Federal. O Siturb é um Sistema de Informação Territorial composto por várias bases, dentre elas, o Sistema Cartográfico do DF – Sicad, que é a base cartográfica de referência obrigatória para todos os trabalhos de topografia, cartografia, demarcação, estudos, anteprojetos, projetos, implantação e acompanhamento de obras de engenharia em geral, bem como para o controle do uso do solo no Distrito Federal (Decreto nº 4008, de 26 de dezembro de 1977), abrangendo, também, a cartografia temática, e contendo dados de diversas naturezas, o que constitui uma base geográfica única para todo o DF. O Plano Diretor de Ordenamento Territorial do Distrito Federal – PDOT, Lei Complementar n° 17, de 28 de janeiro de 1997, concebido como um dos instrumentos da política de ordenamento territorial e de desenvolvimento urbano, abrange objetivos, estratégias e

2

diretrizes setoriais do ordenamento territorial; o macrozoneamento do território; os planos, as ações, os programas e os projetos prioritários; os instrumentos da política de desenvolvimento urbano e o Sistema de Planejamento Territorial e Urbano – Sisplan. A fim de subsidiar o processo de efetiva implantação do Sisplan, o Siturb foi concebido para coletar, organizar, produzir e disseminar as informações sobre o território e sua população. Ao longo dos anos de implantação do PDOT e demais instrumentos urbanísticos, que tratam sobre as políticas de planejamento urbano, controle urbano, regularização e habitação, observou-se o distanciamento entre o planejamento e a gestão frente à realidade que se instalou, ou seja, o descolamento entre os planos e programas governamentais e os processos sociais de apropriação do espaço. Essa situação é decorrente da própria dinâmica da urbanização das cidades brasileiras reproduzida, também, no Distrito Federal, onde, como em qualquer cidade, há a necessidade constante de avaliação e reflexão acerca do planejamento, a fim de que suas propostas sejam capazes de responder às demandas relativas ao desenvolvimento da cidade. Somente em 2009, a Secretaria conseguiu utilizar de recursos de Tecnologia da Informação para estruturar o Siturb como um Sistema de Informação Territorial. De forma geral, os Sistemas de Informação Territorial – SIT são sistemas de informação transacionais, baseados em Sistemas de Informação Geográfica – SIG, que visam armazenar e consultar informações descritivas e espaciais do território para promover o crescimento ordenado de um município e a distribuição eficaz e justa de seus recursos. (Fourie;Nino-Fluck, 2000, apud Silva, 2012). A partir disso, dotou a administração pública do Distrito Federal de um sistema de informações confiável e preciso, com dados relativos aos aspectos físico e social, o qual dá suporte à gestão do território e dos espaços urbanos. Criado de forma georreferenciada, possibilitou organizar os instrumentos urbanísticos em vigor e permitiu a comparação entre a cidade real e a cidade legal, além de subsidiar as ações de planejamento, controle urbano e fiscalização. A arquitetura da aplicação projetada, naquele ano, foi concebida para atender às necessidades apenas da Secretaria, tendo em vista que a infraestrutura tanto de hardware quanto de software não possibilitava atender a um número muito grande de usuários. Ao longo dos anos, a Diretoria de Geoprocessamento conseguiu conquistar um espaço dentro da Secretaria e também no Governo, apresentando a importância de utilizar

3

de ferramentas geográficas como, por exemplo, o Siturb no auxílio aos gestores públicos para a tomada de decisão. Esse cenário criou um novo desafio para a Unidade de Tecnologia da Informação da Sedhab – Untec, a partir de 2011, quando foi proposto pela Subsecretaria de Informações Urbanas – Siurb disponibilizarem o acesso do Siturb para os órgãos do Governo do Distrito Federal. Como relatado, a tecnologia adotada para suportar a aplicação era limitada, visto que, na época, a arquitetura foi desenhada apenas para manter os trabalhos dos técnicos da Secretaria. A Untec aceitou o desafio com a Siurb, e, a partir dessa parceria, foi proposta a reestruturação de toda a arquitetura de hardware e o desenvolvimento de uma nova solução não só para suportar os usuários da nuvem privada do GDF, como para cumprir com o normativo legal da Lei Complementar que menciona a necessidade de disponibilizar o Siturb para a sociedade. Diante do exposto, o objetivo deste Projeto é propor um sistema de informações territoriais e urbanas para as políticas de urbanismo, habitação e regularização fundiária do DF. 1.1.2 - Enunciado do problema Disponibilizar um sistema de informações territoriais e urbanas para o auxílio à tomada de decisão dos gestores do Governo do Distrito Federal, bem como dar transparência para a sociedade quanto às políticas públicas de urbanismo, habitação e regularização fundiária. 1.2

- JUSTIFICATIVA

O Siturb é um importante instrumento de informações georreferenciadas, confiável e preciso, com dados relativos aos aspectos físico e social, o qual dá suporte à gestão do território e dos espaços urbanos, porém o sistema tem uma limitação na representação de fenômenos espaciais no computador, pois, atualmente, apresenta os dados de forma estática. Isto se deve ao fato de que a principal abstração utilizada em Sistemas de Informação Geográfica – SIG é o mapa. No entanto, um significativo conjunto de fenômenos espaciais, tais como escoamento de água da chuva, planejamento urbano, entre outros, são intrinsecamente dinâmicos, e as representações estáticas utilizadas em SIG não os capturam de forma adequada. Deste modo, um dos grandes desafios para a equipe 4

técnica, por intermédio da área de monitoramento territorial, é o desenvolvimento de técnicas e abstrações que sejam capazes de representar adequadamente fenômenos dinâmicos. O conhecimento sobre os fenômenos dinâmicos que norteiam o processo de urbanização é imprescindível para um bom planejamento urbano que pretenda contribuir para a construção do desenvolvimento econômico sustentável de uma dada região, uma vez que esses redefinem a hierarquia dos lugares em função das exigências em matéria de comunicação, de deslocamentos os mais variados e complexos, como também o quadro em que se realiza a vida cotidiana através das modificações nos usos dos lugares. A necessidade de observar os fenômenos dinâmicos, todavia, não exclui a necessidade de criar e trabalhar com a gestão de projetos SIG, pois os encarregados de tomada de decisões em um órgão público, sendo estes usuários de um SIG, acabam se defrontando, ao longo de seu trabalho, com a questão da decisão correta a ser tomada, visto que o processo decisório é de fundamental importância para quem faz uso de tais sistemas. Sob este aspecto, percebeu-se a necessidade do emprego do geoprocessamento no dia-a-dia das atividades da Sedhab. A partir da reunião das características de um SIG com o processo decisório, é possível elaborar mapas, modelar, fazer buscas e analisar uma grande quantidade de dados, todos mantidos em um único banco de dados. Todo reforço destinado à área de gestão da informação territorial e urbana torna-se imprescindível para que tanto o planejamento urbano quanto a área de controle urbano tenham acesso a informações confiáveis e possam fluir na estrutura organizacional. O uso do Siturb como um grande sistema de informações georreferenciadas do governo do Distrito Federal garantirá inúmeros benefícios ao governo, dentre eles: o aumento no valor de arrecadação dos impostos relativos aos imóveis (IPTU e ITBI), o auxílio na tomada de decisão de novas construções de equipamentos públicos, controle das áreas de mananciais e de preservação ambiental, ou seja, informações para uma cidade inteligente. 1.3

- DELIMITAÇÃO DO TEMA

O sistema de informações territoriais e urbanas da Sedhab possui uma limitação na sua arquitetura tecnológica, dificultando o auxílio nas atividades dos arquitetos, engenheiros e demais técnicos da Secretaria. Dessa forma, o foco desse projeto é propor uma nova aplicação que consiga abarcar um número maior de usuários e utilize de uma tecnologia em que seja possível acessá-lo, por meio da World Wide Web. 5

1.4

- OBJETIVO GERAL

Propor um Sistema de Informações Territoriais e Urbanas para as Políticas de Urbanismo, Habitação e Regularização Fundiária do DF. 1.5

- OBJETIVOS ESPECIFICOS

São objetivos específicos do trabalho: a. Caracterizar o Sistema de Informação Territorial e Urbana do DF; b. Apresentar os requisitos do Sistema de Informação Territorial e Urbana do DF; c. Apresentar o protótipo do Sistema de Informação Territorial e Urbana do DF. 1.6

METODOLOGIA

1.6.1 - Classificação da Pesquisa Quanto à natureza, a pesquisa classifica-se como aplicada, pois tem como objetivo gerar conhecimento e aplicação prática e dirigida à solução de problemas específicos, além de envolver verdades e interesses de um grupo definido. Quanto aos objetivos, essa pesquisa é definida como exploratória e descritiva. Segundo Gil (1999), as pesquisas exploratórias têm como objetivo proporcionar maior familiaridade com o problema, com vistas a torná-lo mais explícito ou a construir hipóteses. Inclui levantamento bibliográfico e entrevistas com pessoas que tiveram experiências práticas com o problema pesquisado; análise de exemplos que estimulem a compreensão. A pesquisa descritiva tem como objetivo descrever as características de uma determinada população ou fenômeno. 1.6.2 - Percurso Metodológico Na figura abaixo, é demonstrado o diagrama do percurso metodológico em que podemos observar três colunas, as quais representam as fases do processo (Temas, Referenciais de Investigação e Resultados Esperados).

6

Figura 1.1 - Diagrama de Percurso Metodológico

1.6.2.1 - Temas Um dos grandes desafios para a Ciência da Geoinformação é representar os espaços geográficos e relacionar a natureza interdisciplinar dessa ciência. Segundo Câmara (2011), trabalhar com geoinformação significa utilizar de computadores como instrumentos de representação de dados espacialmente referenciados. Isso foi possível, principalmente, graças à popularização e à redução de custos na produção de hardware ao longo dos últimos 30 anos. Um dos alicerces para um sistema de informação geográfica é produzir dados cartográficos, topológicos e alfanuméricos a partir de imagens de satélites ou imagens aéreas. A produção desses tipos de mapas, além de ser demorados e caros, exige um poder de processamento e armazenamento de hardware bastante intenso. É nesse sentido que o uso da arquitetura da computação veio amparar o desenvolvimento de aplicações SIG com o objetivo de proporcionar escalabilidade e performance para este tipo de sistema. Além disso, os altos investimentos feitos pelas empresas, órgãos governamentais e a academia não poderiam ficar restritos apenas aos seus ambientes. Apesar de muitas das vezes, cada organização ou empresa ter aplicações de SIG heterogêneas o compartilhamento da geoinformação é de interesse de todos, visto que de 60 a 80% dos custos de um projeto SIG são direcionados para a produção de dados. Assim, com o 7

objetivo de reduzir custos, foram criados padrões e protocolos para compartilhá-los pela indústria de informações geográficas. Diante dos fatos apresentados, a importância dos temas constantes na figura 1.1 são fatores chaves para o sucesso de um projeto SIG. 1.6.2.2 - Referenciais de Investigação A engenharia de software é a disciplina que cuida da criação e da manutenção de aplicações de software. Sistema de Informação Geografia – SIG é uma aplicação que utiliza da tecnologia da informação, de forma que os conceitos dessa disciplina são de grande importância, a considerar que 87% desses projetos falham, conforme estudo realizado pela KPMG.( Hamil, tradução nossa). Um SIG utiliza técnicas matemáticas e computacionais para o tratamento da informação geográfica, sendo que aplicar a tecnologia no mesmo significa usar de algoritmos e estruturar dados capazes de representar a diversidade do espaço geográfico. Esses dados serão armazenados e, posteriormente, serão consultados por meio de análises espaciais para apoio na tomada de decisão dos gestores. Um dos pilares que possibilita essa função em um SIG é o banco de dados e a sua extensão geográfica, que tem a capacidade de armazenar e processar dados espaciais e alfanuméricos. As consultas em bancos de dados precisam de discos que consigam fazer grandes transações de dados de forma rápida e eficaz. Esse processo é complexo, contínuo e lida com um volume muito grande. Com a queda dos custos de hardware, bem como, os avanços computacionais, a comunidade de tecnologia da informação percebeu que era possível alcançar um poder computacional maior usando computadores interconectados em rede na execução de aplicações paralelas e distribuídas, com o objetivo de resolver problemas de processamentos complexos com escalabilidade e alta performance. Assim, a arquitetura distribuída passou a contribuir com aplicações SIG para permitir o ganho de escala, disponibilidade e performance. Os protocolos e padrões do Consórcio Geoespacial de Dados Abertos (Open Geospatial Consortium – OGC) são, atualmente, os mais usados para a interoperabilidade de dados geográficos, sendo que boa parte das aplicações de SIG para web disponibilizam os dados nos protocolos definidos por esse consórcio, permitindo assim o reuso dos dados geográficos pela comunidade da geoinformação.

8

1.6.2.3 Resultados Esperados A definição da metodologia adequada a ser utilizada na implementação de uma aplicação evita que trabalhos desnecessários sejam efetuados ou que sejam feitas de forma desordenada e confusa, por isso, a necessidade dos conceitos da engenharia de software como subsídio para a concepção de uma arquitetura adequada para a aplicação, bem como requisitos de negócios bem estabelecidos. Como esses instrumentos são chaves para o sucesso de um sistema WEBSIG, uma vez bem implantados, consequentemente, será possível criar um protótipo e, posteriormente, uma nova aplicação que permita ao usuário consultar informações georeferenciadas e tabulares sobre uma determinada área de modo interativo, por meio da manipulação de diferentes níveis de informação (camadas), de acordo com seu interesse e necessidade. Tudo isso a partir da combinação dos conceitos dos temas e os referenciais de investigação ora citados como forma de representar os dados geográficos em uma aplicação que utiliza de recursos computacionais.

9

2

- REFERENCIAL TEÓRICO

Nesta parte, que corresponde ao referencial teórico da pesquisa, serão apresentados os conceitos mais relevantes para elaboração do presente trabalho, conforme Figura 1.1, no tocante à Geoinformação, Engenharia de Software, Sistema de Informação Geográfica, Arquitetura de um Sistema de Informação Geográfica, Modelagem de Dados Geográficos, Banco de dados Geográficos e Sistema de Informação Territorial. 2.1

- GEOINFORMAÇÃO

Para Câmara, trabalhar com geoinformação significa “utilizar computadores como instrumentos de representação de dados espacialmente referenciados”. Sendo assim, a geoinformação “deve necessariamente se apoiar em estruturas de percepção ambiental [...] transformação de dados geograficamente referenciados em conhecimento.”, segundo Almeida & Câmara & Monteiro (2007). Importa consignar que um dos grandes desafios para a ciência da geoinformação é representar os espaços geográficos e relacionar a natureza interdisciplinar dessa ciência. Atualmente, vários campos utilizam-se da geoinformação como contribuição para referencial teórico. Esse cenário prejudica a consolidação dessa disciplina científica de forma independente. Por outro lado, apesar de ela ser interdisciplinar, o fundamento básico é a construção de representações computacionais do espaço, sendo esse espaço uma linguagem comum nas diversas disciplinas que se apoiam da geoinformação. Por se tratar de linguagem comum, é possível o uso do Sistema de Informação Geográfica – SIG. Aplicar a tecnologia em um SIG significa usar de algoritmos e estruturar dados capazes de representar a diversidade do espaço geográfico. Apesar de dotar de várias técnicas desde algoritmos até a inteligência artificial para prover um SIG, a estrutura de computadores é finita, e o espaço é infinito. Utilizar-se de modelagem computacional, derivações de modelos matemáticos, não se pode reduzir a premissa de representar o comportamento de uma sociedade e dos agentes sociais.

10

Possivelmente, esse seja um dos grandes paradigmas e desafios para a tecnologia da informação em SIG, principalmente, em gestão urbana e regional, no qual há a necessidade de explorar a extrema complexidade de problemas socioambientais. 2.1.1 - Engenharia de Software Segundo Pressman (2011), “software consiste em instruções (programa de computador) que, quando executadas, fornecem características, funções e desempenho desejados...”. Para Sommerville (2011), “o software é um conjunto de vários artefatos e não apenas o código fonte”. Na verdade, antes mesmo de caracterizar um software, a indústria de computadores sempre esteve preocupada em desenvolver um hardware que reduzisse os custos de processamento e armazenamento de dados. Superada essa fase que percorreu as últimas trinta décadas, um novo desafio para a indústria de tecnologia surgiu: ser mais eficiente com mais qualidade e com menores custos. Isso só tornou possível a partir da evolução da indústria eletrônica depois de vários anos de pesquisa. Assim, a partir da década de 90 era possível que as pessoas comprassem um computador pessoal com um alto poder de processamento. Para alguns, o que era sonho tornou-se realidade com o abandono dos processadores e o desenvolvimento de válvulas para dispositivos microeletrônicos cada vez menores e mais potentes. Essa nova era ressaltou a importância do software nas organizações como um meio para auxiliar as empresas em seus processos produtivos e na tomada de decisão como forma de serem mais competitivas em um mercado globalizado. O desenvolvimento de softwares passou por diversas ondas, começando pelos programas sob medida, passando pela produção de larga escala e pelos softwares de inteligência artificial. Nesse contexto, Pressman (2011) afirma: “...atualmente, com a Web 2.0 e a computação pervasiva estamos por ver uma geração completamente diferente de software. Ele será distribuído via internet e parecerá estar residente nos dispositivos de computador de cada usuário... porém, estará residente em um servidor bem distante.”

11

Conforme citado, novas formas de fazer software surgem rapidamente e, hoje, verifica-se que ele está presente nas atividades cotidianas da sociedade, a exemplo da televisão, do forno micro-ondas, da nanotecnologia e da biomedicina. Lidar com tecnologias mais complexas, em uma demanda maior por parte dos consumidores, é um desafio para a engenharia de software. Apoiar-se da engenharia de software é o “emprego de sólidos princípios de engenharia de modo a obter software de maneira econômica, que seja confiável e funcione de forma eficiente em máquinas reais.” Fritz Bauer citado por (Pressman, 2011) . Para o Software Engineering Body of Knowledge - Swebok, Engenharia de software é uma área de interesse (disciplina) preocupada com a criação e manutenção de aplicações de software pela aplicação de tecnologias e práticas da ciência da computação, gerência de projetos, engenharia, domínio de aplicação e outros campos. O Swebok, guia de boas práticas de engenharia de software, divide a disciplina em áreas de conhecimento para facilitar a especialização dos profissionais. Essas áreas são tratadas no Swebok como: Requisitos de software, projeto de software, construção de software, teste de software, manutenção de software, gerência de configuração de software, gerência de engenharia de software, processo de engenharia de software, ferramentas e métodos da engenharia de software e qualidade de software. Enquanto sistema de informação, uma aplicação em SIG deve seguir os modelos propostos pela engenharia de software para o desenvolvimento de sistema. No entanto, na análise de requisitos, fase preliminar para o desenvolvimento de um sistema de informação, precisa-se ter atenção especial para identificar e elaborar as necessidades, exigências, restrições e imposições, não tanto funcionais e comportamentais da tecnologia, mas do SIG e seu meio técnico-científico-informacional e político-institucional, assim como seu ambiente organizacional amplo, hospedeiro e fornecedor de dados geoespaciais, cuja disponibilidade e fluxos de produção e disseminação irão garantir a constituição e a instituição do SIG planejado. Na engenharia de software, um dos modelos de ciclo de vida de sistemas de informação é o Modelo em Cascata. Neste modelo, há um grande esforço inicial de definição de requisitos de um sistema até chegar em sua implementação, por um processo recursivo de detalhamento de sua especificação de requisitos, que acompanha, assim, o desenvolvimento do sistema de informação até a instalação final. Para Pressman (2002) o desenvolvimento de software se divide em ciclos, sendo que o ciclo mais clássico, o cascata, pode ser dividido em seis partes, são elas: 12

a. Engenharia de Sistemas: o estabelecimento de requisitos de sistema; b. Análise de requisitos: a coleta de requisitos e informações necessárias para a implementação de um sistema; c. Projeto: a determinação de todos os passos que serão executados durante o desenvolvimento. É onde se estabelece a arquitetura, estrutura de dados, detalhes procedimentais e interface do sistema; d. Codificação: a tradução do projeto para uma linguagem computacional para então ser compilado em um objeto executável no computador; e. Teste: após a codificação o teste é a validação dos procedimentos que o sistema executa, aonde se procura por erros e procura-se corrigi-los; e, f. Manutenção: como o desenvolvimento é feito por pessoas, mesmo após os testes, erros podem persistir em existir, para isto a manutenção é necessária para prever e corrigir problemas futuros ou prover modificações mediante necessidade. Na figura abaixo, observa-se um melhor entendimento de como o ciclo de vida de um software funciona onde a engenharia de sistemas é base para a análise de requisitos e o projeto de software.

Figura 2.1 - Esquema sequencial do ciclo de vida clássico de um software (modificado – Storck, 2006)

Segundo um estudo da KPMG 87% dos projetos de SIG falharam; 50% ficaram acima do orçamento, 45% não conseguiram produzir os benefícios esperados e entre 86 a 92% ultrapassaram o cronograma estipulado. (Hamil, 2000, tradução nossa). As quatro razões para o fracasso dos projetos em SIG estão ligados às seguintes razões: falta de planejamento, falta de apoio da alta gestão, má gestão do projeto e falta de foco no cliente e a participação dos usuários finais.

13

Para que um projeto de SIG não seja frustrado, é interessante que a área de negócio esteja envolvida no processo de definição de requisitos do sistema, na concepção e ao longo da implantação da aplicação. Segundo Hamil (2000, tradução nossa), os usuários deverão ser parte do projeto e ser envolvidos durante o levantamento de requisitos, o design do aplicativo, criação do protótipo, testes e aceitação. O autor, em seu artigo, comenta a necessidade de os clientes entenderem o que querem e o que está sendo entregue, além acompanhar essas ações com afinco. Ademais, os clientes precisam ser capazes de quantificar e qualificar os benefícios do projeto. Diante dos fatos apresentados, a engenharia de software, que é uma ciência que se ocupa do estudo de todas as características do desenvolvimento de software, deverá ser empregada para auxiliar os profissionais de SIG em sua concepção, gerenciamento e monitoramento como forma de minimizar o fracasso de projetos nessa área. 2.1.2 - Sistema de Informação Geográfica – SIG A representação do espaço, por meio de mapas, é praticada desde a pré-história antes mesmo da invenção da escrita, e o uso da cartografia matemática para a concepção e a construção de mapas data do século XV. A coleta e distribuição geográfica sempre foram preocupações para a sociedade organizada, mas, somente a partir do século XX, a forma de representar o espaço geográfico avançou de forma drástica, principalmente, com o avanço da tecnologia da informação. Assim, os mapas que eram representados em papel passaram a usar recursos de armazenamento e apresentar tais informações em ambiente computacional. Esse avanço é conhecido como geoprocessamento, a “...disciplina do conhecimento que utiliza técnicas matemáticas e computacionais para o tratamento da informação geográfica e que vem influenciando de maneira crescente as áreas de Cartografia.” (Câmara, et al., 2002) Por sua vez, as ferramentas computacionais para Geoprocessamento são chamadas de Sistema de Informação Geográfica. A chamada Informação Geográfica é a informação acerca de entidades ou fenômenos localizados na proximidade da superfície terrestre (Rocha, 2005 apud Faria, 2006). Podemos definir a informação geográfica também como sendo atributos versus localização, porém, embora a terra seja quase esférica, a sua forma real é bastante complexa, apresentando muitas deformações. A sua superfície conta com

14

quinhetos milhões de quilômetros quadrados, e a tarefa de representá-la passa a ser infinita. A criação do computador, como ferramenta para auxiliar os trabalhos das disciplinas que estudam os fenômenos da terra, tem uma limitação na forma de representação das características desses fenômenos. Os técnicos precisam definir critérios de como representar o mundo geográfico da forma que possa atender a sua necessidade de negócio, afinal nenhuma das representações são perfeitas e nem sempre são ideais para todas as aplicações. Quanto mais completa uma representação em um mapa, mais detalhes ele revelará, parecendo mais complexo, por isso a necessidade de descartar ou ignorar informações que se aplicam a pequenas áreas, visto que a necessidade de armazenamento e o processamento para a apresentação em um mapa em uma determinada escala poderão exigir milhões de pixels ( menor unidade de uma imagem) para exibi-lo. Para Longley et al (2005, tradução nossa), muitas definições surgiram ao longo dos anos, mas nenhuma conseguiu abarcar uma definição inteiramente satisfatória entre os pesquisadores. O Sistema de Informação Geográfica – SIG está ligado a várias circunstâncias ou fatores, como um software, representação digital de vários aspectos geográficos do mundo, ou seja, conjunto de dados geográficos, ou ainda pessoas que usam o SIG para resolver problemas ou avançar no campo da ciência. Na literatura, os termos mais comuns usados são: 1. Para o público em geral: Um recipiente de mapas em formato digital; 2. Para os tomadores de decisão, planejadores: Uma ferramenta informatizada para resolver problemas geográficos; 3. Para os cientistas e pesquisadores: Um sistema de apoio a decisão espacial; 4. Para os gestores de empresas de energia, infraestrutura e transporte: É Um inventário geográfico distribuído com várias características e facilidades de forma mecanizada; 5. Para os cientistas e estudiosos: Uma ferramenta para revelar o que é invisível em informação geográfica; 6. Para os planejadores: Uma ferramenta para executar operações de dados geográficos que são muito tediosos ou caros, ou impreciso caso seja realizado sem o apoio de computadores. Os SIG são “sistemas automatizados usados para armazenar, analisar, e manipular dados geográficos, ou seja, dados que representam objetos e fenômenos em que a

15

localização geográfica é uma característica inerente à informação e indispensável para analisá-la.” (Vieira, 2002). Nick Chrisman’s (2003 apud Longley et al., 2005,tradução nossa) define o SIG como uma atividade organizada, pela qual as pessoas medem os aspectos dos fenômenos geográficos e processos; representam as medições, geralmente, sob a forma de uma base de dados de computador para enfatizar temas espaciais, entidades e relacionamentos; operam sobre estes representações para produzir mais medidas e descobrir novas relações, integrando fontes distintas e transformando estas representações que estão de acordo com outros frameworks de entidades e relacionamentos. A história do Sistema de Informação Geográfica é controversa, pelo fato de alguns estudiosos terem dito que o primeiro uso desse tipo de tecnologia tenha ocorrido no Norte da América, enquanto outros afirmam que foi na Europa e, por último, na Austrália, sendo que, na verdade, o desenvolvimento do primeiro SIG foi implantado pelo Governo Canadense, na década de 60, com o objetivo de identificar as terras e os recursos naturais daquele território, o que foi um esforço bastante grande tanto do governo federal quanto dos governos das províncias para a obtenção um registro dessas áreas. Posteriormente, outras iniciativas de outros governos como o Departamento do Censu dos Estados Unidos, a Universidade de Harvard, por meio do Laboratório de Computação Gráfica e Análise Espacial desenvolveu um SIG de propósito geral chamado Odyssey. Vale ressaltar que, nessa década, as forças militares norte americanas também beneficiaram a área de informações geográficas com o desenvolvimento do primeiros estudos do Global Positioning System – GPS. O maior avanço em tecnologia SIG efetivamente ocorreu a partir da década de 80, quando os custos com armazenamento e hardware cairam para um nível competitivo que permitisse que a indústria conseguisse ser rentável com uma aplicação perene. Os primeiros clientes foram as agências de recursos naturais e florestais. Assim, nos últimos trinta anos, com a queda dos preços do hardware, a popularização da internet e do computador pessoal, surgiram os primeiros fabricantes de softwares comerciais como Environmental Systems Research Institute – ESRI, o Consórcio OpenGIS que envolve governos, agências, empresas privadas e demais usuários de tecnologia SIG com o objetivo de criar padrões de interoperabilidade, a Agência Nacional de Inteligência Geoespacial – NGA do Departamento de Defesa dos Estados Unidos, dentre outras.

16

Com esse novo paradigma, as organizações passaram a armazenar milhares de dados das suas áreas de negócio, sendo desafiante aos gestores selecionar, organizar esses dados e transformá-los em informações valiosas para se manterem em um mercado mais competitivo. Com o SIG, isso não é diferente, por isso o pilar para a aplicação dessa tecnologia precisa de

seis

componentes:

Pessoas, software,

dados,

hardware,

procedimentos e uma rede de dados, conforme a figura abaixo:

Figura 2.2 – As seis partes de um SIG (modificado – Longley, 2005)

Esses itens são de grande importância para o sucesso desse tipo de projeto, visto que, hoje, é muito natural se produzir uma quantidade muito grande de dados dos mais diversos tipos em uma organização sejam eles financeiros, marketing, vendas etc. Apesar do custo de armazenamento e processamento terem diminuído nos últimos anos, as empresas, por outro lado, precisam lidar com orçamentos limitados alinhados a uma alta qualidade de seus projetos, em razão de o mercado ser muito competitivo, com margens cada vez reduzidas. Assim, o grande dilema para o sucesso de projetos em SIG é a

17

capacidade dos gestores e planejadores conseguirem selecionar os dados mais críticos para seus negócios e transformá-los em informações estratégicas apoiadas em SIG para a tomada de decisão. 2.1.3 - Arquitetura: Sistema Informações Geográficas - SIG Nos últimos anos, com a proporção em que a Internet alcançou muitas empresas, foram realizados investimentos em aplicações voltadas para o mundo web. Em SIG, essa tendência também foi seguida. Diante desse novo cenário tecnológico, criou-se o WEBGIS que é um SIG que permite ao usuário consultar informações georeferenciadas e tabulares sobre uma determinada área de modo interativo, por meio da manipulação de diferentes níveis de informação (camadas), de acordo com seu interesse e necessidade. O portais WEBGIS permitem o compartilhamento e implementação de dados geográficos que são geridos pelos diferentes departamentos de uma empresa, tais como mapeamentos vetoriais por camadas, imagens de satélite, fotografias aéreas, mapas específicos, informações tabulares, modelos digitais de elevação, pontos de interesse (POIs), dentre outros. Para Bressan apud Pascual (2013), Web SIG é um SIG que usa tecnologia web. O WEBGIS deve ter pelo menos um cliente-servidor, no qual o servidor é um servidor de aplicação Web e que o cliente é um navegador da web, uma aplicação em computador ou uma aplicação móvel. Segundo Longley et al. (2005, tradução nossa), existem três peças chaves para um SIG: a interface do usuário, as ferramentas de um SIG e o sistema de gerenciamento de dados. A interface gráfica do usuário (GUI) permite o acesso às ferramentas de SIG. O conjunto de ferramentas define os recursos ou funções que o SIG tem disponível para processamento geográfico dos dados, e tais dados são armazenados e organizados pelo software de gerenciamento de dados. Em tecnologia da informação, esse tipo de arquitetura é classificado como sendo de três camadas: a camada de apresentação, a camada lógica e a camada de servidor de dados. A camada de apresentação deve suportar a exibição e a interação com os objetos gráficos. A segunda camada é a responsável pela execução de computação intensiva operações como processamento de sobreposição de dados e análise raster, sendo nessa camada que é feita a implementação da lógica de dados de SIG. A terceira e última camada deve importar e exportar dados e requisições de serviços a partir da comunicação

18

com um sistema de banco de dados ou arquivos. Abaixo, segue um modelo clássico de três camadas para aplicações em SIG:

Figura 2.3 - Arquitetura Clássica de 3 camadas de um Sistema de Software SIG (modificado – Longley, 2005)

Um dos grandes desafios para os projetos de SIGWEB é conseguir dimensionar o hardware e o software para otimizar o desempenho da aplicação. Por exemplo, os mapas requerem grandes quantidades de memória e velocidade do clock do CPU. As consultas e banco de dados precisam de discos que consigam fazer grandes transações de dados. Como forma de resolver parte dos problemas de escalabilidade e desempenho, a arquitetura de SIGWEB tem adotado a computação distribuída e a computação orientada a serviços. Os projetos de SIG lidam com uma gama de tipos de dados bastante variados, desde os mapas cartográficos, estudos topológicos, mapas analógicos até os dados alfanuméricos, por isso um dos principais atores no sucesso do projeto é o sistema de banco de dados. Para que o banco de dados possa gerar análises espaciais e consultas rápidas para o auxílio aos gestores na tomada de decisão, é necessário, conforme mencionado anteriormente, que os envolvidos em projetos de SIG produzam os dados de forma limitada 19

para atender ao negócio da empresa ou instituição, visto que a computação em máquina é limitada, e o universo da superfície terrestre é infinita. A modelagem de dados geográficos é outro fator decisivo para o bom desempenho e tempo de resposta das consultas em banco de dados. Ao longo dos últimos anos, tanto a academia quanto as instituições e empresas têm trabalhado no sentido de criar padrões de modelagem para facilitar a integração e a interoperabilidade da geoinformação. Um bom exemplo foi a criação do Consórcio Geoespacial de Dados Abertos (Open Geospatial Consortium – OGC) que surgiu como uma organização mundial que conta com centenas de membros dentre eles universidades, instituições públicas e iniciativa privada, com o objetivo de desenvolver padrões para a troca de dados. Outro exemplo é o trabalho da Comissão Nacional de Cartografia – CONCAR para a criação de normas para a estruturação de dados geoespaciais. 2.1.4 - Modelagem de Dados Geográficos Para Longley et al. (2005), o coração de um SIG é o modelo de dados, isto é, um conjunto de representações de objetos e processos em ambiente digital. A modelagem dos dados é uma das tarefas mais importantes para a implantação de um banco de dados. O banco de dados é uma das peças chaves para o sucesso do SIG, e, para tanto, precisa ter um projeto de modelagem de dados bem elaborado para que seja possível fazer consultas, extração e a análises de dados geográficos. Para Borges et al. (2005), um modelo de dados é um conjunto de conceitos que podem ser usados para descrever a estrutura e as operações em um banco de dados. O modelo busca sistematizar o entendimento que é desenvolvido a respeito de objetos e fenômenos que serão representados em um sistema informatizado. Os objetos e fenômenos reais, no entanto, são complexos demais para permitir uma representação completa, considerando os recursos à disposição dos sistemas gerenciadores de bancos de dados (SGBD) atuais. Desta forma, é necessário construir uma abstração dos objetos e fenômenos do mundo real, de modo a obter uma forma de representação conveniente, embora simplificada, que seja adequada às finalidades das aplicações do banco de dados. Os fenômenos geográficos fazem parte do modelo de representação de um projeto de modelagem de dados geográficos. Os referidos fenômenos geográficos são classificados como dados geográficos, sendo de dois tipos: objeto geográfico e campos. O objeto geográfico representa os elementos do mundo real e é composto por duas partes.

20

A primeira parte representa a geometria do objeto geográfico, basicamente são: o ponto, a linha e o polígono. A segunda parte, os campos são variações espaciais que representam a grandeza distribuídas espacialmente no mundo real, ou seja, a temperatura, cobertura do solo, população etc. A implantação da representação espacial e dos relacionamentos espaciais de um conjunto de objetos geográficos é feita com base em estruturas de dados espaciais. Geralmente, nos esquemas conceituais de banco de dados geográficos, são incluídos os objetos espaciais e seu relacionamento com os fenômenos geográficos como forma de permitir a abstração do componente espacial de cada fenômeno. Para a modelagem, o importante é definir a representação de um componente espacial, como exemplo: se uma estação meteorológica será representada por um ponto, se um rio será representado por uma linha ou por um polígono. Os campos geográficos são abstraídos de forma diferentes dos objetos geográficos. Podem ser adotados vários modelos, sendo resumidos em seis modelos espaciais descritos por Goodchild (1992, apud Filho et al.): grade de células; polígonos adjacentes; isolinhas; grade de pontos; rede triangular irregular; e pontos amostrados irregularmente. Em um SIG, esses modelos serão, posteriormente, implementados por meio dos modelos de representação matricial e vetorial, conforme explanação a seguir. A representação vetorial armazena os dados espaciais por meio de elementos geométricos (ponto, linha, polígono etc), e o formato matricial por meio de uma grade de células. Cada célula é referenciada por uma linha e uma coluna, e contém um dado que representa o valor do fenômeno que está sendo mapeado. Esse valor é utilizado para definir uma cor para sua visualização. Com a totalidade da matriz contendo valores agregados em suas células, chega-se a uma imagem digital que permite o reconhecimento de objetos. Cada célula de um dado matricial, que recebe o nome de pixel, representa uma medição de alguma grandeza física, que corresponde a algum objeto no mundo real. Segundo Thome (1998), para ambas representações, algoritmos são adotados para indexar a representação vetorial e na representação matricial e para essa última, para compactar uma grande massa de dados com objetivo de otimizar o seu armazenamento. A modelagem de dados geográficos tem adotado padrões de modelos de dados semânticos e orientados a objetos como o modelo OMT e UML - Unified Modeling Language. Apesar de serem modelos bem estabelecidos e usados largamente no campo da tecnologia da informação, eles possuem limitação na representação dos dados espaciais.

21

Segundo Borges et al. (2005), modelos de dados para aplicações geográficas têm necessidades adicionais, tanto com relação à abstração de conceitos e entidades, quanto ao tipo de entidades representáveis e seu inter-relacionamento. Diversas propostas existem atualmente, principalmente, dispostas a estender os modelos criados para aplicações convencionais, como GeoOOA – Object-Oriented Analysis for Geographic Information Systems,

GMOD - Generic Model Organism Database para aplicações geográficas,

OMT-G - Object Modeling Technique for Geographic Applications, GeoFrame (padrão desenvolvido por Schlumberger GeoQuest). Todos esses modelos procuram refletir melhor as necessidades de aplicações geográficas. A escolha de um deles pode ser feita observando as necessidades de modelagem quanto à abstração de conceitos geográficos, ao atendimento de requisitos usuais para modelos de dados. 2.1.5 - Banco de Dados Geográfico Um SIG tem como característica lidar com vários tipos de dados, por isso a sua estrutura deverá ser robusta o suficiente para suportar entrada de dados dos mais distintos possíveis. O banco de dados geográfico tem a capacidade de armazenar os mais variados dados de forma a preservar a topologia, projeção geográfica, atributos dos elementos dos objetos geográficos, e, consequentemente, realizar consultas específicas, recuperar dados, suportar análises espaciais, dentre outros. Os sistemas relacionais de gerência de bancos de dados SGDB’s utilizam de uma linguagem chamada SQL – Structured Query Language. Esse tipo de banco de dados suporta apenas uma massa de dados convencionais, ou seja, não suporta dados, como por exemplo, dados espaciais e temporais. Isso se deve que a linguagem SQL que foi criada pela IBM na década de 70 e, posteriormente, após sucessivas alterações, foi estabelecida no final da década de 90, como um padrão de linguagem para banco de dados. Esse padrão tem uma dificuldade em ter mecanismos eficientes de indexação espacial e ser incapaz de manipular de forma direta componentes espaciais armazenados no banco. Assim, os especialistas de tecnologia da informação passaram a estudar maneiras de criar uma ferramenta que fosse uma extensão de um SGBD relacional, mas que suportasse tipos de dados tão singulares com que o SIG trabalha. Nesse sentido, a criação de bancos de dados espaciais permitiu a integração de dados tanto alfanuméricos quanto espaciais. O primeiro banco foi criado em 1994, por Engenhofer, que propôs criar uma linguagem de consulta espacial baseada em SQL. Spatial SQL divide-se em duas sub-

22

linguagens, uma para consulta e outra para apresentação de objetos espaciais, buscando aproximar-se da forma como os seres humanos conceitualizam o espaço geográfico. A sublinguagem de consulta estende SQL com operadores e relacionamentos espaciais. Distingue-se de outras extensões por preservar os conceitos de SQL e por conseguir um tratamento de alto nível dos objetos espaciais. Segundo Hartmur (1994, apud Oliveira, 2013), banco de dados geográficos é um sistema de base de dados, que oferece tipo de dados espaciais em seu modelo de dados e sua linguagem de consulta suporta tipos de dados espaciais e sua implementação, fornecendo pelo menos indexação espacial e algoritmos eficientes para integração espacial. O uso de indexações espaciais são importantes em análises de dados geográficos, visto que otimiza o processo de acesso ao banco de dados que, normalmente, está armazenado na memória secundária do computador, sendo que essa memória é mais lenta do que a memória principal do computador. As aplicações de SIG lidam com base de dados complexas e bastantes volumosas, por isso há uma necessidade muito grande armazenamento em disco. Para resolver esse problema, uma consulta espacial é realizada em dois passos, sendo o primeiro feito a partir de uma “filtragem” de um índice espacial para selecionar os objetos candidatos que satisfaçam aquela consulta espacial. Posteriormente, o segundo passo é chamado “refinamento”; a partir da filtragem, é analisado sequenciamente, e o teste espacial é feito nas geometrias reais dos objetos, diminuindo o custo de complexidade computacional para avaliar os objetos espaciais. (Silva, 2002). Há basicamente três diferentes arquiteturas de SIGs que utilizam os recursos de um SGBD: a arquitetura dual, a arquitetura integrada e a arquitetura baseada em campos longos. A primeira armazena os dados alfanuméricos em um banco de dados relacional e os dados espaciais em arquivos com formato proprietário. A segunda arquitetura armazena ambos os dados em um único banco de dados. E a última armazenada os dados em um único SGBD, porém o armazenamento das representações geométricas dos objetos geográficos ocorre no campo longo do banco. Nesta abordagem, tanto a parte descritiva quanto a parte da representação geométrica do objeto geográfico estarão contidas no mesmo subsistema. O uso da arquitetura integrada é mais segura do que a dual, visto que, em um único SGBD, é possível controlar e manipular objetos espaciais quanto as transações e os controles de integridade. Na figura a seguir, é apresentado o modelo de arquitetura dual e integrada. 23

Figura 2.4 - Arquitetura de Bancos de Dados em SIG (Ferreira, 2003)

No mercado, estão presentes os bancos com extensão geográficas proprietários como o Oracle Spatial, IBM DB2 Spatial Extender, ARCSDE. A extensão PostGIS para o PostgreSQL foi desenvolvido pela comunidade de software livre, sendo que todos os bancos citados estão dentro dos padrões abertos definidos pelo OGC. O PostGIS e o Oracle Spatial optaram por fornecer mecanismos de indexação espacial baseados nas árvores-r, e o IBM DB2 Spatial Extender utiliza grades fixas multiníveis e space filling curves, de forma a não terem a necessidade de criar novas implementações de seus mecanismos de indexação sobrejacentes (árvores-b). O método de indexação de acesso multidmensionais em árvores tem como vantagem realizar a computação em um retângulo envolvente das geometrias e não diretamente nelas. Quando é solicitada uma consulta, primeiramente, é feito um filtro para reduzir a quantidade de possíveis candidatos que satisfaçam àquela pesquisa e, posteriormente, o refinamento para trazer a busca do candidato. Para esse modelo, a aplicação desse método é importante, pois são usados algoritmos bastante complexos e custosos que são aplicados na geometria no momento do refinamento e isso consome tempo de resposta e hardware. No método de grades, a indexação particiona o espaço segundo uma grade retangular, em que cada célula é associada a uma página, uma área no disco. Esta associação é feita por meio de uma matriz bidimensional, conhecida como diretório. Para objetos mais complexos, tais como polígonos, é utilizada a aproximação pelo seu retângulo 24

mínimo envolvente (MBR), sendo o objeto associado às páginas das células interceptadas por seu MBR. A resolução da grade é um ponto de grande importância para este tipo de indexação. (Teotônio, 2008). Segundo Egenhofer (1999, apud Silva, 2002), uma grande variedade de métodos de acesso espacial foi desenvolvida, cada uma buscando ocupar menos espaço em disco, mas sendo difícil de analisar qual método é o melhor. Segundo Ferreira (2002) a extensões citadas são limitadas, pois tratam somente dados vetoriais não suportando os dados matriciais. Isso significa que os bancos de dados geográficos não oferecem tipos de dados específicos para armazenar dados matriciais e nem recursos para executar operações espaciais sobre os dados. Recentemente, novos produtos estão sendo introduzidos no mercado com o objetivo de otimizar os SIG’s, como por exemplo: a extensão do PostGIS Topology, que suporta dados topológicos, e o PostGIS Raster, que suporta o armazenamento de imagens. Diante da evolução dos SGDB’s relacionais, o mercado tem utilizado desse tipo de ferramenta de forma eficiente para o gerenciamento dos dados geoespaciais. Porém, com os novos conceitos no campo da tecnologia da informação como a computação em nuvem e o big data, que lidam com uma massa de dados muito grande e precisam de um tempo de resposta muito rápido, os bancos não relacionais – NoSQL surgiram para suportar esse novo paradigma. Banco de dados NoSQL é uma ferramenta que não utiliza linguagem SQL para consultas, sem a necessidade de criar esquemas rígidos para o armazenamento de dados. Atualmente, há bancos NoSQL com extensão geoespacial, e a comunidade científica no campo geográfico tem estudado e aprimorado os conhecimentos nessa nova tendência. Como exemplo, os bancos CouchDB possuem uma extensão espacial chamada GeoCouch; o banco Neo4J possui uma extensão espacial chamada Spatial que faz indexação espacial. Recentemente, na tese defendida por Bart Baas (2012, tradução nossa), foi feito um estudo de benchmarking entre o banco de dados relacional PostGreSQL e sua extensão PostGis e o banco de dados NoSQL Neo4J com a extensão Spatial. O autor concluiu que o banco de dados NoSQL não substituirá o banco de dados relacional, mas o NoSQL poderá ser mais uma opção para ser aplicado em determinados projetos que necessitam executar tarefas específicas, como exemplo, operações rápidas ou integração com outros projetos em Java. Ele conclui que ambos os bancos poderão andar lado a lado.

25

Diante dos fatos apresentados, tendo em vista a crescente evolução dos bancos de dados, espera-se uma evolução no suporte espacial beneficiando o campo da geoinformação que precisa lidar com um volume cada vez maior de dados. 2.1.6 - Sistema de Informação Territorial - SIT A partir de um SIG, é possível iniciar o processo de constituição de um sistema mais abrangente e mais específico. Um Sistema de Informação Territorial visa armazenar e consultar informações descritivas e espaciais do território, para promover o crescimento ordenado de um município e a distribuição eficaz e justa de seus recursos (Silva, 2012). No SIT, deve conter: a. Subsistema de Referência a Dados, abrigando um conjunto de descrições sobre todos os dados disponíveis para os pesquisadores, documentando sua origem, procedência metodológica, entidade responsável pela produção, publicação ou acervo da qual faz parte, características de coleta, captura e representatividade; este sistema deve atuar como “pano de fundo” das bases de dados e espaciais, geradas e utilizadas pelos pesquisadores, garantindo a descrição necessária de todo e qualquer “item de dado” destas bases; tratase de uma intensificação das funções e recursos da base de metadados do SIG; b. Subsistema

de

Códigos

Locacionais,

documentando

as

distintas

especificações de estrutura espacial adotadas pelas entidades produtoras e fornecedoras de bases; não só a divisão política-administrativa, mas todas as formas de divisão territorial, especialmente aquelas criadas pelo estudo do espaço geográfico, são descritas e controladas, juntamente com as respectivas bases espaciais a que se referem; este subsistema facilita sobremaneira a integração de dados de diferentes fontes produtoras; c. Subsistema de Legislação, referenciando e resumindo toda a legislação que possa representar uma imposição normativa relevante, do políticoinstitucional em atuação na configuração do território; d. Subsistema de Programas Afins, documentando todo e qualquer programa governamental ou não, que esteja atuante, através do político-institucional, na organização do território;

26

e. Subsistema de Disseminação, garantindo a adequada difusão dos produtos do SIG através da Internet, permitindo consultas a dados e documentos a partir de mapas interativos e mobilizando a comunidade através de fóruns debatendo os resultados alcançados. 2.2

- COMPUTAÇÃO DISTRIBUÍDA

2.2.1 - Arquitetura Orientada a Serviços – SOA Conforme exposto anteriormente, em decorrência do crescimento de aplicações SIG’s heterogêneas e da necessidade de compartilhar dados entre instituições e empresas, diversos segmentos se reuniram para criar métodos e padrões para a troca de dados, assim surgia o OGC. Outro desafio para a indústria de SIG é compartilhar dados geográficos, visto que 60% dos custos de um projeto como esse estão ligados à produção dos dados, demorada e bastante minuciosa. Além disso, ao longo de vários anos, o mercado de SIG investiu grandes cifras em projetos vultuosos e caros, e esses valores também não poderiam ser descartados. Nesse sentido, a evolução da arquitetura de sistemas da informação e a maneira que os softwares passaram a ser produzidos a partir do marco da internet, a considerar o fácil acesso e custo benefício do hardware, vieram resolver essa situação. Assim, os sistemas passaram a ser divididos em pequenos blocos de código com uma função bem definida, encapsulados e de forma transparente. Especialistas preocuparam-se em adotar um padrão, de forma que a implementação não dependesse de uma linguagem definida ou tipo de plataforma, ou mesmo não precisassem de um tipo de pré-condição definida para serem executados. Essas funcionalidades precisavam possuir uma interface de comunicação para serem disponibilizadas por meio de serviços (funções de software) e proverem esse serviço para outro software. Na outra ponta, bastava apenas conhecer a interface do protocolo e envio do serviço para poder usufruírem das funcionalidades providas pelo mesmo. Diante desse cenário, a orientação a serviços surgiu para suprir a necessidade de troca de dados no mundo web unindo diversos conceitos e práticas sob um único paradigma.

27

Em Programa do Governo Eletrônico Brasileiro - e-PING, define-se SOA - ServiceOriented Architecture como uma arquitetura para interoperabilidade de sistemas por meio de conjunto de interfaces de serviços fracamente acoplados, em que os serviços não necessitam de detalhes técnicos da plataforma dos outros serviços para a troca de informações a serem realizadas. A arquitetura SOA é um paradigma computacional que flexibiliza o desenho, desenvolvimento e a execução de aplicações distribuídas. SOA utiliza serviços como elementos básicos para a composição das aplicações. (Momo et. al., 2011). Cada atividade é implementada como um serviço, ou seja, o componente poderá ser reutilizado quantas vezes necessárias para outros sistemas. Em aplicação SIG, a característica desse tipo de arquitetura é importante, pois é possível disponibilizar protocolos no padrão OGC como o WMS e reutilizá-lo para toda a cadeia interessada em ter um determinado mapa. Como nesse tipo de tecnologia não há limitação de implantação ou vínculo de linguagem ou plataformas, SIG’s desenvolvidos por linguagens proprietárias ou livres podem disponibilizar e consumir os serviços, desde que sigam um padrão ou regra para que tenham o serviço acessível e utilizável por meio de uma rede, o que significa interoperabilidade. Os serviços poderem ser reaproveitados indica que a adoção desse tipo de arquitetura é uma outra vantagem para as empresas e entidades, pois conseguem reduzir custos de projeto e desenvolvimento e, consequentemente, diminui o tempo total do mesmo. Para a implantação da arquitetura SOA pode-se adotar diversos tipos de protocolo, mas os comumente mais usados são: XML como linguagem responsável por representar os tipos de dados e compor as mensagens; SOAP como protocolo de troca de mensagens XML; HTTP para o envio das mensagens; WSDL para descrever o serviço e UDDI para listar serviços na rede. Fazendo uma analogia, o XML é a língua que é escrita no livro, SOAP é a mídia em que está o conteúdo do livro em si, WSDL é uma ficha catalográfica que descreve o conteúdo do livro e UDDI é uma biblioteca onde estão cadastradas todas as fichas catalográficas para pesquisa (Costa, 2011).

28

2.2.2 Web - Service Um dos principais alicerces para a implantação da arquitetura SOA é a adoção de Web Services para a implantação de serviços. Segundo Josutis (2007, apud Santana, 2009), a Microsoft lançou em 2000 o termo Web Service para se referir ao conjunto de padrões que permitem a comunicação entre dois computadores em uma rede. Web Service é um sistema de software identificado por uma URI (Identificador Uniforme de Recursos), cujas interfaces públicas e ligações são definidas e descritas utilizando-se XML. Sua definição pode ser descoberta por outros sistemas de software. Estes sistemas podem, então, interagir com o Web Service numa maneira prescrita na sua definição, usando mensagens baseadas em XML transportadas por protocolos da internet. (Júnior et. al., 2005) O XML utiliza marcações que não são pré-definidas, assim não são interpretadas pelo browser, ou seja, o browser não tem conhecimento de como apresentar os elementos XML. Para solucionar esse problema, foi criado padrão XSL (Extensible StyleSheet Language) para formatar o XML. O XSL permite filtrar e ordenar elementos XML, formatar e direcionar a saída de um documento para ser formatado em vídeo ou voz. Esta separação e apresentação do conteúdo torna a linguagem XML mais aperfeiçoada para o desenvolvimento de sistemas baseados na Web. Além disso, o XML permite que as informações sejam armazenadas em lugares distintos ao do modelo de apresentação de dados (XSL). Isso permite que se diferenciem os dados e a apresentação, o que em HTML não era possível. Esse tipo de tecnologia permite a interoperabilidade de dados e, por isso, é de grande importância para a troca de dados geográficos. Por meio da criação de um portal WEB GIS, suportado por essa tecnologia, órgãos governamentais ou mesmo empresas podem trocar dados geográficos de forma segura independentemente da plataforma de software ou hardware utilizado. 2.2.3 Computação em Cluster Conforme citado ao longo do presente trabalho, a análise de dados espaciais exige um poder de processamento muito grande. Os SIG’s Web necessitam de alta escalabilidade e disponibilidade. Para tanto, os especialistas em tecnologia da informação necessitam criar um ambiente de infraestrutura de hardware, de forma a aumentar a velocidade dos

29

processadores e demais componentes do sistema a fim de atender uma demanda por requisição de serviços vinda de qualquer lugar do globo. Assim, a computação em cluster, conjunto composto por dois ou mais computadores (monoprocessáveis ou multiprocessáveis) que trabalham em harmonia, buscando fornecer uma solução para um problema geral ou específico, é comumente utilizada em aplicações que possuem conteúdo crítico ou quando os serviços precisam ser processados o mais rápido possível, sendo aplicado em áreas como biotecnologia, petroquímica, modelagem e mineração de dados, processamento de imagens e servidores de música e jogos para a Internet. É uma tecnologia usada para aplicações que necessitam de um alto desempenho, mas que possui um custo substancialmente menor. Nessa arquitetura, cada um dos equipamentos interligados é chamado de nó e, normalmente, existe um nó principal que gerencia e divide tarefas entre os demais nós. Algumas vantagens desse tipo de tecnologia são:  Escalabilidade: é possível aumentar o desempenho aumentando a quantidade de máquinas que compõe o cluster;  Alta disponibilidade: Um nó desativado não prejudica o desempenho do sistema como um todo;  Tolerância a falhas: o cluster funciona de maneira paralela e distribuída, mantém o funcionamento mesmo com a interrupção de algum dos nós, sendo possível o redirecionamento da carga de processamento para outro nó;  Balanceamento de carga: Cluster de computadores também podem ser formados de forma heterogênea, ou seja, com máquinas com configurações diferentes, sendo possível realizar o balanceamento de carga para máquinas com maior ou menor processamento para executar tarefas distintas;  Baixo custo: utilizam recursos de fácil acesso. Segundo Bacellar, cluster é um sistema distribuído de computadores independentes e interligados, cujo objetivo é suprir a necessidade de um grande poder computacional com um conjunto de computadores de forma transparente ao usuário. Segundo Pitanga (2003, apud Ferrão et. al., 2012), a computação em cluster não é uma área nova, mas, sim, o resultado de um constante aperfeiçoamento de estudos e pesquisas em computação distribuída e paralela, engrenada, principalmente, pelo

30

desenvolvimento de processadores de alto desempenho, aprimoramento das redes de comunicação e padronização de ferramentas de computação distribuída e paralela tanto em softwares quanto em hardwares. Os clusters podem ser de três tipos, conforme a seguir: a. Balanceamento de carga integram os nós para que toda as requisições provenientes dos clientes sejam distribuídas de maneira equilibrada entre os nós “escravos”. Os sistemas não trabalham junto em um único processo, mas redirecionando as requisições de forma independente assim que chegam baseado em um escalonador. b. Alta disponibilidade: A arquitetura é estruturada de forma que os serviços sejam prestados de forma interrupta e caso um dos nós do cluster vier a falhar as aplicações ou serviços passam a estar disponíveis por meio de outros nós. c. Combinação do cluster de balanceamento de carga e alta disponibilidade: Este tipo de configuração é usado para servidores web de e-mail entre outros; d. Processamento distribuído ou processamento paralelo: Usado para grandes tarefas computacionais. Uma grande tarefa computacional pode ser dividida em pequenas tarefas que são distribuídas entre os nós como se fosse um supercomputador massivamente paralelo. Em projetos de Web SIG, nos quais os usuários solicitam uma requisição muito grande de serviços e precisam lidar com uma massa de dados bastante complexa e computacionalmente intensiva, adotar clusters baseados em balanceamento de carga e alta disponibilidade é útil para ganho de performance e escalabilidade. 2.3

- PADRÕES ABERTOS

2.3.1 Interoperabilidade dos dados Geográficos Segundo Ariza (2002 apud Guedes, 2010), a expansão do uso de geotecnologias por diversos usuários, não necessariamente especialistas em geoinformação, tem ocasionado inadequações na utilização e integração de dados. A falta de planejamento na coleta de dados ou mesmo a utilização de padrões para a elaboração da informação.

31

Os vários formatos de dados, a adoção de diferentes projeções cartográficas, escalas, simbologias e a utilização de softwares diversos são questões de heterogeneidade dos dados comprometendo o compartilhamento e a reutilização dos mesmos. Com o avanço tecnológico e o surgimento dos primeiros SIG’s apoiados por ferramentas de tecnologia da informação, diferentes ferramentas passaram a serem usadas, mas sem um padrão. De acordo com Guedes (2010), “o intercâmbio de dados geoespaciais é um importante desafio no uso de geotecnologias, impulsionado pelo alto custo na produção de dados. Em sistemas heterogêneos, os custos de aquisição de dados variam de 60 a 80% do valor do custo total da implantação de um SIG.” É nesse sentido que surgiu a Infraestrutura de Dados Espaciais – IDE’s como fonte de criar normas, políticas, tecnologias e recursos humanos necessários para adquirir, processar, armazenar, distribuir e melhorar a utilização dos dados georreferenciados (Lunardi, 2006 apud Guedes, 2010). A Comissão Nacional de Cartografia – CONCAR afirma que uma linguagem comum é o requisito essencial para uma comunicação efetiva (CONCAR, 2012). O objetivo das IDE’s é a busca de soluções para os problemas de interoperabilidade dos dados, visto que os SIG’s utilizam dados geográficos com modelos e estruturas diferentes. Para Burity et. al., (2003, apud Guedes, 2010), a migração entre sistemas só é possível quando os dados são padronizados. O intercâmbio de dados é a capacidade de compartilhar e trocar dados, informações e processos entre diferentes usuários de geoinformação. O grande desafio do intercâmbio dos dados é enfrentar a diversidade de modelos conceituais dos SIG’s disponíveis no mercado. Esforços em todo o mundo estão sendo feitos no sentido de estabelecer IDE’s para os níveis: global, nacional, regional ou local, para que os segmentos que utilizam dados geográficos possam ter acesso de maneira e simples a essas informações para auxiliarem seus projetos. O OGC (Open Geospatial Consortium) surgiu exatamente a partir das frustrações das agências governamentais, órgãos de defesa e mercado privado, que fizeram grandes aportes no desenvolvimento de SIG’s; no entanto, essas ferramentas não conseguiam compartilhar dados geoespaciais entre sistemas. O Consórcio conta com 475 membros entre órgãos do governo, instituições acadêmicas e mercado privado e tem como objetivo desenvolver padrões de interface para acesso público, suportando soluções interoperáveis baseadas na internet, que também são 32

desenvolvidas para trabalhar com informações espaciais complexas e serviços utilizados por diferentes tipos de aplicações para diversos segmentos, como por exemplo: aviação, Defesa e Inteligência, Energia, Geociência, Engenharia dentre outros. Atualmente, tanto o mercado público quanto o privado têm utilizado dos padrões de interoperabilidade do OGC em suas aplicações SIG’s, sendo os padrões mais usados as extensões: WMS, WFS, GML, KML e SLD. O padrão GML(Geography Markup Language) foi especificada para o transporte e armazenamento de informação geográfica, incluindo propriedades espaciais e não espaciais das feições geográficas. O objetivo da GML é oferecer um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados. Esse padrão é baseado em esquemas eXtensible Markup Language – XML. O esquema XML define os elementos usados em um documento que descreve os dados. (Júnior et al. 2005). O padrão WFS (Web Feature Service) fornece aos usuários acesso a feições georreferenciadas e seus atributos, podendo, inclusive, manipulá-los. A partir de uma requisição que especifique o recurso desejado, o servidor deve retornar os dados georreferenciados com geometrias e os atributos, no caso de uma consulta, ou inserir, atualizar ou remover dados, no caso de uma transação. Tanto a requisição quanto as respostas de serviços WFS são documentos XML. O WMS (Web Map Service) define um serviço para a produção de mapas na internet. Neste sentido, o mapa é uma representação visual dos dados geográficos e não os dados de fato. Os mapas são produzidos em formato de imagem como JPEG, GIF etc. Quando o cliente requisita um serviço WMS, um conjunto de parâmetros deverá ser informado ao servidor como: as camadas desejadas, os estilos que deverão ser aplicados sobre as camadas do mapa, a projeção de coordenadas, o formato e o tamanho da imagem gerada. Esse tipo de serviço possui algumas operações sendo as principais: a. GetCapabilities: permite que um cliente recupere metadados descrevendo as características do servidor; b. GetMap: retorna a imagem de um mapa incluindo parâmetros como altura e largura do mapa, as coordenadas de referência o estilo e o formato da imagem. c. O Web Coverage Service – WCS é um protocolo para dados de cobertura, ou seja, para a representação de dados contínuos no espaço, como por

33

exemplo, uma imagem de satélite ou uma imagem de radar. Esse tipo de serviço fornece apenas a imagem junto com os dados daquela cobertura. O Keyhole Markup Language – KML é um padrão para visualização de dados georreferenciados em softwares que representam o globo terrestre. Nesse contexto, entende-se visualização como, além da representação dos dados, todo o controle da navegação do usuário, altitude em que o dado será visualizado, inclinação, movimentação em qualquer direção entre outras opções de navegação. Permite codificar dados georreferenciados em um globo terrestre digital e como esses dados serão exibidos. Esse padrão também se baseia em XML e foi proposto pela Google em 2007. (Costa, 2011). O Styled Layer Descriptor – SLD é um padrão de que estende às funções de um WMS para que o usuário possa estabelecer regras de aparência para a produção de mapas personalizados. Esse padrão também permite o acesso a simbologias das legendas utilizadas no mapa. Outra iniciativa de padronização de dados é o Governo Brasileiro por meio do Infraestrutura Nacional de Dados Espaciais – INDE que engloba as tecnologias, políticas normas e recursos humanos necessários para adquirir, processar, armazenar, distribuir e melhorar a utilização dos dados georeferenciados. É a Concar – Comissão Nacional de Cartografia, que possui a missão de coordenar, orientar a elaboração e a implementação da Política Cartográfica Nacional e a manutenção do Sistema Cartográfico Nacional com vistas à ordenação da aquisição, produção e disseminação de informações geoespaciais para a sociedade. A Concar é a responsável por criar a especificação técnica para a Estruturação de Dados Geoespaciais Vetoriais (ET-EDGV), Estrutura de Dados Geoespaciais Matriciais (ET-EDGM), Estrutura de Metadados Geoespaciais (EMDG) e o Exército Brasileiro pela criação as especificações técnica para a aquisição de dados Geoespaciais Vetoriais (ETADGV), Estrutura de Representação Cartográfica dos Dados Geoespaciais Vetoriais (ETRDGV). A padronização e estruturação desses dados tornaram-se necessárias para garantir a aceitabilidade da qualidade, a precisão e a acurácia dos produtos cartográficos digitais que passaram a existir a partir da evolução tecnológica. Com o desenvolvimento dos mapas digitais e a manipulação da informação geográfica por meio dos SIG’s, surgiu a necessidade de também padronizar os metadados geográficos.

34

Assim, a partir da disponibilização dos SIG’s na web, é importante descrever as características dos dados, como por exemplo: quem o produziu, quando, onde e como. Essas informações devem estar disponíveis para facilitar as interfaces de consultas e a recuperação de uma base de dados, além é claro da troca de dados entre quem produz o dado ou apenas o usuário que o consome. A tecnologia da informação tem colaborado com a geoinformação na divulgação dos metadados. O GeoNetwork Opensource é uma aplicação de catálogo de dados geográficos baseada em padrões abertos, que auxilia os usuários a reunir e publicar metadados de dados geoespaciais na web.

35

3

- REFERENCIAL TECNOLÓGICO

Neste capítulo, apresentar-se-ão as principais ferramentas tecnológicas adotadas para o desenvolvimento da aplicação SIG Web, seguidas da apresentação das ferramentas usadas para esse trabalho, que estão organizadas nas seções discriminadas a seguir. Na seção 3.2, será visto o Sistema Gerenciador de Banco de Dados; na seção 3.3, o Banco de Dados Geográfico; na seção 3.4, Aplicativos Geográficos, a serem utilizados para o ambiente de desenvolvimento da aplicação; na seção 3.5, Servidor de Mapas – Geoserver, ferramenta usada para a disponibilização de mapas para esse projeto; na seção 3.6, Ferramentas para o Desenvolvimento de Aplicações Web e apresentação das linguagens de programação usadas nesta pesquisa para a construção da aplicação SIG Web; na seção 3.7, Servidores Web e apresentação de uma proposta de uma arquitetura distribuída com objetivo de suportar uma aplicação web. 3.1

- FERRAMENTAS DE MERCADO PARA WEB SIG

Atualmente, estão disponíveis no mercado diversas ferramentas de SIG em vários formatos, desde sistemas proprietários até o desenvolvimento de aplicações pela comunidade de software livre. As aplicações mais difundidas são: framework da ESRI, a maior fabricante de ferramentas de SIG no mundo, e o framework da Google, ambos proprietários. Por outro lado, nos últimos anos, os trabalhos realizados tanto pela academia quanto pelos órgãos e agências governamentais permitiram a evolução do software livre na área de SIG. Servidores de aplicação como o GeoServer, Mapserver e o TerraLib são bons exemplos de produtos equivalentes aos softwares proprietários. A proposta dos frameworks é desenvolver uma interface gráfica ao usuário que facilite a construção de mapas, visualizar os mapas de forma interativa e personalizada, além de simular cenários a partir da apresentação dos mapas para a tomada de decisão, tudo isso por meio da Web 2.0. Várias organizações e empresas disponibilizam mapas interativos baseados na Web 2.0, como a Microsoft com o Bing, o Google com o Google Maps, Yahoo com o Yahoo Maps e o Open Street Map. Geralmente, essas empresas utilizam imagens de satélite e imagens aéreas para compor seus mapas. 36

Conforme citado, a arquitetura de SIG-Web é baseada em três camadas, sendo que as soluções proprietárias utilizam dessa estrutura, e a comunidade livre detém alguns sistemas livres que possuem compatibilidades entre eles para formarem esse tipo de arquitetura. A ESRI comercializa uma plataforma completa tanto para a produção e tratamento de imagens e rasters (ArcMap, ArcView, ArcInfo), quanto para o servidor de aplicação de mapas para a Web (ArcServer), além da biblioteca espacial ArcSDE e a camada de apresentação ao usuário em Adoble Flex, HTML5 ou Silverlight. Como desvantagem, a arquitetura proposta pela ESRI é baseada em código fechado, o que não é ideal para algumas empresas e instituições, que precisam fazer muitas customizações para adaptar a aplicação ao seu negócio é ponto agravante, pois o escopo de implantação poderá ser longo e ter um custo muito elevado. A Google propõe uma arquitetura baseada nos produtos: Google Earth, Google Server Earth Enterprise, Google Earth Fusion e a camada de apresentação ao usuário da API Google Maps. O Google Earth Fusion é um motor de reenderização de imagens, dotado de um algoritmo que compacta os vetores, de forma que, ao apresentá-los ao usuário, esses são processados e carregados de forma mais rapidamente do que outros produtos disponíveis no mercado. O Server Earth Enterprise é o responsável por publicar e disponibilizar os mapas para o ambiente web que é baseado na API do Google ou acessado pelo computador por meio do Google Earth Client. A arquitetura Google disponibiliza somente o protocolo KML, que está dentro do padrão OGC. Essa é uma das primeiras desvantagens da aplicação. Outra desvantagem é o código da API ser fechado, sendo necessário que as empresas e instituições desembolsem com a aquisição de licenças e também com a contratação de empresa especializada em customizar a aplicação para seu negócio. Além disso, há pouca quantidade de funções disponíveis em sua API, apresentando mais como uma biblioteca compilada para ser incorporada a outro aplicativo e sua fonte proprietária inalterável. (Pascual, 2013). O servidor de publicação de mapas, desenvolvido pela comunidade de software livre, GeoServer foi concebido em Java (J2EE) e dentro dos padrões da OGC para a publicação de serviços WFS, WMS, GML e SFS (PostGis). O GeoServer é a implementação de referência para WFS do OpenGIS e WFS-T. Além de integrar com as principais bibliotecas geoespaciais como OracleSpatial, PostGis, ArcSDE. O GeoServer suporta vários componentes e módulos reconhecidos pela 37

comunidade OpenGIS, como GeoWebCache. Essa ferramenta em Java, além de implementar vários serviços do OGC (WMS, WMTS, Google Maps KML) tem um motor que acelera e otimiza a renderização dos vetores. O MapServer é um servidor de publicação de mapas também baseado em plataforma livre. O primeiro projeto do MapServer foi desenvolvido para dar suporte a NASA na disponibilização de imagens de satélite para a população. Mais tarde a fundação OpenGIS incluiu esse servidor como uma opção de software livre para projetos SIG. O sistema fornece funcionalidades para sustentar uma ampla variedade de aplicações web, além da leitura de dados de SIG, permitindo a criação de “imagens de mapas geográficos”. (Granemann, 2009). Segue os padrões do OGC para os serviços WMS, WFS, GML, WCS dentre outros, além de possuir suporte às linguagens de programação como PHP, Perl, Python, Java, dentre outras ou também pode ser acessado por meio da API do MapServer. Também, reconhece os formatos ShapFiles, TIFF/Geo e possui suporte as principais bibliotecas de dados espaciais como o Oracle Spatial, PosGIS. 3.2

- SISTEMA GERENCIADOR DE BANCO DE DADOS – POSTGRESQL

Segundo as informações constantes do sítio eletrônico do Postgre, o referido sistema é um poderoso sistema gerenciador de banco de dados objeto relacional, gratuito e de código fonte aberto, que está há mais de 15 anos em plena evolução e suportado pelos principais sistemas operacionais como por exemplo: Linux, Unix e Windows. O PostgreSQL segue os conceitos ACID (acrônimo de Autenticidade, Consistência, Isolamento e Durabilidade), ou seja, suporta transações do tipo chaves estrangeiras, junções, gatilhos. Conta com funcionalidades como controles de multiusuários, recuperação de dados, concorrência multiversionado, planejador de consultas, replicação assíncrona, altamente escalável, dentre outros. É compatível com linguagens como PL/PGSQL, PL/Perl, PL/Python, PL/Java. O banco PostgreSQL suporta tipos de dados geométricos, operadores espaciais simples e indexação espacial por meio de uma R-Tree nativa ou de uma R-Tree implementada no topo de mecanismo de indexação GiST ( Generalized Serach Tree). O GiST consisti em um índice (árvore balanceada) que pode fornecer tanto as funcionalidades de uma B-Tree quanto de uma R-Tree e suas variantes. A principal vantagem desse índice é a possibilidade de definição do seu “comportamento”. (Queiroz et. 38

al,, 2013). Importa consignar que o GiST serve como base para muitos projetos públicos que utilizam o PostgreSQL como OpenFTS e PostGIS. 3.3

- BANCO DE DADOS GEOGRÁFICO

3.3.1 PostGis O PostGis é uma extensão do banco de dados PostGreSQL, mantido pela empresa Refractions Research, e provê mais de 300 tipos de operadores espaciais, funções espaciais, tipos de dados espaciais e indexações espaciais. O suporte aos operadores espaciais é fornecido por meio da integração com a biblioteca GEOS (Geometry Engine Open Source), sendo essa uma tradução da API Java Topologic Suite (JTS) para linguagem C++. Está de acordo com o padrão Simple Features for SQL – SFSQL especificação do OGC. Segundo Queiroz et. al., (2006), a criação de uma tabela com tipo espacial no PostGIS é realizada em duas etapas. Na primeira, são definidos os atributos alfanuméricos, e, na segunda, é utilizada a função AddGeometryColumn para adicionar a coluna com o tipo espacial. Essa função, implementada no PostGIS e especificada no OpenGIS, realiza todo o trabalho de preenchimento de uma tabela especial de metadados, denominada “geometry_columns”. Os parâmetros dessa função são:  Nome do banco de dados;  Nome da tabela que irá conter a coluna espacial;  Nome da coluna espacial;  Sistema de coordenadas em que se encontram as geometrias da tabela;  Tipo da coluna espacial, que serve para criar uma restrição que verifica o tipo do objeto sendo inserido na tabela;  Dimensão em que se encontram as coordenadas dos dados. Após criar as tabelas, pode-se inserir os dados usando o comando SQL INSERT. Para isso, pode-se usar a representação textual das geometrias em conjunto com a função GeometryFromText, que recebe a representação textual e mais o sistema de coordenadas em que se encontra a geometria e compõe o objeto geográfico para armazenamento. O PostGis adota a arquitetura integrada para recursos de banco de dados. Segundo Ferreira (2003):

39

“Esse tipo de arquitetura contêm funcionalidades e procedimentos que permitem armazenar, acessar e analisar dados espaciais de formato vetorial. Como desvantagens dessa arquitetura podem ser citadas a falta de mecanismos de controle de integridade sobre os dados espaciais e a falta de padronização das extensões da linguagem SQL para tratar dados espaciais.”

3.4

- APLICATIVOS GEOGRÁFICOS

3.4.1 - ArcGIS/ArcSDE O ArcSDE (Spatial Database Engine) é uma extensão integrante do produto ArcGis versão Desktop ou Server desenvolvida pela empresa ESRI Incorp. Essa ferramenta permite acessar e gerenciar os dados espaciais em um SGBD. O framework geodatabase da ESRI, que é uma combinação de dados espaciais com repositório de dados, é o modelo de armazenamento principal para a plataforma ArcGIS, sendo um local central para acessar e gerenciar os dados espaciais. O ArcSDE tem uma funcionalidade nativa que permite a integração com diversos SGBD relacionais, como o Oracle e sua extensão espacial, PostGreSQL e sua extensão espacial, SQLServer, DB2, dentre outros, permitindo assim manipular dados geográficos, além do padrão de consultas definidos pelo OGC chamado Simple Features for SQL – SFSQL. Essa extensão segue os preceitos de arquitetura de SIG, que utilizam recursos de banco de dados chamada arquitetura integrada, conforme conceitos apresentados na seção 2.1.5 – Banco de Dados Geográficos. O ArcSDE define um modelo lógico próprio para os dados matriciais implementado sobre o modelo físico de cada SGBD.

Isso significa que o ArcSDE

armazena os dados vetoriais em tipos de dados espaciais (SGBD com extensão espacial) ou em BLOBs (SGBD sem extensão), e os dados matriciais são armazenados em BLOBs em todos os SGBDs. Adotando esse tipo de armazenamento para dados vetoriais as, consultas de dados rasters são otimizadas, visto que somente os blocos necessários para atender àquela consulta serão retornados, ao invés de todo o dado, ao passo que o dado matricial é 40

armazenado em diferentes resoluções (pirâmides). Esse procedimento também colabora com a performance das consultas para estes tipos de dados, pois diminui a quantidade de dados transferidos para a aplicação cliente. Para cada banco de dados, o ArcSDE cria várias tabelas de sistema, no esquema do usuário do ArcSDE, para armazenar metadados sobre os dados geográficos. (Ferreira et. al., 2006). Para Ferreira et. al., (2003), armazenar os dados usando campos longos (BLOB) pode propiciar as seguintes caracteristicas:  Não capacidade de capturar a semântica dos dados espaciais: como o SGBD trata o campo longo como uma cadeia binária, não é possível conhecer a semântica do seu conteúdo;  Métodos de acesso espacial e otimizador de consultas devem ser implementados pelo SIG: como o SGBD trata os dados espaciais como uma cadeia binária, não possui mecanismos satisfatórios para o seu tratamento;  Limitações da linguagem SQL para a manipulação dos dados espaciais: a SQL padrão oferece recursos limitados para o tratamento de campos longos. Por meio da ferramenta, é possível ter o controle de multiusuários e realizar a edição on-line dos dados e o controle de versionamento. O ArcCatalog é uma interface gráfica (GUI) usada para gerenciar os dados espaciais via o ArcSDE. Para que seja possível a manutenção e a produção de dados vetoriais e matriciais, utilizando a plataforma ESRI, é necessário que os usuários utilizem os produtos da plataforma ArcGis Desktop, API web ArcGIS ou ArcGIS Mobile. Já para atualizar o banco de dados a partir da produção ou manutenção dos dados, os técnicos acessam a interface ArcCatalog, e essa se conecta ao ArcSDE para a atualização das informações do banco de dados. A seguir, expõe-se uma figura com a estrutura de funcionamento da plataforma ArcGIS para um ambiente corporativo.

41

Figura 3.1 - Arquitetura do ArcSDE (ESRI, 2013)

A ferramenta cria um modelo de dados lógico próprio para representar dados geográficos nos SGBD’s, ou seja, a sua utilização fica restrita ao uso de ferramentas proprietárias da suíte ArcGIS. 3.5

- SERVIDOR DE MAPAS - GEOSERVER Um dos meios de viabilizar o Web SIG é a adoção de um servidor de publicação de

mapas. Esses servidores permitem aos clientes a visualização interativa dos dados geoespaciais e a criação de mapas de forma colaborativa por meio do acesso à web. A produção de dados geoespaciais por si só consomem grandes recursos de processamento dos computadores, conforme já mencionado. Levar os dados geográficos para um ambiente web exige não só um poder de hardware maior, mas um servidor eficiente de publicação de mapas de forma que, ao apresentar a interface ao usuário, seja possível ele manipular e visualizar os mapas no menor tempo possível. É nesse cenário que o uso de um servidor de aplicação de mapas web torna-se importante no processo de desenvolvimento de uma aplicação Web SIG, sendo que é por meio desse aplicativo que será possível disponibilizar mapas interativos, ou simples consultas ou mesmo a edição on-line de dados geográficos. 42

A OGC desenvolveu um modelo mínimo para a disponibilização dos dados geoespaciais, de acordo com a figura a seguir:

Figura 3.2 - Modelo OGC de disponibilização de dados geoespaciais (modificado – Granemann, 2009) O modelo proposto pela OGC segue a seguinte composição:  O processo de seleção retorna os dados localizados em uma base de dados geoespacial de acordo com as consultas realizadas, como a área de seleção de temas;  O elemento gerador de visualização processa os dados da seleção geoespacial em uma sequência de elementos de visualização. Ele anexa os estilos como símbolos e linhas, gera notações alfanuméricas, gera a ordem de visualização dos elementos e realiza outros processamentos gráficos;  A renderização é responsável por obter os elementos de visualização e gerar um mapa renderizado ( ex. arquivos GIF); e  O processo de visualização torna o mapa renderizado visível ao usuário por meio de um dispositivo de visualização adequado ( Ex.: navegadores de internet.) A partir do uso desse tipo de servidor aliado com os padrões e protocolos de interoperabilidade definidos pelo OGC, é possível que as empresas e governo possam compartilhar dados, acessar, visualizar e operar mapas. Esse aplicativo entrega, entre outras especificações, um conjunto de interfaces para comunicação de alguns comandos

43

para a sobreposição automática de dados geoespaciais. Esse conjunto de interfaces é conhecido pelo OpenGIS como Web Map Server Interfaces Implementation Specification. Para esse projeto, foi adotado o servidor de publicação de mapas da comunidade livre GeoServer, visto que seria inviável adotar uma ferramenta proprietária por motivos de restrições orçamentárias. O Geoserver foi iniciado em 2001 pelo projeto Open Planning, uma empresa sem fins lucrativos localizada nos Estados Unidos. O principal objetivo, a princípio, era a implementação do protocolo WFS, que é um dos tipos de padrões adotados pela comunidade do Consórcio livre de Geoprocessamento – OGC. Posteriormente, a aplicação evoluiu para suportar outros tipos de padrões como WMS, WCS, além de formatos de dados vetoriais como Shapefile, GML, GeoTIFF dentre outros. Em 2007, passou a suportar os formatos KML, GeoRSS e o GeoJSON (Geographic JavaScript Object Notation) que são outros tipos de padrões além do OGC. A figura abaixo representa os principais protocolos suportados pelo GeoServer.

Figura 3.3 - Protocolos suportados pelo GeoServer (Jeevanchaaya, 2009)

44

Na figura apresentada abaixo, seguem os principais módulos da arquitetura do Geoserver.

Figura 3.4 - Arquitetura do GeoServer (Jeevanchaaya, 2009)

O Spring é utilizado para fazer a ligação com os outros módulos. O módulo principal é responsável pela configuração das funcionalidades comuns aos vários serviços. A interface do utilizador é responsável pela implementação de toda a interface Web que possibilita ao administrador do sistema fazer toda a gestão dos vários conteúdos. O módulo dados é responsável pelos dados do tipo vetor e raster e, por fim, o GeoTools que corresponde à biblioteca Java, sendo responsável por suportar diferentes tipos de dados como Shapefile, PostGis, ArcSDE, Oracle etc. Segundo Rita (2010), “a construção das imagens dos mapas também está a cargo da biblioteca GeoTools. Essa biblioteca é também responsável pela interpretação dos estilos presentes no documento SLD.” O GeoServer conta nativamente com o pacote de aplicações chamado OpenGeo Suite que é composta pelo GeoExplorer, uma aplicação para visualização, navegação e gestão de mapas e pelo GeoWebCache que acelera a visualização das imagens, por meio de um fusionamento e geração de caches dessas imagens. Segundo um estudo realizado por Liu et. al., (2010), o tempo de resposta para um pedido WMS usando o GeoWebCache foi 36% mais rápido sem a adoção dessa ferramenta. 45

Além das ferramentas citadas, o GeoServer possui em seu motor uma API Rest que facilita a troca e o consumo de serviços de geoinformação, possibilitando a interoperabilidade de dados geográficos. REST é um conjunto de princípios que definem como HTTP e URI’s devem ser usados. As aplicações web são, geralmente, baseadas em HTTP e XML e outras partes em JavaScript Object Notation – JSON. Para o usuário, ao digitar um endereço no browser para visualizar uma página na internet, é apresentado o protocolo HTTP que é responsável por processar o pedido, o envio e a informação solicitada de volta ao browser, que, por sua vez, faz a formatação e mostra o conteúdo ao utilizador, tornando assim o servidor HTTP como uma das peças fundamentais para se montar um servidor de página para Internet. O GeoServer, por ser um servidor web de mapas, funciona da mesma forma que um servidor web, contudo disponibiliza protocolos do padrão OGC. Na tese de Rita (2010) é explicado de forma bem clara como o Geoserver trabalha com pedidos HTTP para a função GET de um serviço WMS. Segundo o autor: “Verificamos que no tratamento de um dado pedido é criado um interpretador específico dos valores KVP para o pedido em questão, e que ao interpretar os valores devolve um objeto tipo Request que representa o pedido. No caso de um pedido GetMap feito ao serviço WMS a interpretação dos valores KVP é feito utilizando um objecto do tipo GetMapKVPReader. Verificamos que é criado um objecto do tipo GetMapRequest que representa um pedido GetMap. Este objeto irá conter os parâmetros contidos no pedido, tais como o CRS, as camadas e o documento SLD descodificado, caso este exista. Como podemos verificar na execução, a descodificação do documento SLD é efetuada recorrendo à biblioteca GeoTools. Após o GeoTools interpretar o SLD com as novas extensões é necessário que módulo WMS seja modificado de modo a suportar estas extensões. Assim, foi analisada a execução de um pedido GetMap. A execução deste pedido é efetuado no método execute da classe GetMapResponse. Podemos verificar que é criado um objeto do tipo WMSMapContex que irá conter os vários parâmetros necessários à criação de um mapa, tais como o código CRS, o BBOX, a altura e a largura,

46

transparência e cor de fundo. Cada camada presente no pedido é processada e é adicionada ao WMSMapContext juntamente com o seu estilo associado.” (Rita, 2010, p.46, tradução nossa)

É fornceido, no quadro abaixo, um exemplo de requisição GetMap utilizando a base de dados do Siturb: Tabela 3.1 - Exemplo de um pedido GetMap a um WMS via GET do GeoServer http://IP:8080/geoserver/sedhab/wms?service=WMS&version=1.1.0&request=Get Map&layers=sedhab:CATALOGO_FOTO_AEREA_20091&styles=&bbox=144675.0,821 8985.5,259336.0,8289560.5&width=536&height=330&srs=EPSG:31983&format=applicat ion/openlayers

Neste pedido, podemos ver que o primeiro parâmetro refere-se a uma solicitação de serviço HTTP; a requisição GetMap é uma operação usada no protocolo WMS, para buscar e apresentar uma imagem do mapa, conforme conceito apresentado na seção 2.7 – Interoperabilidade dos Dados Geográficos. O parâmetro “LAYER” é o nome da camada; o parâmetro Style informa ao servidor os estilos para aquele mapa; o parâmetro “EPSG” refere-se à projeção; o “BBOX” é um parâmetro que informa o ponto espacial a ser usado para este mapa, e os últimos parâmetros são as propriedades da imagem. Além das funções apresentadas, que são nativas da aplicação, a comunidade de software livre criou vários plug-ins que podem ser adicionados ao servidor com o objetivo de melhorar performance. 3.6

- FERRAMENTAS PARA O DESENVOLVIMENTO DE APLICAÇÕES WEB

3.6.1 - Hypertext Markup Language 5 - HTML5 De acordo com o consórcio World Wide Web (W3C), a web está baseada em três pilares: Um esquema de nomes para localização de fontes de informação na Web, chamado URI; um protocolo para acessar estas fontes, hoje, o HTTP, e uma linguagem de hypertexto, para a fácil navegação entre as fontes de informação, o HTML.

47

O HTML é um acrônimo de Hypertext Markup Language ou linguagem de marcação de texto, ou seja, uma linguagem que permiti a publicação de conteúdo na web. O padrão surgiu na década de 90 a partir do crescimento da internet. Foi concebida como uma linguagem para descrever semanticamente documentos científicos e, posteriormente, passou a ser utilizada em aplicações web. O objetivo do HTML era ter uma linguagem independente de plataformas, navegadores web e outros meios de acesso, ou seja, permitir a interoperabilidade. O HTML5, por sua vez, é uma evolução do HTML que passou por várias versões de melhorias, principalmente, a partir de 2007, quando foi feito um termo de cooperação entre o consórcio W3C e o grupo Web Hypertext Application Technology (WHATWG) com o objetivo de se criar uma versão HTML que trouxesse mais flexibilidade para a produção de websites e sistemas baseados na web. Antes do HTML5, desenvolver páginas web de forma interativa não era tão rápido como nos últimos anos. Nesse contexto, essa linguagem veio para facilitar a manipulação de elementos tornando as aplicações web interativas, leves e funcionais sem a necessidade a instalação de plug-ins. Esse padrão tem como princípio o uso de ferramentas para CSS e JavaScript. A CSS (Cascading Style sheets) é uma linguagem, a qual descreve os estilos, aparências e formatações que uma aplicação web escrita em HTML terá, e o JavaScript é uma linguagem dinâmica que possibilitará dar interatividade a uma página web. O HTML fornece a estrutura, o CSS adiciona o estilo e o JavaScript a interatividade. Os navegadores web de mercado possuem em seu núcleo um interpretador de JavaScript permitindo a execução dessa linguagem. Um dos problemas para o uso do HTML5 é exatamente a compatibilidade desses interpretadores com o JavaScript. Essa é uma das desvantagens em usá-la, porém esse problema está sendo superado, pois os grandes fabricantes de navegadores web têm interesse em suportar esse tipo de padrão. 3.6.2 - JavaScript JavaScript é “uma técnica de programação que funciona percorrendo e buscando seus alvos (elementos de marcação) na árvore do documento, ou seja, um script só consegue executar sua ação se todo o documento já tiver sido carregado.” (Silva, s.d).

48

A linguagem foi criada pela Netscape em parceria com a Sun Microsystems para dar interatividade às páginas web. A primeira versão foi lançada em 1995 e implementada em 1996 no navegador Netscape. Ao contrário de outras linguagens de programação, em que é necessário ter um servidor remoto configurado para suportar essas linguagens, em JavaScript, como citado, são necessários apenas que os navegadores de internet tenham em seu motor de navegação um interpretador capaz de executar os scripts desenvolvidos em JavaScript. O Nestacape foi percursor e, posteriormente, a Microsoft também desenvolveu um interpretador proprietário e assim, sucessivamente, os demais navegadores presentes no mercado. JavaScript é bastante seguro, pois não permite a leitura e escrita de arquivos no disco rígido do usuário, além trabalhar por meio de scripts organizando tipos de dados. Como o JavaScript escreve marcação HTML é possível controlar o comportamento do navegador em diversos aspectos. Com a definição de padrões web o desenvolvimento, a partir de conceitos em camadas, passou a ser implantado em JavaScript. A proposta é separar a estruturação de conteúdos constituídos pela marcação HTML, a camada de definição de estilo (CSS) e a camada de comportamento constituída pelos scripts que determinam o comportamento como scripts desenvolvidos em JavaScript. Para escrever JavaScript basta ter um editor de texto simples e visualizar o resultado em um navegador. Os scripts são criados para serem executados dentro de um arquivo HTML, ou seja, os scripts devem estar atrelados a esse padrão. A linguagem também suporta programação orientada a objetos. Atualmente, com o crescimento do uso da linguagem JavaScript, surgiram várias bibliotecas para dar agilidade ao desenvolvimentos de projetos nessa plataforma. Nesse projeto, uma das bibliotecas usadas é o LeaFletJS. LeaFletJS é uma biblioteca da comunidade livre bastante leve e intuitivo apresentando os mapas de forma rápida. Por ser leve, facilita a integração com dispositivos móveis. Possui diversas ferramentas que podem ser integradas à biblioteca por meio de plug-ins. Esses plug-ins são validados e testados pela comunidade que mantém a ferramenta, o que dá uma garantia em termos de segurança para as equipes de desenvolvimento que pretendem integrar algumas dessas em sua aplicação. Outro ponto positivo é que o código da API foi reduzido em alguns milhares de linhas de programação permitindo o ganho de performance.

49

Por fim, importa informar que foi desenvolvida em 2011 por Vladimir Agafonkin com a proposta de ser uma aplicação mais fácil de usar do que o OpenLayers, além de utilizar conceitos HTML5. Atualmente, várias aplicações utilizam dessa biblioteca em seus projetos de mapas, dentre eles o OpenStreetMap, Flickr, Foursquare, The Wall Street Journal , Washington Post. 3.6.3 - Hypertext Preprocessor - PHP O PHP, acrônimo para Hypertext Preprocessor, é uma linguagem script da comunidade de software livre utilizada para o desenvolvimento de aplicações web usado juntamente com HTML. O PHP necessita de um servidor para executar seus códigos, que, posteriormente, são respondidos para os clientes. Também precisa, ao contrário do JavaScript, de um servidor web para executar seus scripts. A linguagem é compatível com os principais sistemas operacionais como Windows e Linux, compatível com os principais bancos de dados como MySQL, Oracle, PostGreSQL, além dos principais servidores web como Apache e Microsoft Internet Information Server - IIS. O funcionamento do PHP é por meio da execução de scripts em um servidor web que altera a estrutura do HTML deixando a página web dinâmica. Para isso, em códigos HTML são incluídos scripts PHP, e esses determinarão como o HTML deverá ser manipulado. 3.7

- SERVIDORES WEB

3.7.1 - NGinx Nginx é um servidor web, proxy reverso e proxy de balanceador de carga. Foi criado em 2002 com o objetivo de suportar o tráfego intenso de um serviço web russo chamado Rambler, o qual recebia mais de 500 milhões de acesso por dia. Segundo o site W3Techs, o servidor Nginx está em terceiro lugar como o servidor mais utilizado perdendo apenas para o servidores Apache e IIS da Microsoft. A proposta do Nginx é ser rápido, leve e eficiente no consumo de recursos de plataforma de hardware, em que está instalado.

50

O Nginx trabalha com a arquitetura orientada a eventos; assim, ele possui um socket assíncrono que não distribui processos logo que recebe requisições. A ferramenta trabalha com o conceito de blocos hierárquicos, sendo que um processo para cada núcleo de processamento é suficiente para dar conta de milhares de conexões, permitindo o uso mais eficiente da CPU e memória. Esse servidor suporta os principais protocolos como HTTPS, FastCGI, SCGI. O Nginx para alguns especialistas em tecnologia da informação é comparado com o servidor web Apache, porém eles podem ser usados conjuntamente. Segundo estudos de testes com as duas ferramentas, o Nginx tem vantagem quanto ao consumo de memória e velocidade, porém a tecnologia é frágil quanto à documentação disponível e o sistema trabalha com acoplamento em módulos permitindo a outros desenvolvedores a construção de extensões para o servidor. Entretanto, neste aspecto, o Apache fornece uma facilidade maior: ele carrega seus módulos dinamicamente, mesmo os módulos de núcleo, bastando especificar no seu arquivo de configuração o módulo a ser carregado. 3.7.2 Tomcat Tomcat é um servidor web Java que suporta aplicações J2EE desenvolvido pela Apache Software Foundation. É um servidor de software livre referendado pela Sun Microsystems para a implementação Java Servlet e JavaServer Pages (JSP). Um servlet é uma classe escrita em Java, cujos objetos têm a finalidade de gerar documentos codificados em HTML. Uma página escrita em JSP é uma página escrita em HTML que contém pequenos fragmentos de códigos java e ou tags especiais. Essas tags permitem que os desenvolvedores não precisem escrever várias linhas de código Java. O servidor Tomcat consegue converter automaticamente qualquer página JSP em um servlet equivalente, ou seja, criar código java a partir de um documento HTML permitindo a criação de conteúdos de forma dinâmica.

51

4

- DESENVOLVIMENTO

No capítulo que corresponde ao Desenvolvimento, apresentamos a construção desse projeto, uma proposta de uma nova aplicação SIG Web, que permite consultas e análises espaciais de mapas temáticos para a elaboração de políticas públicas nas áreas de urbanismo, habitação e regularização fundiária. 4.1

- ARQUITETURA DO SITURB

O Sistema de Informações Territoriais e Urbanas do DF – Siturb é uma aplicação tecnológica baseada em um sistema de informação geográfica que contém toda a base cartográfica, os projetos arquitetônicos, urbanísticos, de infraestrutura do DF, o Zoneamento Ecológico e Econômico, os equipamentos públicos, legislação pertinentes às áreas de urbanismo, ambiental, base hidrográfica, geológica, base de arruamento dentre outros. Somente em 2009 foi possível dotar da tecnologia da informação para consolidar todos os dados ora citados em uma única base em banco de dados estruturado. Para estruturar essa coleção de dados em um repositório único, bem como estruturá-lo em um ambiente SIG de três camadas foram adotados a plataforma ESRI, sendo composta pelas ferramentas Desktop, servidor de Aplicação ArcGIS Server 10.0, a API Adobe Flex da ESRI suportado pelo banco de dados Oracle 9iR2. Essa aplicação foi adquirida com o objetivo de prover os técnicos da Secretaria de um ambiente em que fosse possível disponibilizar para consulta a base cartográfica e de projetos do DF de forma dinâmica e interativa, por isso a arquitetura para a aplicação foi composta, conforme figura a seguir.

52

Figura 4.1 - Arquitetura Siturb 2009

Ao longo dos anos, o Governo do Distrito Federal – GDF percebeu a importância de trabalhar com informações georeferenciadas para o auxílio à tomada de decisão. Assim, outros órgãos da estrutura do Governo passaram a necessitar dos dados do Siturb para o auxílio em seus projetos. Diante desse cenário, vislumbrou disponibilizar a aplicação para a nuvem privada do GDF com objetivo compartilhar as informações da aplicação com outros órgãos. Conforme citado, o Siturb foi concebido para atender apenas a Secretaria de Habitação, Regularização e Desenvolvimento Urbano – Sedhab. Ao disponbilizá-lo para outros órgãos, foi constatado um baixo desempenho no sistema, pois o hardware e o software foram dimensionados para uma quantidade reduzida de usuários. Assim, com objetivo de atender a uma demanda maior de acessos, foi proposta a concepção de uma nova plataforma mais moderna e com uma estrutura de hardware mais robusta. O primeiro passo foi a alocação da aplicação em um datacenter com redundância, sala segura, grupo gerador, e infraestrutura de servidores e storage, conforme a seguinte estrutura apresentada.

53

Figura 4.2 - Arquitetura Siturb

Como os técnicos têm um amplo conhecimento e habilidade com a plataforma ESRI, além dos investimentos realizados nos últimos anos em software proprietário, o legado não poderia ser descartado. Por outro lado, havia limitação de recursos orçamentários, por isso um ambiente híbrido foi estruturado, ou seja, uma aplicação suportada por software proprietário e plataforma livre. Como citado anteriormente na seção 2.4 – Arquitetura de SIG, as plataformas WebSIG apresentam tipicamente uma arquitetura cliente-servidor multi camadas, com a separação em termos lógicos dos processos de apresentação, o processamento e gestão de dados. Este tipo de arquitetura permite grande modularidade do sistema e contribui para melhorar a sua manutenção ao permitir que o desenvolvedor adicione, modifique ou remova componentes enquanto outros permanecem em funcionamento. Desta forma, a arquitetura do Siturb está baseada em três componentes principais: Cliente, Servidor e Dados. Os dados geográficos sejam eles rasters e matriciais são produzidos e atualizados pela Subsecretaria de Informações Urbanas, por meio de softwares da plataforma ArcGIS. Esses dados são obtidos por meio do amplo acervo cartográfico e de projetos urbanísticos e arquitetônicos, que estão sob a responsabilidade da Sedhab, além de imagens aéreas não 54

somente, mas principalmente obtidas junto a Agência de Desenvolvimento do Distrito Federal – Terracap. Essas bases são um dos principais subsídios para os técnicos, sendo complementados com os levantamentos topográficos realizados pela própria Secretaria e demais estudos e levantamentos realizados por outros órgãos de Governo que são compartilhados nos mais diversos formatos. Após as atividades de produção de dados, esses são validados por um técnico da Subsecretaria antes da carga para o Banco de Dados PostGreSQL. A conexão entre o software de produção e edição de mapas e o banco de dados relacional é feito por meio do aplicativo ArcSDE, que é uma coleção de ferramentas geográficas que vem nativo no servidor de aplicação ArcGIS Server, conforme citado no capítulo 3. O Banco Relacional não segue nenhum modelo de dados propostos pelas melhores práticas brasileiras, por isso o próprio ArcSDE cria a sua estrutura de tabelas no banco. Apesar de a plataforma ArcGIS possuir funções de controle de versionamento para a edição e manutenção de dados essa funcionalidade ainda não foi implantada na Secretaria, por isso a necessidade de exisitr um administrador de dados geográficos para validar a sua produção. Esse processo de edição, manutenção e exclusão de dados é realizado no ambiente de desenvolvimento, que é suportado pelo sistema operacional Windows 2008 R2. Nesse contexto, foi desenvolvida uma rotina, executada diariamente, de atualização dos dados do ambiente de desenvolvimento para produção. Por sua vez, o ambiente de produção conta com as ferramentas livres: SGBD PostGreSQL, o cartucho espacial PostGIS, o servidor de publicação de mapas GeoServer, as linguagens de programação JavaScript, PHP e a camada de apresentação do usuário suportada em HTML5 todo essa estrutura em Linux CentOS versão 6.0. O servidor de publicação de mapas GeoServer possui conexão nativa com o PostGis, permitindo o ganho de performance para as consultas espaciais. O GeoServer é componente do sistema responsável pela interligação entre a base de dados e o usuário. Ele é suportado pelo servidor Apache Tomcat, padrão para a instalação da ferramenta. O GeoServer, conforme figura 3.2 – Arquitetura Siturb, está instalado em uma máquina central e em mais três outros servidores escravos. Essa estrutura baseada em computação cluster conta com o Nginx, servidor de proxy de balanceamento de carga, cuja atribuição é receber as milhares de requisições clientes e distribuí-las de tal forma que a aplicação não perca em performance e escalabilidade. 55

Como o Siturb utiliza basemaps de imagens de alta resolução, esses dados exigem um grande consumo de memória e processamento. Além disso, a aplicação conta com mais de cem serviços de mapas temáticos e uma base de mais de quinhentos mil registros aramazenados no banco PostGreSQL. Toda essa estrutura precisa estar acessível em uma nuvem privada que conta com mais de cinquenta mil usuários. Para manter esse ambiente em pleno funcionamento, recursos da computação distribuída são fundamentais para esse projeto. Para acessar o sistema, foi desenvolvido um módulo de segurança de acesso em PHP. Esse módulo gerencia grupos de usuários e níveis de permissão com trilhas de auditoria. A interface gráfica do usuário foi desenvolvida em HTML5 com a biblioteca JavaScript específica de mapas chamadas LeaFlet. O LeaFlet, conforme citado na sessão 3.6.2 – JavaScript, permite que a camada de apresentação seja estável, escalável e suportada por dispositivos móveis como tablets e smartphones. Para o negócio da Sedhab, isso é importante, pois há equipes em campo colhendo dados, o que futuramente permitirá a edição e alimentação em tempo real da aplicação SIG. Essa API possui diversos recursos como medir áreas, identificar polígonos, exportar e importar diversos formatos de arquivos, conforme será apresentado ao longo desse projeto. Assim, ao cliente acessar o endereço da aplicação em seu browser, ele precisará realizar logon. Solicitando um pedido, esse será enviado pelo browser, utilizando JavaScript, que por sua vez transmitirá ao GeoServer. A API REST do GeoServer facilita a troca e o consumo de serviços de geoinformação, possibilitando a interoperabilidade dos dados geográficos. O REST é um conjunto de princípios que define como HTTP e URI’s devem ser usados. As aplicações web são, geralmente, baseadas em HTTP e XML, e as outras partes em JavaScript Object Notation – JSON. Para o usuário, ao digitar um endereço no browser para visualizar uma página na internet, é apresentado o protocolo HTTP, responsável por processar o pedido e o envio, e a informação solicitada de volta ao browser que, por sua vez, faz a formatação e mostra o conteúdo ao utilizador, tornando assim o servidor HTTP como uma das peças fundamentais para se montar um servidor de página para Internet. O usuário faz uma requisição de um serviço ao GeoServer executando a função GET. O Geoserver requisita ao PostGIS os dados espaciais e alfanuméricos.

56

O GeoServer retorna ao cliente uma requisição GETMAP baseada no padrão WMS, conforme exemplo abaixo:

Tabela 4.1 - Requisição GETMAP http://IP:Porta/geoserver/sedhab/wms?service= Versão:WMS&version=1.1.0 Requisição=GetMap& Layers=sedhab:CATALOGO_FOTO_AEREA_20091& Styles=& bbox=144675.0,8218985.5,259336.0,8289560.5& width=536&height=330&srs= EPSG:31983& format=application/openlayers

Essa função retorna um mapa com o dimensionamento e informação geográfica definidos, por meio dos parâmetros especificados quando da sua invocação. No exemplo acima, apresenta-se o caminho do servidor de mapas que armazena os serviços WMS, nesse caso, o Geoserver; os parâmetros das camadas que deverão ser representadas no mapa requisitado (Layers); os estilos que deverão ser representados no mapa requisitado (style); as coordenadas que indicam como estão codificados os pontos no mapa, indicando a projeção e a caixa delimitadora a ser utilizada no pedido do mapa (BBOX); parâmetros de altura e comprimento do mapa a ser produzido em termos de número de pixels (widht e height) e, por fim, o formato do mapa devolvido na solicitação (format). 4.2

- REQUISITOS DO SISTEMAS DE INFORMAÇÕES TERRITORIAIS E URBANAS DO DF - SITURB

Conforme citado na seção 2.1 – Engenharia de Software, o modelo clássico do ciclo de vida de sistemas chamado cascata necessita grandes esforços nas análises dos requisitos do sistema. Em SIG, essa tarefa é mais importante ainda, visto que é preciso selecionar quais dados, efetivamente, serão disponibilizados aos usuários, considerando sempre o foco no negócio. A engenharia de sistemas, segundo a definição de Pressman (2011), é o campo em que são definidos os requisitos do sistema. 57

Para o projeto Siturb, especificamente, os requisitos foram definidos ainda na primeira versão de 2009. Sendo assim, a proposta para a nova aplicação foi manter as funcionalidades existentes na versão anterior, acrescendo, a princípio, apenas de mais algumas funcionalidades. Seguem os requisitos funcionais da aplicação: 1. Exibir Maptips: permitir que o usuário possa recuperar as informações do Mapa apenas com o deslocamento do cursor sobre a feição da camada ativa; 2. Associar registros de tabelas diversas a feições: possibilitar a atualização de endereços em tabelas descritivas existentes no Geodatabase; 3. Gerenciar Camadas: Possibilitar ao usuário gerenciar as Camadas visualizadas, conforme o Mapa temático selecionado; 4. Manter Conteúdo de Apresentação: gerenciar os conteúdos referentes ao Siturb e Sicad que serão apresentados na interface inicial do sistema; 5. Exibir Informações de Rede Geodésica: exibir informações sobre a rede geodésica; 6. Inserir Comentário no Mapa: inserir comentários textuais e temporários no Mapa; 7. Visualizar Metadado: exibição dos metadados no padrão ISO-19139 para a camada selecionada pelo usuário; 8. Alterar Configurações da Camada: permitir que o usuário possa alterar as cores das camadas para eventuais analises nos dados. 9. Calcular medida no mapa: permite ao usuário obter medidas de distância e área através de desenho de linhas e polígonos no mapa; 10. Exportar Imagem do Mapa: permitir que o usuário possa extrair informações para disponibilização como amostragem para outros usuários ou sistemas; 11. Recuperar informações do Mapa: possibilitar ao usuário a consulta de informações com um clique sobre uma ou mais feições no mapa; 12. Exportar dados tabulares das Feições: permitir que o usuário possa extrair para sua máquina local, atributos das feições apresentadas no Mapa; 13. Selecionar Elementos no Mapa: permitir que o usuário possa selecionar feições no mapa; 14. Realizar Busca de Atributos: localizar atributos das feições sem a necessidade de elaboração de critérios avançados de pesquisa; 15. Realizar Busca por Distância: permite ao usuário a localização de feições com base numa distância informada pelo usuário; 58

16. Realizar Busca por Critérios: possibilitar que o usuário defina critérios para a localização de feições no mapa; 17. Adicionar Dados Locais: possibilitar que o usuário possa adicionar dados locais para eventuais análises; 18. Gerar Impressão de Mapas Temáticos: possibilitar a geração de mapas temáticos para templates definidos pela Sedhab; 19. Alterar Sistema de Coordenadas do Mapa: permitir que o usuário possa alterar o sistema de coordenadas sem a necessidade de reprojeção dos dados; 20. Extrair Dados do mapa: permitir que o usuário possa extrair para sua máquina local, feições para eventuais análises; 21. Limpar Seleção: permitir ao usuário limpar os elementos selecionados no mapa; 22. Gerenciar Zoom: permite ao usuário executar navegações do tipo aproximação no mapa através do clique no mapa e/ou do controle de rolagem do mouse (scroll button); 23. Exibir visão geral (Overview): permite ao usuário ativar/desativar a visualização geral do mapa; 24. Exibir resultados: permiti ao usuário visualizar os resultados de uma consulta e/ou seleção de feição no mapa; 25. As novas funcionalidades propostas foram: 26. Manter perfil: permitir ao usuário o cadastro e manutenção dos perfis do sistema; 27. Manter associação mapa perfil: permitir ao usuário o cadastro e a manutenção de associação entre mapas temáticos e perfis; 28. Efetuar login: identificar e autenticar o usuário verificando seus acessos e permissões; 29. Criar usuário: possibilitar a criação dos usuários do sistema, assim como as definições de perfis de acesso; 30. Manter usuário possibilitar a administração dos usuários do sistema, assim como as definições de perfis de acesso; 31. Excluir usuário: possibilitar a administração dos usuários do sistema a exclusão de usuários; 32. Efetuar Logout: encerrar as sessões utilizadas pelo usuário no sistema; 59

33. Editar o mapa: permite que o usuário edite dados on-line no mapa; 34. Disponibilizar serviços WMS: permite que o usuário disponibilize arquivos no padrão wms para que seja possível consumir dados em outras aplicações. 35. Disponibilizar serviços WCS, KML, WMST, WFS: permite que o usuário disponibilize arquivos nos principais protocolos do padrão OGC para que seja possível consumir dados em outras aplicações. Apresentam-se, a seguir, os requisitos não funcionais da aplicação: 1. Segurança: Senha de entrada de dados são mascarados; As senhas utilizam equivalentes ou superiores a SHA-256; O sistema possui validação de usuário, resguardando dados importantes para regras específicas de visualização. 2. Desempenho: O tempo de resposta das consultas não devem ultrapassar 4 segundos; criação de views no banco postgre para aumento de desempenho de consultas. 3. Interoperabilidade: O sistema se comunicará com o banco de dados Postgre; 4. Usabilidade: O sistema possui facil navegação, utilizando padrões de UX Design; O sistema é responsivo, ou seja, se adapta as resoluções mais comuns do mercado, como smartphones, tables e desktops. 5. Portabilidade: O sistema é web e está disponível para todos os navegadores existentes no mercado atual. 6. Confiabilidade: O sistema possui backup de banco de dados diários, todas as triggers estão dentro da aplicação, não importanto assim o banco de dados que estará servindo o sistema. 7. Padrão: O sistema utiliza arquitetura MVC, utilizando o paradigma de orientação a objetos. 8. Implementação: O sistema utiliza PHP, Javascript. 4.3

PROTÓTIPO

SISTEMAS

DE

INFORMAÇÕES

TERRITORIAIS

E

URBANAS DO DF - SITURB O Siturb conta com a funcionalidade de controle e nível de acesso. Essa funcionalidade tem como objetivo controlar os níveis de acesso e o que cada usuário pode visualizar de acordo com a área de negócio de cada órgão. O cadastro dos usuários é

60

realizado pela Sedhab, que, além disso, gerencia as permissões de acesso por meio da criação de grupos de usuários. Alguns atributos e mapas temáticos são estratégicos para uma determinada Secretaria, enquanto outros não são de interesse para outros órgãos. O perfil administrador é o responsável por fazer a gestão dos usuários e de grupo de usuários. . Além disso, o sistema mantém em um banco de dados todos os logs de acesso e quais as ações que os usuários realizaram no sistema. Nas figuras abaixo, são apresentadas as telas do módulo de segurança da ferramenta.

Figura 4.3 – Tela de login

61

Figura 4.4 – Usuários cadastrados no sistema

Figura 4.5 – Criando usuário

62

Figura 4.6 – Editando usuário

Figura 4.7 – Grupo de usuários

63

Figura 4.8 – Criando um grupo de usuários

O sistema permite a visualização, exportação e importação de mapas para as coordenadas Sirgas 2000 e Chuá. Por ser suportado pelo servidor de publicação de mapas, é possível selecionar e exportar mapas em diversos formatos de arquivos como Shapefile, PNG, JPG e outros, conforme demonstrado na Figura abaixo.

Figura 4.9 – Exportação de um mapa em formatos SHP, JPG e PNG 64

A aplicação contempla ferramentas como geração de áreas de proximidade para facilitar as análises espaciais. Esta função permite gerar polígonos no entorno de um elemento a partir de uma distância definida pelo usuário ou de atributos que estão vinculados ao elemento.

Figura 4.10 – Geração de áreas de proximidade Na figura abaixo, é apresentada a ferramenta de medir áreas, exibe as coordenadas de um ponto selecionado, além de trazer os dados alfanuméricos do ponto selecionado.

Figura 4.11 – Medição de área 65

Permite que o usuário crie uma consulta, a partir dos dados alfanuméricos, vetores e rasters de todos os serviços, que contempla o sistema e exibe ao usuário uma tabela com os dados e as feições na tela.

Figura 4.12 - Consulta de dados alfanuméricos

O Sistema permite que o usuário gerencie camadas, conforme o mapa temático selecionado, altere a ordem e a visibilidade das camadas, com o objetivo de realizar consultas espaciais. O usuário pode ainda salvar os mapas mais acessados por meio da ferramenta favoritos.

66

Figura 4.13 - Gerenciamento de camadas

O sistema permite geocodificar pontos em um mapa a partir da coleta em campo ou por meio da exportação desses dados.

Figura 4.14 - Visualização de geocodificação

A proposta de reestruturação do Sistema de Informações Informações Territoriais e Urbanas do DF, ora apresentado visa permitir ganho de performance e a ampliação da ferramenta a outros órgãos como fonte de melhoria em seus processos de negócio.

67

5

5.1

- CONCLUSÕES E RECOMENDAÇÕES

- CONCLUSÕES GERAIS

Os Sistemas de Informações Geográficas têm sido empregados nas mais diversas áreas para solucionar problemas de negócio. Trata-se de uma área promissora a ser explorada por meio de pesquisas, bem como novos estudos com a integração de novos conceitos na área da computação, dentre elas a computação em nuvem e o bigdata. A metodologia utilizada neste trabalho e a pesquisa bibliográfica realizada foram relevantes e imprescindíveis ao desenvolvimento final deste trabalho e do modelo proposto. A proposta discutida neste trabalho de desenvolver uma nova aplicação para o monitoramento do planejamento e o uso da ocupação do solo suportada por um Sistema de Informação Geográfica – SIG permitirá que os órgãos do Governo do Distrito Federal planejem as ações de urbanismo e regularização fundiária para a sociedade de uma maneira mais justa. 5.2

SUGESTÕES PARA TRABALHOS FUTUROS

Para o progresso desse trabalho, sugerem-se alguns pontos, os quais seguem expostos. A implantação da aplicação no ambiente de produção do datacenter não foi feito. Assim, não foi possível testar em um ambiente real a disponibilidade, integridade e a segurança da solução. A operação do sistema em produção permitirá a avaliação e adequação da aplicação, bem como o real impacto na rede de dados e o desempenho do hardware alocado para esse trabalho. Outro ponto que necessita de evolução nesse trabalho é a ampliação a arquitetura do Sistema com a disponibilização de um ambiente de redundância para o nó central onde está hospedado o GeoServer. Essa ação garantiria o alto desempenho da aplicação no caso de falha no servidor que está instalado o balanceador de carga.

68

REFERÊNCIAS AKTAS, M. S, et al. Information Services for Grid/Web Service Oriented Architecture (SOA) Based Geospatial Applications. Community Grids Lab. Indiana, s.d.

ALMEIDA, C; Câmara, G; Monteiro, A.M.V. Geoinformação em Urbanismo: cidade real x cidade virtual. In: ______. 1.ed. São Paulo: Ed. Oficina de Textos, 2013.

ALVES, P.B. Desenvolvimento de uma Plataforma Baseada em Serviços para Suporte à Simulação de Tráfego. 2013. 75 f. Tese (Mestrado Engenharia Informática e Computação) – Faculdade de Engenharia, Universidade do Porto, Porto, 2013.

BACELLAR, H.V. Instituto de Computação. Cluster: Computação de Alto Desempenho. Disponível em: http://www.ic.unicamp.br/~ducatte/mo401/1s2010/T2/107077-t2.pdf. Acesso em: jan.2014.

BASS, B. NoSQL Spatial: Neo4j versusPostGIS. 2012. 67f. Tese (Mestrado Geographical Information

Management and Applications). Delt University of Technology,

Holanda, 2012.

BORGES, K.A.V. Universidade Federal de Minas Gerais. Modelagem de Dados Geográficos.

Disponível

em:

http://www.csr.ufmg.br/geoprocessamento/publicacoes/Modelagem%20de%20dados %20geografico.PDF. Acesso em: fev. 2014.

BORGES, K.A.V; Junior, C.A.D; Laender, A.H.F. Modelagem Conceitual de Dados Geográficos. In: CAMARA, Gilberto et al. Banco de Dados Geográficos. Ed. MundoGEO, 2005. p. 83-135.

BORGONY, V; VINHAS, L. Proceedings of The XI Brazilian Symposium on Geoinformatics. In: SIMPÓSIO BRASILEIRO DE GEOINFORMÁTICA. n. XI, 2010, Campos do Jordão. Anais 11º Simpósio Brasileiro De Geoinformática. São José dos Campos: INPE, 2010.p. 206. 69

CÂMARA, G; Davis.C. et al. Introdução ao Geoprocessamento. In: ______. Introdução à Ciência da Geoinformação . Ed. INPE, 2001. p. 1-5.

CHENG, E.C. Modelagem de Dados Geográficos e Aplicação de Indicadores para a Gestão dos Recursos Hídricos – Estudo de Caso da Bacia do Lago Paranoá – DF. 2012. 90f. Dissertação ( Mestrado em Geociências Aplicadas) – Instituto de Geociências. Universidade de Brasília, Brasília, 2012.

COSTA, F.S. Sopa de Letras Geográfica. In: REVISTA FOSSGIS BRASIL, 2011, São Paulo. Revista FossGis Brasil, São Paulo, v.1, n. 1, p. 13-18, mar., 2011.

CRUZ, I.; Campos, V.B.G. Instituto Militar de Engenharia. Sistemas de Informações Geográficas Aplicados à Análise Espacial em Transportes, Meio Ambiente e Ocupação

do

Solo.

Disponível

http://aquarius.ime.eb.br/~webde2/prof/vania/pubs/(15)SIG-AE2.pdf.

em Acesso

em:

fev. 2014.

DEGGAU, R. Biblioteca Digital Brasileira de Computação. Enriquecendo Data Warehouses

Espaciais

com

Descrições

Semânticas.

Disponível

em

http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/Trabalho?id=7794 . Acesso em: fev. 2014.

FARIA, N.A.S. Suporte à Edição Cooperativa de Informação Geográfica em ambiente Web. 2006. 99f. Dissertação (Mestrado em Informática) – Escola de Engenharia. Universidade do Minho, Braga, 2006.

FERRÃO, L.M. S; Plotze, R. O. Computação Distribuída: o melhor aproveitamento de recursos computacionais. In: LINGUAGEM ACADÊMICA. n. I, 2012, Batatais. Linguagem Acadêmica, v.2, n.1, p. 93-119 jan/jun, 2012.

FERREIRA, K.R; Casanova, M.A et al. Arquitetura e Linguagens. In: CAMARA, Gilberto et al. Banco de Dados Geográficos. Ed. MundoGEO, 2005. p. 170-201.

70

FERREIRA, K.R. Interface para Operações Espaciais em Banco de Dados Geográficos. 2003. 83f. Dissertação ( Mestrado em Computação Aplicada) – Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 2003.

FERREIRA, S.F.T. Plataforma Web para Disponibilização de Serviços Geoespaciais. 2012. 70f. Tese (Mestrado Engenharia Informática e Computação). Universidade do Porto, Porto, 2012.

FILHO, J.L; Iochpe, C, et al. Universidade Federal do Rio Grande do Sul. Modelagem Conceitual de Bancos de Dados Geográficos: o estudo de caso do Projeto PADCT/CIAMB.

Disponível

em

http://www.ecologia.ufrgs.br/paginas.centro/idrisi/artigos/ . Acesso em: fev. 2014.

GeoServer in Production. OpenGeo Org., 2013.

GASKILL,

J.

ESRI.

Understanding

ArcSDE.

Disponível

em:

http://downloads.esri.com/support/documentation/other_/uc2000/415.pdf.

GIL, A. C. Métodos e Técnicas de Pesquisa Social. São Paulo, Atlas, 1999.

GORINO, F. V. R. Balanceamento de Carga em Clusters de Alto Desempenho: Uma Extensão para a LAM/MPI. 2006. 91f. Tese (Mestrado Ciência da Computação). Universidade Estadual de Maringá, Maringá, 2006.

GRANEMANN, T. E.D. Infraestruturas de Dados Geoespaciais: Um estudo comparativo entre aplicações desenvolvidas em Java e PHP. 2009. 103f. Trabalho de Conclusão de Curso (Graduação Ciência da Computação). Centro de Ciência Tecnológica da Terra e do Mar. Universidade Vale do Itajaí, Itajaí, 2009.

GUEDES, S.Z. Implantação de uma Infraestrutura de Dados Espaciais com Base em Tecnologias Open Source para Riscos Costeiros. 2010. 95f. Dissertação (Mestrado Ciência e Tecnologia Ambiental). Universidade do Vale do Itajaí, Itajaí, 2010. HAILING, L; Yunfeng, N. Til. IEEEXplore Digital Library. Tile-Based Map Service GeoWebCache

middleware.

Disponível 71

em:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5658509&url=http%3A%2F %2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5658509.

HAMIL, D.L. Your Mission, Should You Choose To Accept It: Project Management Excellence. In: Australian Local Government Association. Local Government Spatial Information Management. Ed. ANZLIC, 2007. p. 153-172.

HASENACK, H; Weber, E. Universidade Federal do Rio Grande do Sul. Derivação de Novas Informações Cadastrais para o Planejamento Urbano através de Sistema de Informação

Geográfica.

Disponível

em

http://www.ecologia.ufrgs.br/paginas.centro/idrisi/artigos/ . Acesso em: fev. 2014.

JÚNIOR, C.A.D. Múltiplas Representações em Sistemas de Informação Geográficos. 2000. 91f. Tese (Doutorado Ciência da Computação). Universidade Federal de Minas Gerais, Belo Horizonte, 2000.

JÚNIOR, C.A.D; Borges, K.A.V et al. O Open Geospatial Consortium. In: CAMARA, Gilberto et al. Banco de Dados Geográficos. Ed. MundoGEO, 2005. p. 367-383.

JÚNIOR, J.B.M; Candeias, A.L.B. SIG e sua interoperabilidade utilizando servidores de WEB. In: Anais XIII Simpósio Brasileiro de Sensoriamento Remoto, n.XIII, 2005, Goiânia. INPE, 2005. p. 2273-2280.

KÖSTERS, G; Pagel, B.U; Six, H.W. Universidade de Hagen. Object-Oriented Requirements

Engineering

for

GIS-Applications.

Disponível

em:

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=34CB7FD8BF408BDDE01 DD72381088498?doi=10.1.1.9.3626&rep=rep1&type=pdf. Acesso em: jan. 2014.

LADWIG, N.I. O sistema de Informação Geográfica para o Planejamento e a Gestão Sustentável do Turismo. In: REVISTA GESTÃO SUSTENTÁVEL AMBIENTAL, 2012, Florianópolis. Revista Gestão Sustentável Ambiental, Florianópolis, v.1, n. 1, p. 19-32, 2012.

LONGLEY, P.A; Goodchild, M.F et al. Geographical Information Systems and Science. 72

2.ed. Chichester: John Wiley & Sons, 2005. MARTINS, R. B. Metodologia Científica – Como tornar mais agradável à elaboração de trabalhos acadêmicos. Curitiba: Juruá Editora, 2011. 1th Edição.

MOMO, M.R; Refosco, J.C. Arquitetura Computacional baseada em computação GRID, aplicada a sistemas de informação geográfica na gestão de risco e alerta da bacia do rio Itajaí. In: SIMPÓSIO BRASILEIRO DE SENSORIAMENTO REMOTO. n. XV, 2011, Curitiba. Anais XV Simpósio Brasileiro De Sensoriamento Remoto. Curitiba: INPE, 2011.p. 8865.

OBE, R.O; Hsu, L.S. PostGIS in Action. 1ed. Stamford: Manning, 2011.

OGLIARI, T.C. Brasília e os Desafios de uma nova Realidade Urbana. In: Leitão, Francisco. Brasília 1960 2010: passado, presente e futuro. Ed. SEDUMA, 2009. P 201-205.

OLIVEIRA, H.V. Uma Arquitetura de Integração de Dados Espaciais: um Estudo dos Dados de Solos e Folhas dos Biomas Brasileiros. 2013. 92f. Tese (Mestrado Ciência da Computação). Universidade de Brasília, Brasília, 2013.

OLIVEIRA, P.A.; Oliveira, M.P. Uso de um Sistema de Informação Geográfica em Cadastro Técnico Municipal: a experiência de Belo Horizonte. In: INFORMÁTICA PÚBLICA, 2005, Belo Horizonte. Revista IP – Informática Pública, Belo Horizonte, v.7, p. 67-84, 2005.

PASCUAL, M. Xgis Flex: Um Framework Livre Para O Desenvolvimento De Sistemas De Informações Geográficas para a Web. 2013. 63f. Dissertação (Mestrado Geociências Aplicadas) – Instituto de Geociências, Universidade de Brasília, Brasília, 2013.

PENNA, R.A.C. O Papel da TI Na Estratégia Competitiva: Um Estudo Sobre Data Warehouses Espaciais, Integrando Sistemas De Informação Geográfica (GIS) À Inteligência Do Negócio. 2004. 1281f. Tese (Mestrado Ciências em Engenharia de 73

Produção) – Engenharia de Produção. Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2004.

PRESSMAN, R.S. Engenharia de Software. 7ed. São Paulo: AMGH Editora, 2011.

QUEIROZ, G.R; Monteiro, A.M.V; Câmara, G. Banco de Dados Geográficos e Sistemas NoSQL: Onde Estamos e para Onde Vamos. In: REVISTA BRASILEIRA DE CARTOGRAFIA, 2013, São Paulo. Revista Brasileira de Cartografia, São Paulo, v.1, n. 65, p. 479-492, 2013. RICHARDSON, L; Ruby S. RESTful Web Services. 1. Ed. California: O’Reilly, 2007. RITA, E.J.F. Criação de Mapas Temáticos através de Extensões às Normas do “Open Geospatial Consortium”. 2010. 73f. Dissertação (Mestrado Engenharia Informática e de Computadores) – Instituto Superior Técnico. Universidade Técnica de Lisboa, Lisboa, 2010.

SAMPAIO, V.B. Adaptação do Pefil de Metadados Geoespaciais do Brasil para a Administração Pública Municipal. 2011. 107f. Monografia (Especialização Geoprocessamento) – Instituto de Geociências, Universidade Federal de Minas Gerais, Belo Horizonte, 2011.

SANTANA, F.C. Fundamentos de SOA e Web Services. Relatório Técnico. 2009. Escola Politécnica. Universidade de São Paulo, São Paulo.

SCHEPKE, Claudio, et al. Panorama de ferramentas para gerenciamento de clusters. Porto Alegre: III Workshop de Processamento Paralelo e Distribuído, 2005.

SILVA, A.N.R. Sistemas de Informações Geográficas para Planejamento de Transportes. 1998. 112f. Texto (Obtenção Título Livre-Docente) – Departamento de Transportes. Universidade de São Paulo, São Carlos, 1998. SILVA, F. M. SOA – Arquitetura Orientada a Serviços. 2006. 38f. Trabalho de Conclusão de Curso (Graduação Ciência da Computação) - Instituto de Matemática e 74

Estatística, Universidade de São Paulo, São Paulo, 2006. SILVA, J.T.C. SIGHabitar – Uma Abordagem baseada em Inteligência de Negócios para o desenvolvimento de Sistemasde Informação Territorial: O Cadastro Técnico Multifinalitário do Município de Ouro Preto, MG. 2012. 68f. Dissertação ( Mestrado Ciência da Computação) – Instituto de Ciências Exatas e Biológicas. Universidade Federal de Ouro Preto, Ouro Preto, 2012.

SILVA, M.S. JavaScript Guia do Programador. In: ______. 1ed. São Paulo: Ed. Novatec, 2010.

SOMMERVILLE, I. Engenharia de Software. 9ed. São Paulo: Pearson Education, 2011.

STORCK, M.A. Desenvolvimento de Sistemas de Informação Geográfica sob a Ótica de Qualidade de Software. 2006. 67f. Dissertação (Mestrado Geomática) – Centro de Ciências Rurais. Universidade Federal de Santa Maria, Santa Maria, 2006.

TEOTÔNIO, F.A.B. Comparação do Desempenho dos Índices R-Tree, Grades Fixas e Curvas de Hilbert para Consultas Espaciais em Bancos de Dados Geográficos. 2008. 73f. Dissertação (Mestrado Computação Aplicada) – Computação Aplicada, Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 2008.

THOMÉ, R. Geoprocessamento. In: CAMARA, Gilberto et al. Geoprocessamento: Teoria e Aplicações. Ed. INPE, 2001. p. 33-54.

VALENTE, C. Engenharia de Software - Apostila. ESAB, 2007. VALENTE, C. Tópicos Avançados de Engenharia de Software – Apostila, ESAB, 2007.

VERGARA, S. C. Projetos e Relatórios de Pesquisa em Administração. São Paulo: Editora Atlas, 2010. 12th Edição.

VIEIRA, A.S. Orientações Para Implantação de um SIG Municipal Considerando Aplicações na Área de Segurança Pública. 2002. 48f. Monografia (Especialização 75

Geoprocessamento) – Departamento de Cartografia, Universidade Federal de Minas Gerais, Belo Horizonte, 2002.

VINHAS, L. Bancos de Dados Geográficos 2013. Espaciais.

Instituto Nacional de Pesquisas

Disponível

em:

http://wiki.dpi.inpe.br/doku.php?id=cap349#sites_interessantes.

ZENTENO A.H.T; Martins, E. et al. Instituto de Computação. Teste de Desempenho em Aplicações

SIG

Web.

Disponível

em:

http://www.lis.ic.unicamp.br/publications/journal-and-conferencepapers/performance-tests-in-web-gis-applications-in-portuguese/. Acesso em: jan. 2014.

76