Gestão de Equipamentos e Mobiliário Urbano€¦ · FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Gestão de Equipamentose Mobiliário Urbano

Helder Marco Barata Nunes

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Rosaldo Fernandes Rossetti (PhD)

Co-orientador: António Fernando Coelho (PhD)

29 de Julho de 2010

Gestão de Equipamentose Mobiliário Urbano


Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo júri:

Presidente: Ana Paula Rocha (PhD)

Vogal Externo: Jorge Gustavo Rocha (PhD)

Orientador: Rosaldo Fernandes Rossetti (PhD)

31 de Julho de 2010

Resumo

Os Sistemas de Informação Geográfica (GIS) são conhecidos pela capacidade de tra-zer eficiência na gestão e manipulação de entidades geo-referenciadas. Por esta razão, agestão de equipamentos urbanos deve tomar partido deste tipo de tecnologia a fim de agi-lizar o fluxo de negócio associado à tarefa de gestão. Esse fluxo de negócio deve integrartodas as áreas de gestão identificadas, fornecendo as ferramentas e informações necessá-rias para desempenhar as respectivas funções. Como alguns destes utilizadores exercemas suas funções no espaço geográfico, devem ser utilizados dispositivos móveis providosde GPS para desenvolver uma tarefa gestão eficiente.A visualização de um grande conjunto de dados sobre um mapa Web pode levantar pro-blemas de usabilidade se não existirem certos cuidados na apresentação da informação.Para resolver este problema, foi realizado um estudo que incidiu na visualização de in-formação sobre mapas Web para providenciar uma utilização mais agradável e facilitar apesquisa espacial.As entidades municipais são responsáveis pela gestão e manutenção dos equipamentosdentro da área que governam, por exemplo, iluminação, bancos, sinalética entre outros.Esta tarefa pode tornar-se propensa a erros e muito complexa se não estiverem disponí-veis ferramentas adequadas. A gestão de equipamentos exige uma solução integrada queinclui resposta em emergências e reacções de contingência, favorecendo a interacção comos cidadãos. Deve então ser desenvolvido um sistema integrado capaz de fornecer umaabordagem dinâmica para a gestão de todas as possíveis entradas e saídas de informaçãopara garantir um processo eficiente.Neste trabalho foi desenvolvido um conceito funcional e aplicável à gestão de equipa-mentos, integrando todos os recursos humanos envolvidos. A ferramenta fornece meiospara receber inputs de uma variedade de fontes, permitindo que estas sejam utilizadaspara criar reacções de resposta adequadas.Para atingir os objectivos foi seguida uma abordagem metodológica, que incluiu um pe-ríodo de pesquisa e experimentação, na qual ferramentas GIS, visualização de informaçãoe utilização de software GIS em gestão urbana foram alguns dos assuntos avaliados. Autilização de bases de dados espaciais foi explorada para providenciar o conhecimentonecessário para interrogações espaciais em dados georreferenciados. Foi criada uma pla-taforma de testes, consistindo numa ferramenta de visualização GIS e dados originais daCMP.As funcionalidades essenciais foram desenvolvidas, e estas permitem aumentar a produ-tividade geral do modelo de gestão de equipamentos actual da CMP. Para além disto osoperadores de visualização desenvolvidos permitem aumentar a usabilidade das aplica-ções baseadas em mapas Web.

i

Abstract

Geographical Information Systems (GIS) are known for its ability to bring efficiencywhen it takes to the management and manipulation of geo-referenced entities. Therefore,equipment management must make use of this kind of technology in order to streamlinethe business workflow associated with such a managing task. This workflow must inte-grate all the identified management areas, providing the tools and information needed toundertake their assignments. As some of these workers carry out their duties on the geo-graphical space, GPS-enabled mobile devices must be used to build efficient managementsoftware modules.The visualization of a large set of items on a Web map will bring usability issues if noinformation pre-processing is considered. Thus an information visualization study overWeb maps is taken into consideration to provide a more user friendly experience to thespatial search function. Bearing in mind this context, City Councils are responsible forthe management and maintenance of urban equipments within the area they govern, e.g.lighting, benches, bins, traffic signs and security elements such as road rail-guards. De-pending on how large the area governed is, types vary greatly and the number of itemscan be extremely large therefore. This task may become error-prone and very complexif no adequate tools are provided. Indeed, managing urban equipments demands an in-tegrated solution that includes maintenance, emergency and contingency actions, as wellas allows for the effective e-Governance especially favouring an explicit interaction withcitizens. An integrated system providing an dynamic approach for the management of allthe possible inputs and outputs must be developed to ensure an efficient process model tothe public organization.A functional and applicable equipment management concept, integrating all the humanresources involved with this management is required. The tool must provide a way toreceive inputs for a variety of sources, enabling those to be processed by creating mana-gement reactions.A methodological approach was followed, including a research and experimentation pe-riod in which, GIS associated tools, information visualization and the use of GIS softwarein urban management were some of the included topics. The use of a spatial database wasexplored to provide the knowledge of spatial querying on geo-referenced data. A test plat-form, consisting on a GIS visualization tool and original spatial data of the City Councilof the City of Porto, was set.Essential functionalities were developed which together can improve greatly the mana-gement workflow overall performance. Besides the information visualization processingallows for a more usable Web map interface.

iii

Agradecimentos

Saio deste curso com sentimento de objectivo cumprido. Agradeço a todos aquelesque me ajudaram nos momentos complicados em especial a ti, Carla. Não tinha chegadoaté aqui sem o teu apoio e força de vontade.A todos os aqueles professores que souberam transmitir o seu conhecimento para que eupudesse aprender e crescer (ainda mais :P). Um agradecimento muito especial ao meu ori-entador Prof. Rosaldo Rossetti e co-orientador Prof. António Coelho, mestres que muitoestimo, pelo seu tempo dedicado nesta minha etapa final.Esta dissertação teve outras contribuições que não posso deixar serem esquecidas, especi-almente provenientes de amigos e colegas do INESC-Porto, Leonel Dias, João Rodrigues,José Lino e Lígia Silva.Aos amigos da FEUP e fora da FEUP, que contribuíram com conforto e companhia du-rante estes 5 anos de curso.A todos os outros que também se preocuparam.

Obrigado a todos


v

Conteúdo

1 Introdução 11.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Organização do documento . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Revisão bibliográfica 52.1 Sistemas de informação geográficos . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Standards para a Implementação de GIS . . . . . . . . . . . . . . 7

2.2 GIS e Gestão Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Abordagens GIS em aplicações de gestão urbana . . . . . . . . . 92.2.2 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Visualização de informação em mapas Web . . . . . . . . . . . . . . . . 112.3.1 Problemas na visualização de informação em mapas Web . . . . . 132.3.2 Métodos anti-congestionamento . . . . . . . . . . . . . . . . . . 142.3.3 Estratégias para generalização . . . . . . . . . . . . . . . . . . . 19

2.4 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Solução para gestão de equipamentos urbanos 233.1 Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Fiscal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Departamento de gestão . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Departamento de execução . . . . . . . . . . . . . . . . . . . . . 253.2.4 Administrador do sistema . . . . . . . . . . . . . . . . . . . . . 253.2.5 Público . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . 263.3.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . 27

3.4 Processo de gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6 Módulos da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii

CONTEÚDO

3.6.2 Administração do sistema . . . . . . . . . . . . . . . . . . . . . 333.6.3 Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.4 Gestão de equipamentos . . . . . . . . . . . . . . . . . . . . . . 343.6.5 Gestão de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.6 Mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.7 Visualização estatística . . . . . . . . . . . . . . . . . . . . . . . 35

3.7 Modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Implementação e análise 394.1 Processo de gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Entidades e documentos . . . . . . . . . . . . . . . . . . . . . . 404.1.2 Gestão de utilizadores . . . . . . . . . . . . . . . . . . . . . . . 424.1.3 Gestão de cadastros de equipamentos . . . . . . . . . . . . . . . 434.1.4 Participação pública . . . . . . . . . . . . . . . . . . . . . . . . 444.1.5 Análise e possíveis melhorias . . . . . . . . . . . . . . . . . . . 46

4.2 Visualização sobre o mapa . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.1 Server-side vs Client-side clustering . . . . . . . . . . . . . . . . 464.2.2 Minimização da quantidade de informação transferida . . . . . . 474.2.3 Comunicação cliente-servidor . . . . . . . . . . . . . . . . . . . 494.2.4 Fase de selecção e criação de clusters . . . . . . . . . . . . . . . 504.2.5 Fase de tratamento da informação . . . . . . . . . . . . . . . . . 524.2.6 Processamento no cliente . . . . . . . . . . . . . . . . . . . . . . 534.2.7 Integração com Google Street View . . . . . . . . . . . . . . . . 544.2.8 Análise e possíveis melhorias . . . . . . . . . . . . . . . . . . . 56

4.3 Aplicação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.1 Geolocalização em aplicações Web . . . . . . . . . . . . . . . . 584.3.2 Utilização da W3C Geolocation API . . . . . . . . . . . . . . . . 594.3.3 Modelo da aplicação móvel . . . . . . . . . . . . . . . . . . . . 614.3.4 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3.5 Análise e possíveis melhorias . . . . . . . . . . . . . . . . . . . 64

4.4 Portabilidade da solução . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 Conclusão 675.1 Notas finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Desenvolvimento futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Referências 71

A Protótipo de interface 75A.1 Slides de apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.2 Prototipagem para funcionalidades desktop - Serviços internos . . . . . . 75A.3 Prototipagem para funcionalidades móveis - Fiscalização . . . . . . . . . 84

viii

CONTEÚDO

B Implementação de operadores de visualização em Web maps 87B.1 Operador de tipificação homogénea . . . . . . . . . . . . . . . . . . . . 87B.2 Tipificação heterogénea . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.3 Deslocamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

ix

CONTEÚDO

x

Lista de Figuras

2.1 Ciclo de desenvolvimento. Retirado de [1] . . . . . . . . . . . . . . . . . 82.2 Níveis de abstracção para visualização . . . . . . . . . . . . . . . . . . . 122.3 (Duas imagens mais à esquerda) Uma igreja representada de duas formas

mais próximas da realidade; (À direita) Uma loja designada pelo nomerepresentada com um ícone. . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Estado da arte das contribuições de diferentes projectos na representaçãode informação em mapas. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Excesso de representações icónicas no Google Earth. . . . . . . . . . . . 142.6 (Direita) Selecção global; (Esquerda) Selecção local. . . . . . . . . . . . 152.7 Operador de simplificação para um conjunto de pontos. . . . . . . . . . . 152.8 Agregação de um conjunto de pontos . . . . . . . . . . . . . . . . . . . . 172.9 Tipificações: à esquerda são salientadas a densidade e homogeneidade, e

à direita a densidade e heterogeneidade. . . . . . . . . . . . . . . . . . . 182.10 Tipificação no trabalho de [2]. Em cima tipificação homogénea e em

baixo tipificação heterogénea. . . . . . . . . . . . . . . . . . . . . . . . 182.11 Tipificação na página oficial de turismo da região alemã de Schleswig-

Holstein [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.12 Operador de deslocamento . . . . . . . . . . . . . . . . . . . . . . . . . 192.13 Operador de deslocamento em acção no trabalho de [2] . . . . . . . . . . 19

3.1 Hierarquia de serviços na gestão de equipamentos . . . . . . . . . . . . . 293.2 Processo de negócio idealizado para o problema de gestão de equipamen-

tos e mobiliário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Diagrama de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4 Modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Fluxo de documentação entre entidades . . . . . . . . . . . . . . . . . . 414.2 Exemplo de notificação ao utilizador sobre a interface . . . . . . . . . . . 424.3 Interface de criação de cadastros . . . . . . . . . . . . . . . . . . . . . . 444.4 Interface de participação pública . . . . . . . . . . . . . . . . . . . . . . 454.5 Notificação de script prolongado . . . . . . . . . . . . . . . . . . . . . . 474.6 Comparação do volume de resposta do servidor usando JavaScript, XML

e JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.7 Comunicação cliente-servidor e estágios de processamento . . . . . . . . 504.8 Filtro de selecção de equipamentos no mapa . . . . . . . . . . . . . . . . 514.9 Tipificação homogénea desenvolvida . . . . . . . . . . . . . . . . . . . . 544.10 Tipificação heterogénea desenvolvida com 2, 4, 6 e 6+ categorias . . . . . 54

xi

LISTA DE FIGURAS

4.11 Operador de deslocamento desenvolvido . . . . . . . . . . . . . . . . . . 544.12 Visualização de detalhes de um equipamento numa InfoWindow . . . . . 554.13 Visualização de um equipamento com Google Street View . . . . . . . . 554.14 Tempos de resposta no processamento de todos os pontos . . . . . . . . . 574.15 LBS e Geolocation API . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.16 Aplicação Google Maps Mobile com triangulação por células de telemó-

vel (à esquerda) e por GPS (à direita) . . . . . . . . . . . . . . . . . . . . 604.17 Aplicação móvel: Login (à esquerda) e página inicial (à direita) . . . . . 634.18 Aplicação móvel: Lista de tarefas (à esquerda) visualização de tarefa (à

direita) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.1 Apresentação à CMP: Slide inicial . . . . . . . . . . . . . . . . . . . . . 75A.2 Apresentação à CMP: Utilizadores . . . . . . . . . . . . . . . . . . . . . 76A.3 Apresentação à CMP: Exposição do fluxo de negócio criado . . . . . . . 76A.4 Apresentação à CMP: Mapa principal . . . . . . . . . . . . . . . . . . . 77A.5 Apresentação à CMP: Visualização de tarefas . . . . . . . . . . . . . . . 77A.6 Apresentação à CMP: Criação manual de tarefas . . . . . . . . . . . . . . 78A.7 Apresentação à CMP: Listagem de pedidos . . . . . . . . . . . . . . . . 78A.8 Apresentação à CMP: Visualização de pedidos . . . . . . . . . . . . . . . 79A.9 Apresentação à CMP: Listagem de equipamentos . . . . . . . . . . . . . 79A.10 Apresentação à CMP: Histórico de um equipamento . . . . . . . . . . . . 80A.11 Apresentação à CMP: Visualização de um documento . . . . . . . . . . . 80A.12 Apresentação à CMP: Edição de um documento . . . . . . . . . . . . . . 81A.13 Apresentação à CMP: Lista de processos . . . . . . . . . . . . . . . . . . 81A.14 Apresentação à CMP: Notificações sobre a interface . . . . . . . . . . . . 82A.15 Apresentação à CMP: Visualização do estado de um processo . . . . . . . 82A.16 Apresentação à CMP: Visualização estatística . . . . . . . . . . . . . . . 83A.17 Apresentação à CMP: Apresentação das funcionalidades móveis . . . . . 84A.18 Apresentação à CMP: Listagem de tarefas em interface móvel . . . . . . 84A.19 Apresentação à CMP: Selecção de tarefa em interface móvel . . . . . . . 85A.20 Apresentação à CMP: Visualizar tarefa no mapa em interface móvel . . . 85A.21 Apresentação à CMP: Submissão de documentos em interface móvel . . . 86

xii

Lista de Tabelas

2.1 Definições de GIS e grupos em que são utilizadas . . . . . . . . . . . . . 62.2 Categorias de POI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Propostas de representação de POI . . . . . . . . . . . . . . . . . . . . . 122.4 Resumo dos operadores de generalização . . . . . . . . . . . . . . . . . 21

4.1 Resposta JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Resposta XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 Resposta JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4 Características da máquina de teste . . . . . . . . . . . . . . . . . . . . . 564.5 Análise do tempo do processamento geo-espacial (msecs) . . . . . . . . . 574.6 Determinação da próxima tarefa do fiscal por sugestão . . . . . . . . . . 64

xiii

LISTA DE TABELAS

xiv

Abreviaturas e Símbolos

AJAX Asynchronous Javascript and XMLAPI Application Programming InterfaceCSS Cascading Style SheetsCMP Câmara Municipal do PortoCRUD Create, Read, Update, DeleteDOI Grau de InteresseDOM Document Object ModelGIS Geographic Information SystemGPS Global Positioning SystemHTML Hypertext Markup Languagei.é isto éIGP Instituto Geográfico PortugêsINESC Instituto de Engenharia e Sistema de ComunicaçõesIP Internet ProtocolLAN Local Area NetworkLBS Location Based ServicesJSON Javascript Object NotationNE NordesteOGC Open Geospatial Consortiump.ex. por exemploPOI Ponto de interessePPGIS Public Participation GISRFID Radio-Frequency IdentificationSQL Structured Query LanguageSW SudoesteURL Uniform Resource LocatorW3C World Wide Web ConsortiumWAN Wide Area NetworkWGS-84 World Geodetic System (1984)WWW World Wide WebXML Extensible Markup Language

xv

ABREVIATURAS E SÍMBOLOS

xvi

Capítulo 1

Introdução

Este capítulo contém uma breve introdução ao trabalho a desenvolver. É introduzidoo contexto deste trabalho através do seu enquadramento a que se segue a exposição dasmotivações e objectivos, metodologia utilizada e os resultados esperados no final. É im-portante sublinhar que todas as noções introduzidas neste capítulo estão desenvolvidasnos capítulos seguintes.

1.1 Enquadramento

As autarquias são responsáveis pela gestão e manutenção dos equipamentos (comop.ex. sinalização horizontal e vertical, contentores, bancos, iluminação, elementos de se-gurança) existentes nas regiões administrativas de que estão responsáveis. A quantidadedestes itens pode ascender a centenas de milhares de unidades, pelo que se não existi-rem mecanismos eficazes para o desenvolvimento da tarefa de gestão, esta pode tornar-secomplexa e susceptível a erros. No caso da Câmara Municipal do Porto (CMP) sabe-seque esta gestão é baseada em folhas de cálculo que funciona como base da informaçãopara a gestão e documentos físicos (papel) que são entregues em mão ou endereçadas aosfuncionários de diferentes departamentos, sendo um processo burocrático e que em al-guns casos pode atrasar processos considerados urgentes. Aponta-se desde logo o grandeponto negativo desta metodologia: a baixa eficiência do processo de gestão. Nesta orga-nização os equipamentos da cidade não estão georreferenciados, e sendo uma das maioresautarquias nacionais, podemos inferir que o mesmo se passa com muitas outras.Como cada um dos equipamentos encontra-se numa determinada localização geográfica epartindo do facto que os serviços que utilizam Sistemas de Informação Geográficos (SIGou mais universalmente GIS) são caracterizados por uma maior eficiência e capacidade

1

Introdução

de resposta, este será o tipo de sistema a ser desenvolvido para esta finalidade. [4] Os GISsão caracterizados pela possibilidade de integrar dados geoespaciais de uma variedade defontes. As suas funcionalidades permitem diferentes tipos de operações de análise espa-cial, permitindo dessa forma inúmeras possibilidades de aplicações tendo em vista umcarácter de tomada de decisão. Obviamente, os mapas têm um papel importante nestetipo de sistemas. Não só apresentam os resultados finais da análise espacial, mas são tam-bém cruciais no processo iterativo de manipulação das informações georreferenciadas. Odesenvolvimento tecnológico associado ao GIS em associação com a WWW permitiu aaproximação da cartografia a outras disciplinas que influenciaram a produção de mapas,nomeadamente ao nível da visualização de dados, interacção e apresentação dinâmica. [5]A informatização e modernização dos sistemas de informação dos organismos públicos,tem vindo a criar maior propensão para a necessidade de criar mais e melhores sistemasde gestão. A utilização do sistema a desenvolver implica a utilização de mapas Web,sobre o qual são colocadas representações abstractas de objectos reais nas suas posiçõesreais. Esta representação pode, se não houver alguns cuidados, levantar alguns problemas.Considerando os dois tipos de componentes do mapa (o próprio mapa e os objectos repre-sentados) eleva-se o mapa como ferramenta principal, isto porque o utilizador dependedele para se orientar e realizar a tarefa em curso. Os objectos, se visualizados todos deuma vez ou com pouco controlo vai debilitar a usabilidade da aplicação. Por esta razão énecessário estudar quais os paradigmas actuais para aplicar regras para a selecção, mani-pulação e apresentação destes elementos.A gestão destes itens engloba três classes de funcionários da CMP, os responsáveis pelaverificação in loco dos equipamentos, o núcleo central da gestão e o(s) departamento(s)de execução. No capítulo 3 é feita uma descrição mais detalhada sobre estes utilizadores.

1.2 Objectivos

O objectivo é criar um sistema que permita obter informação em tempo real sobreas actividades que estão associadas ao processo de gestão dos equipamentos, permitindoautomatizar determinados processos. Pretende-se desenvolver um sistema de georreferen-ciação dos equipamentos da cidade, utilizando mapas Web para visualização de todos osequipamentos, integrando no sistema um componente móvel que permita aos colaborado-res que realizam trabalho no exterior - os fiscais - uma maior eficácia na execução do seutrabalho. Estes funcionários devem poder submeter informação actualizada sobre cadaum dos itens. A automatização do processo de gestão deve permitir minimizar a necessi-dade de intervenção humana em acções de gestão sempre que possível. A experiência daCMP é que a maior parte dos inputs no fluxo operacional de gestão dos equipamentos éproveniente dos habitantes da cidade, quer via telefone, e-mail ou carta. Na maior parte

2

Introdução

dos casos estes contactos são devidos a emergências existindo necessidade de uma rápidaresposta dos serviços executores.Uma característica obrigatória do sistema visa a possibilidade de adicionar novos ca-dastros aos equipamentos. Entende-se por um cadastro, o conjunto de nome, categoria,atributos e conjunto de valores possíveis para cada um daqueles atributos.No campo da visualização científica é esperado utilizar conceitos identificados no levan-tamento bibliográfico (capítulo 2) para aplicar os mecanismos de visualização necessáriosao domínio deste trabalho.

1.3 Metodologia

Este projecto iniciou-se com um período de pesquisa e experimentação. GIS, ferra-mentas associadas, visualização de informação e a utilização de GIS para processos degestão formam alguns dos temas incluídos nessa fase de contacto inicial com este domí-nio. Foi estudada a manipulação de dados georreferenciados utilizando para tal bases dedados específicas para estes fins. A partir desse ponto foi desenvolvido o estado da artepresente no capítulo 2 deste documento, em que se deu ênfase a questões de visualizaçãode informação sobre mapas Web.Com base em dois ficheiros Microsoft Excel provenientes da CMP e nas característicasa providenciar pela solução foi estruturado um modelo de dados presente no capítulo 3.Outro conjunto de dados, igualmente da CMP e constituído pelas vias e caixas da cidadedo Porto, foi utilizado para constituir uma plataforma de testes.Tendo em conta a futura fase de desenvolvimento foram estudadas algumas linguagens deprogramação para a Web (PHP, JSP e Ruby on Rails). Este estudo teve como objectivoaveriguar a possibilidade de abstracção da base de dados e objectos geoespaciais com autilização de uma camada de mapeamento objecto relacional e utilização das OGC Sim-ple Features. Foi concebido um processo genérico de gestão de equipamentos. Após adefinição dos requisitos, e arquitectura da aplicação foram então desenvolvidos os módu-los da solução.

1.4 Resultados esperados

Esta dissertação espera realizar algumas contribuições em áreas distintas. Enume-rando cada uma delas, as contribuições esperadas no final são:

• Desenvolvimento de sistemas GIS aplicados à gestão de equipamentos municipais

• Integração de equipamentos móveis na gestão de equipamentos municipais

3

Introdução

• Promoção de aplicações PPGIS em organismos de gestão pública

• Promoção de sistemas de informação GIS junto das entidades governamentais

• Utilização de ferramentas open-source na produção de sistemas GIS

• Visualização de informação em mapas Web interactivos

1.5 Impacto

As informações sobre as propriedades de domínio municipal constituem informaçãode interesse para apoiar as políticas de gestão das redes viárias e gestão financeira dasautarquias. A informação relativa ao cadastro patrimonial de um município, sendo vitalpara a gestão desse mesmo património, contribui para um correcto planeamento e desen-volvimento, principalmente no que diz respeito à reserva e disponibilização de objectos ezonas de utilidade pública aos utentes.Assim o fácil acesso à informação sobre todos os equipamentos municipais contribuirápara um aumento da qualidade em termos de gestão do registo de todos aqueles objectos,e consequentemente para um aumento da eficácia nas actividades de planeamento e ges-tão urbanística.

1.6 Organização do documento

Este documento de dissertação está organizado em 5 capítulos correspondendo o pri-meiro a esta introdução.No capítulo 2 é realizado o levantamento do estado da arte sobre aplicações GIS utilizadasem gestão do ambiente urbano e sobre as questões de visualização de informação que irãoser relevantes para a apresentação dos pontos sobre o mapa. É apresentada uma informa-ção inicial sobre os sistemas GIS e seus componentes essenciais. O capítulo 3 é dedicadoà especificação da solução a utilizar para o desenvolvimento do protótipo. Para além dametodologia utilizada, especificam-se arquitectura, utilizadores, módulos da aplicação emodelo de dados. As decisões tomadas na implementação de cada um dos módulos éexposto no capítulo 4. Este documento termina com o capítulo 5 onde se exibe algumasconclusões sobre o trabalho realizado e desenvolvimentos futuros.

4

Capítulo 2

Revisão bibliográfica

Neste capítulo realiza-se uma introdução aos sistemas GIS descrevendo os seus com-ponentes e um resumo do que é necessário para a implementação de sistemas deste tipo.É apresentado um levantamento sobre a utilização destes sistemas por parte das institui-ções no que toca à gestão urbanística. O caso específico de gestão de equipamentos não écomentado, porque não foi possível encontrar qualquer exemplo no que toca a esse domí-nio de aplicação. Finalmente é focada a importância e aspectos da visualização de pontossobre mapas Web, considerando algumas possibilidades concretas de como resolver algu-mas situações que vão ser identificadas neste capítulo.

2.1 Sistemas de informação geográficos

As ferramentas GIS surgiram nos anos 70 como uma nova abordagem à organiza-ção da informação geoespacial em computadores. Estes sistemas combinam uma basede dados de atributos aos quais estão associadas localizações geográficas. Estes atributosreferem-se a linhas, pontos ou áreas definidas pelas suas coordenadas. Embora a maioriadas aplicações GIS se preocupem basicamente com mapas, o termo GIS é usado para umapanóplia de outras funções como exposto em 2.1. [6]Encontram-se na Web algumas aplicações que providenciam ao utilizador comum a na-vegação e utilização de mapas como o Google Maps, Bing Maps entre outros disponíveisnos principais motores de busca. Embora estas páginas providenciem um serviço de valorinquestionável, estes de pouco servem para fornecer conhecimento sobre GIS ao públicoem geral. Naturalmente não podemos criticar os serviços porque a facilidade de utilizaçãoé o principal objectivo. O que estas aplicações fazem é esconder a complexidade e poten-cialidades destes sistemas ao utilizador funcionando como uma black box da arquitectura

5


dos sistemas GIS. [7]

2.1.1 Definição

Têm sido sugeridas muitas definições de GIS ao longo dos anos, e nenhuma delas éinteiramente satisfatória. O seu significado depende fundamentalmente do contexto emque ela é usada e encontra-se sumariada na tabela 2.1.

Tabela 2.1: Definições de GIS e grupos em que são utilizadas

Definição Grupo de utilizadoresUma aplicação de mapas digitais Público em geralUma ferramenta computorizada pararesolver problemas geográficos Responsáveis pela tomada de decisão e planeamentoSistema espacial de suporte à decisão Ciência de gestão e investigadores operacionaisSistema mecanizado para inventariaçãode elementos dispersos geograficamente Gestores de bens, transportes e recursosFerramenta para evidenciar informaçõesgeográficas pouco evidentes Cientistas e investigadoresFerramenta para realizar operações sobredados geográficos consideradasmonótonas, dispendiosas ou imprecisasse realizadas à mão Gestores de recursos e de planeamento

Como se pode verificar, existem muitas diferenças nas definições preferidas dentro decada grupo de utilizadores e revelam a finalidade da utilização destes sistemas. [8]

2.1.2 Componentes

Os componentes chave de qualquer sistema GIS são os utilizadores, dados e sistemasde computadores.O primeiro componente é considerado como o mais importante, embora alguns defendamos dados como tal. No entanto, estes sistemas são desenvolvidos a pensar nas necessida-des dos utilizadores das organizações sendo dependentes do seu funcionamento para rea-lizar o seu trabalho, responder a questões de forma a interagir com outras organizações epessoas. Os sistemas de informação, geográficos ou não, de certo são desenvolvidos paradar suporte ao trabalho de forma torná-lo mais eficiente e com alto nível de confiança nosoutputs fornecidos. Por essa razão o desenho destes sistemas começa nas pessoas, pelaanálise das suas necessidades, sendo estas que vão utilizar e aprovar o sistema final.Os dados (georreferenciados) são normalmente classificados em dados geométricos e atri-butos. Os dados geométricos consistem de pontos, linhas e áreas e podem estar em for-mato vectorial ou raster (imagens), representando uma geometria de topologia, tamanho,

6


forma, posição e orientação. Estes dados estão geralmente guardados numa base de dadoscom funções que permitem a manipulação e interrogação sobre dados geográficos.Um sistema de computadores consiste em hardware, software e procedimentos para su-portar a captura, processamento, análise, modelação e visualização de dados georreferen-ciados. [9, 1]

2.1.3 Standards para a Implementação de GIS

Uma aplicação empresarial GIS pode ser construída com a ajuda de uma base de dadosque suporta funções específicas para processamento de informação espacial, no entantomuitas vezes este tratamento de dados é feito pelo próprio software. Esta base de dadosgeoespacial pode estar centralizada para acesso em tempo real ou ser replicada em vá-rios computadores na organização. O processo de design e implementação de um sistemaGIS numa organização pode demorar até um ano ou mais, dependendo do tamanho daorganização e a quantidade de dados geográficos a ser incorporado. Num sistema bemdesenhado, os utilizadores que laboram em departamentos em que já interagiam com osistema GIS, vão usar o sistema de forma muito semelhante ao que faziam antes da actua-lização. Os novos utilizadores passam a utilizar aplicações talhadas à medida conforme odeterminado na fase de levantamento de requisitos. O desenvolvimento de uma aplicaçãoGIS envolve várias fases e intervenientes bem estipulados. [1]Devem ser analisados os processos de negócio para determinar os benefícios a tirar pelaautomação da tecnologia GIS. Uma plataforma GIS possibilita responder a diversas ne-cessidades das organizações permitindo aplicações de vários tipos, como por exemplo:

• Visualização, localização e interrogação de dados;

• Seguimento local de reclamações;

• Pesquisa de endereços;

• Manutenção e inventário;

• Mapeamento e seguimento de incidentes;

• Aplicações de cálculo de rotas;

A selecção/desenvolvimento de aplicações depende e é limitada pelo ambiente técnico(sistemas operativos, rede de computadores interna, base de dados a ser utilizada, etc).Para além disso, deve ser avaliada pela organização, a relação custo/benefício do sistemaa introduzir.No ponto de vista de uma aplicação cliente, estando incluído um mapa, a visualizaçãodos seus elementos constituintes é constituída por camadas (layers). Os dados destascamadas podem vir a partir de uma base de dados ou a partir servidores que implementam

7


os padrões definidos pela OGC. No lado do servidor que trata dos pedidos dos clientes,estes dados são obtidos (por um conjunto de interrogações a partir da base de dados e/ouservidores de mapas) e tratados de forma a enviar a representação desejada ao cliente. Aosdados georreferenciados está sempre associada uma projecção espacial como por exemploWGS-84 (utilizada nos dispositivos GPS). No caso de existirem mais do que uma camada,todas elas devem ter as coordenadas geográficas usando o mesmo sistema projecção, casocontrário irão existir desfasamentos entre as camadas e estas não vão coincidir. No casodas camadas não terem o mesmo sistema de projecção, terá que existir uma transformaçãoprévia à visualização.Para além da análise dos requisitos e dos elementos do GIS descritos em 2.1.2, devem sertidos em conta os conceitos e boas práticas do desenvolvimento de sistemas de softwarepela criação de um processo que leve ao sucesso do projecto (figura 2.1). [1]

Figura 2.1: Ciclo de desenvolvimento. Retirado de [1]

2.2 GIS e Gestão Urbana

Existem cinco razões principais pelas quais os governos adoptam a tecnologia GIS:aumento da eficiência, melhor informação para tomada de decisão, mais consistênciana informação, melhor organização governamental (devido à visualização holística dosdados e não departamental) e melhor interacção entre o público e os órgãos governamen-tais. [10] A tecnologia GIS pode ser bastante útil para resolver tarefas complexas paramanutenção de infraestruturas, servindo como um repositório de informação, suportandoa tomada de decisão pela análise da informação assente nas camadas de dados. Estaanálise pode incluir localização do trabalho realizado, progresso, análise espacial entre

8


muitas outras possibilidades. Pode também ajudar os habitantes a verificarem transparen-temente o investimento local ou nacional. [11]Nesta secção faz-se uma breve revisão de algumas aplicações que foram desenvolvidas noâmbito da gestão urbana. Não foi possível neste momento encontrar informações sobreaplicações no contexto da dissertação. Apenas se faz uma referência a alguns dos traba-lhos expostos recentemente na literatura. Apresentam-se de seguida três projectos de GISbem distintos no que diz respeito aos problemas e abordagens tomadas.

2.2.1 Abordagens GIS em aplicações de gestão urbana

O sistema de suporte à decisão descrito por [12] tem como objectivo o desenvolvi-mento de uma ferramenta para planeamento de áreas agrícolas e toma como justificaçãoproblemas de desenvolvimento urbano como a disparidade de rendimentos, o crescimentodesequilibrado, diminuição da qualidade da água entre outros. Este sistema tem entãoem conta variáveis ecológicas e económicas. Tem como base um repositório de conhe-cimento, a partir do qual tomando algumas regras estabelecidas, realiza inferência paradecidir e planear de forma autónoma o ambiente abrangido espacialmente. O sistema finaltem como objectivo criar um Expert System que considera a experiência e conhecimentode um grupo de especialistas, tal como os objectivos a serem atingidos pelo sistema deacordo com as necessidades do utilizador. Um sistema de avaliação do território pode serclassificado de acordo com o tipo de colheitas ou o tipo de gestão, e ambos devem ter emconta factores ambientais, económicos e sociais como os descritos anteriormente. Esteprojecto enquadra-se no âmbito da inteligência artificial, utilizando redes neuronais e uti-liza o algoritmo de backpropagation comum como forma de aprendizagem. Uma questãoimportante levantada nesta aplicação foi a integração de informação de diferentes fontese combinações de dados georreferenciados. Levanta-se ainda alguns aspectos relevantesrelacionados com a combinação destes dados: a informação tem diferentes concepções(dados sócio-económicos, ambientais, etc), resoluções (imagens de satélite, aéreas, etc) ede precisão (dados coleccionados com modelação geoestatística, por inquéritos, etc.). Aintegração desta informação foi feita com alguns métodos descritos na literatura como porexemplo operadores booleanos, lógica fuzzy e métodos de probabilidade bayesiana tendosido este último, o método usado juntamente com alguns outros métodos estatísticos.O trabalho de [13] descreve um esforço de 5 anos para oferecer uma solução que dis-ponibiliza conhecimento geográfico partilhado de 14 cidades do estado de New Jerseynos Estados Unidos. O objectivo é obter um sistema que permite a edição colaborativaem que, municípios e indivíduos se voluntariam para produção de informação geográficapara o benefício dos serviços do governo em prole dos cidadãos. Este estado, tem 566regiões municipais cada uma com um corpo administrativo e missões distintas. A tendên-cia é integrar as missões individuais numa missão do governo local. No entanto, cada um

9


dos departamentos (bombeiros, polícia, infraestrutura, etc) de cada município é geridoindependentemente e existia a tendência dos gestores departamentais não trabalharem emuníssono. Por exemplo, cada departamento produzia o seu próprio mapa e incluiam asua própria simbologia. No sentido de homogeneizar e tentar chegar a um acordo foramreunidos todos os envolvidos e detentores do conhecimento dos diferentes processos denegócio, para se identificarem pontos comuns. A partir dos pontos comuns foram colec-cionadas as camadas temáticas para os mapas e definido o modelo conceptual da base dedados georreferenciada. As geometrias e localizações dos elementos geográficos foramactualizadas utilizando GPS. As tecnologias aqui usadas foram as produzidas pela ESRI:ArcGIS, ArcCatalog e ArcIMS. Os layers resultantes foram separados em três aplicaçõesdistintas, uma contendo informação sobre as infraestruturas municipais e conteúdo demo-gráfico com possibilidade de interrogação, outra permitindo a visualização dos terrenosindicando dono/inquilino e avaliações, e a terceira especialmente concebida para interro-gações sobre riscos associados a edifícios. [14]A utilização de tecnologias 3D no planeamento urbano, análise de viabilidade do pla-neamento com técnicas baseadas em realidade virtual é descrita no artigo de [15]. Estetipo de sistema virtual permite a modelação de cenas que expressam o mundo real. Destaforma, os responsáveis pela tomada de decisão podem ter uma melhor sensação das alte-rações a serem causadas pelas futuras edificações. A aquisição de dados inclui modelosde elevação de terreno (p.ex. utilizando fotogrametria1), obtenção de texturas do terrenoe edifícios, modelação de modelos 3D (utilizando software específico como 3DMAX,Multigen e AutoCAD) dos edifícios e recolha de informações geográficas. O design daaplicação inclui a comunicação entre os módulos GIS e 3D, como a interrogação e visua-lização dos resultados dentro da cena 3D, adição de elementos no módulo GIS (p.ex. umaestrada) a partir de um template com visualização subsequente no módulo 3D, etc. Oselementos de alguns dos edifícios são baseados em templates para uma melhor gestão dememória, nomeadamente quando os edifícios apenas diferem em algumas característicasmenos importantes.

2.2.2 Resultados obtidos

Os projectos descritos por [12] e [13] avaliam como positivos os resultados obtidos.No primeiro, compara-se com os métodos tradicionais de avaliação dos terrenos realiza-dos por cientistas especializados. Este é um bom exemplo de como a junção entre GIS ea inteligência artificial pode ser feita com sucesso. No entanto, consideram que o sistemapode ser expandido com a utilização de outros algoritmos para medição de custos e riscosassociados à tomada de decisão. No segundo, ficou assente que as cinco razões enuncia-das no início deste capítulo foram cobertas.

1Determinação das propriedades geométricas dos objectos a partir de imagens fotográficas

10


O último projecto descrito é ainda um protótipo, e acredita-se que o futuro da gestão edesign urbano passe pela utilização destas técnicas.

2.3 Visualização de informação em mapas Web

A representação de itens do mundo real num mapa é feita com diferentes tipos de re-presentações gráficas e/ou textuais com o objectivo de aumentar a cognição do utilizador.Estas representações contudo podem variar no nível de abstracção que deve ser tido emconta no desenvolvimento da interface. Isto deve-se ao facto de que um utilizador comumpoder ser distraído com demasiado realismo e pode perder noção da sua posição no es-paço real no caso de existirem poucas referências simbólicas.No estudo [16] são propostos conceitos de design para a visualização de pontos de in-teresse em equipamentos móveis. Estes pontos de interesse, constituídos apenas por edi-fícios, foram categorizados em quatro grupos descritos na tabela 2.2 e as visualizaçõespossíveis diferem no seu nível de abstracção desde fotografias foto-realistas, desenhos,esboços e ícones a símbolos e palavras (figura 2.2). [17]

Tabela 2.2: Categorias de POI

Tipo de POI DescriçãoLojas (referenciadas pelo nome) Lojas e restaurantes conhecidas pelo

nome comercial (KFC, McDonalds...)Lojas (referencias pelo tipo) Lojas referenciados pelo seu tipo

ou função comercial (hotel, farmácia...)Edifícios (com nomes/função única) Edifícios conhecidos pelo seu nome ou

função (CMP, Lojado Cidadão...)

Edifícios (com propriedades visuais únicas) Edifícios conhecidos pelos seuspormenores de arquitectura(Torre dos Clérigos...)

A ideia é que a comunicação do ponto de interesse seja feita de uma forma imediata(mínimo esforço mental) e que auxilie na determinação da posição geográfica. Logica-mente, é possível apresentar e transmitir informação utilizando apenas texto, no entantoé seguro afirmar que não seja a forma visual mais correcta para além de que exige umamaior sobrecarga cognitiva. Por esta razão, as palavras são consideradas apropriadas, so-mente no caso de não existir uma forma mais eficiente de comunicar a informação. [16]

Um logótipo comercial de uma marca, é considerado como sendo algo facilmente re-conhecido, por essa razão uma representação icónica é uma boa opção para transmitir ainformação. Na maior parte dos casos, não é necessária descrição dos edifícios, no en-tanto se um deles contiver algum aspecto peculiar e único na sua arquitectura, um esboçodo edifício pode ser usado com benefício para o utilizador. No caso das lojas, se estas são

11


Figura 2.2: Níveis de abstracção para visualização

referenciadas de forma genérica, ícones e símbolos associativos podem ser usados. Nocaso de não existir um símbolo para representar a loja, torna-se necessário recorrer ao usode palavras. Se os aspectos visuais de um edifício são importantes para descrever o POI,estes devem ser retratados com desenho ou com uma imagem. A proposta de representa-ção para cada um dos tipos de edifício encontra-se sumariada na tabela 2.3. [16]

Tabela 2.3: Propostas de representação de POI

Imagem Desenho Esboço Ícone Símbolo PalavrasLoja (nome) (+) +Loja (tipo) + + +Função/Nome + + + +Aspecto visual + +

Podem-se ver exemplos de imagens utilizadas para os testes aos utilizadores, utili-zando algumas das representações referidas anteriormente na figura 2.3.

Figura 2.3: (Duas imagens mais à esquerda) Uma igreja representada de duas formas mais próxi-mas da realidade; (À direita) Uma loja designada pelo nome representada com um ícone.

Na figura 2.4 podemos analisar diferentes projectos comerciais que tomam diferen-tes tipos de representação espacial. Podemos verificar que apenas uma das analisadas(existem mais) utiliza somente imagens enquanto que a maioria utiliza uma combinação

12


de simbologia abstracta (ícones e símbolos) com POIs com representação realista (ima-gens). [17]

Figura 2.4: Estado da arte das contribuições de diferentes projectos na representação de informa-ção em mapas.

2.3.1 Problemas na visualização de informação em mapas Web

Ao desenhar uma aplicação baseada em mapas existem outros factores que não devemficar esquecidos, isto porque vão influenciar a decisão de como representar a informação,podendo ser necessário ponderar o próprio nível de abstracção. Estes problemas são:

• Congestionamento — Demasiados elementos apresentados num espaço limitado;

• Coalescência — Detalhes da visualização num ecrã dependem da sua resolução;

• Imperceptibilidade — Elementos são imperceptíveis a partir de determinada di-mensão;

Estes aspectos podem trazer a necessidade de representações mais abstractas do querealistas. A relevância deste assunto é ainda mais saliente quando estas aplicações se des-tinam a equipamentos móveis devido à capacidade limitada de memória, processamentoe da resolução, número de cores e tamanho do ecrã limitados. [18, 17]O problema de congestionamento pode ser facilmente observado no Google Earth se-leccionando diferentes camadas de informação. O resultado é um mapa com excessode representações icónicas, de tal forma que este fica parcial ou totalmente coberto pelainformação. A imagem 2.5 é um bom exemplo do que se está a transmitir. [17]

O exagero de ícones nesta imagem degrada a usabilidade da interface. Esta visualiza-ção pode ser melhorada utilizando mecanismos de filtragem e simplificação, que têm pre-cisamente como objectivo a redução da informação espacial mostrada sobre o mapa. [2]No contexto da imagem anterior o utilizador poderá alterar o valor de zoom para um níveldiferente. Ao ser executada esta acção, alguns dos ícones podem ser alterados ou mesmo

13


Figura 2.5: Excesso de representações icónicas no Google Earth.

desaparecer. Esta característica é denominada de zoom adaptativo, e pode ser visualizadanesta aplicação apenas dentro de certos domínios de dados (p.ex. dados da camada Pa-noramio). Outro ponto associado a esta temática consiste em complexidade adaptativaque consiste na modificação do nível de abstracção baseado na complexidade global domapa. [17]

2.3.2 Métodos anti-congestionamento

A forma de reduzir a quantidade de informação num mapa passa pela utilização deoperadores de generalização. A generalização de pontos no mapa pode fazer com que al-guns deles se desloquem das suas posições originais, distorcendo a relação espacial entreos elementos.[19] sugere cinco operadores de generalização: selecção, simplificação, agregação, tipifi-cação e deslocamento. Para uma aplicação eficaz destes operadores podem ser utilizadasframeworks para análise estatística do espaço geográfico e para modelar a distorção doespaço. Adicionalmente são necessárias ferramentas de clustering para identificação dedomínios espaciais, ou seja, os grupos de elementos onde estas variações ocorrem.

SelecçãoEste operador consiste na identificação de elementos e seus atributos a serem retrata-

dos numa determinada escala do mapa. A selecção está ligada com a semântica desseselementos e não tanto com a sua localização geográfica. Pode ser aplicada globalmente oulocalmente. A selecção global consiste na filtragem dos elementos do mapa por selecçãode atributos, criando conjuntos de elementos a partir de um conjunto mais alargado, redu-zindo a possibilidade de conflitos no mapa como a sobreposição (figura 2.6 - esquerda).

14


Estes conflitos, a surgirem com o uso desta técnica têm que ser tratados com a utilizaçãode outros operadores. [19]

Figura 2.6: (Direita) Selecção global; (Esquerda) Selecção local.

A selecção local é mais apropriada em termos do seu oposto, isto é, a omissão. Esteoperador é utilizado aquando de conflitos nas representações dos pontos no mapa. Procuraomitir símbolos num conjunto conflituoso, baseando-se na sua importância semântica re-lativa. Como este operador não afecta a posição dos símbolos no mapa, este é importantequando se pretende manter o elemento na posição exacta tal como é referenciada no es-paço (figura 2.6 - direita). [19]

SimplificaçãoA simplificação pode ser vista como um tipo de selecção que filtra os elementos

baseando-se nas propriedades espaciais, reduzindo a densidade ou o nível do detalhe dosdados. É apresentado frequentemente com técnicas de optimização com uma função ob-jectivo, com a finalidade de encontrar um subconjunto que melhor aproxima o conjunto detodos os elementos que respeita características pré-definidas. O tamanho do subconjuntopode ser previamente adoptado ou pode estar dependente de uma margem de erro. Aplica-se geralmente à totalidade do mapa embora possa ser usado mais localmente em gruposde elementos. O objectivo desta aproximação consiste em aliviar o mapa de conflitos enão a eliminação destes por completo (figura 2.7). [19]

Figura 2.7: Operador de simplificação para um conjunto de pontos.

Os autores [2] criaram uma plataforma de visualização de mapas para dispositivosmóveis [20], e provavelmente deparam-se com o problema de congestionamento. Pararesolver esta questão, usam a técnica publicada por [21]. Esta técnica – GeneralizedFisheye Views – explora a apresentação de grandes estruturas de dados em ecrãs de re-duzidas dimensões e usa fisheye views para resolver estas situações. Para clarificar este

15


conceito, Furnas expõe formalmente a ideia e o algoritmo na sua publicação.Fisheye views usa a função de “grau de interesse” (DOI) que atribui a cada ponto da es-trutura de dados um valor numérico representando o interesse que o utilizador tem emvisualizar um determinado objecto dada a tarefa actual. Nesta altura, considerando umainterface para visualização de tamanho n, pode então mostrar os n pontos “mais interes-santes”. A técnica de Furnas passa por decompor o DOI em dois componentes: umaimportância a priori que representa o interesse global em visualizar o objecto, e umaimportância a posteriori que depende do que o utilizador está a focar no momento e éexpresso numa função de distância:

onde DOI consiste no grau de interesse do utilizador num objecto x, dado que o pontoactual de foco é y. API(x) é a importância a priori de x e D(x,y)é a distância entre x e oponto actual y. Ou seja, o interesse aumenta com a importância a priori e diminui coma distância ao ponto. Para o cálculo da importância dos pontos, no trabalho de [2] sãoutilizados atributos de cada ponto, como categoria, preço, etc. O valor final de DOI vaidecidir se o objecto x vai ser ou não visualizado na interface, sendo para isso necessá-rio decidir um valor limite. [21] Desta forma os elementos são filtrados e o seu númerotorna-se mais reduzido no mapa, tornando-se menos provável a sobreposição dos objectosrepresentados. E de facto a distribuição dos elementos, por não ser uniforme, pode fazercom que estes se encontrem com uma proximidade que dificulte a leitura do mapa. [22]

AgregaçãoEste método consiste na substituição de um ou mais elementos do mapa por um seu

substituto, representando a agregação dos primeiros (figura 2.8). O objectivo é a redu-ção do nível do detalhe do mapa pela diminuição do número de elementos e do nível deabstracção da semântica dos tipos de elementos. A agregação é usada onde os elementosestão espacialmente muito próximos para se considerar que existem em posições distintase que por essa razão não faz sentido considerar as entidades individuais. Esta situaçãoocorre quando uma diminuição da escala do mapa faz com que um conjunto de elementosdeixe de ser distintos. [19]

Para esta aplicação existe a necessidade de duas regras: definição das condições se-mânticas e definição das condições espaciais. Pontos no mapa apenas podem ser agrega-dos se existir nos elementos uma semântica associada que permita criar uma relação entreas entidades individuais. Então, os elementos podem ser facilmente identificáveis, pelasua classificação comum ou pela existência de um elemento mais abstracto que integraas classes individuais (geralmente expresso como relações “parte de”). Relativamente às

16


Figura 2.8: Agregação de um conjunto de pontos

regras espaciais, para além de poder ser considerada uma determinada distância limite,podem existir regras topológicas (p.ex. os elementos devem estar todos numa posiçãorelativa a outro atributo do mapa como um lado específico de um rio).Estas regras que devem ser satisfeitas para determinar a aplicação de uma agregação, sãochamadas de regras de ligação (linkage rules). A agregação é aplicada a todo o mapa eapenas resolve conflitos gráficos entre os conjuntos de elementos que satisfazem as regrasde ligação. [19]

TipificaçãoEste operador pode ser visto como um tipo de agregação, no entanto, usa um padrão

de relações espaciais entre um grupo de elementos para mostrar a existência de um novofenómeno. Devido à prioridade das relações espaciais, a tipificação apresenta o novofenómeno usando uma combinação de um conjunto mais reduzido de elementos (em vezde apenas um como a agregação). Com esta técnica é possível suavizar as restriçõescartográficas entre elementos do mesmo grupo. Por exemplo, é possível apresentar umpadrão tipificado que inclui símbolos sobrepostos para dar a noção de densidade. Noentanto esta abordagem tem ela própria algumas restrições:

• Deve ser assegurado que o suficiente de cada símbolo é visível para o identificarindividualmente no grupo

• Símbolos de menores dimensões devem ficar sempre por cima dos restantes

• A forma do grupo reflecte sempre a distribuição original

Na figura 2.9 podemos analisar dois tipos de tipificação. A tipificação pode ser feitade diferentes maneiras, tendo sempre como base evidenciar a configuração base. Ambossalientam a densidade de pontos no mapa mas à esquerda evidencia-se a homogeneidadee à direita a heterogeneidade. A tipificação elimina sempre os conflitos gráficos entre osgrupos de elementos tidos em conta. No entanto, podem remanescer conflitos entre outrospontos e o grupo criado. [19]

No trabalho de [2] citado anteriormente, a resolução de conflitos é feita usando esteoperador. A superfície do mapa é dividida em regiões quadradas como uma matriz. Se

17


Figura 2.9: Tipificações: à esquerda são salientadas a densidade e homogeneidade, e à direita adensidade e heterogeneidade.

todos os pontos do mapa que se encontram dentro da célula pertencem à mesma catego-ria, é aplicado o operador de tipificação homogéneo e, no caso de existirem diferentescategorias dentro da célula e sem ligação semântica, aplica um operador de tipificaçãoheterogéneo. Neste último caso, e de forma interessante, usa a cascata de tipificação ho-mogénea, colocando como sua representação um ícone com as diferentes representaçõesdos objectos substituídos. Apenas coloca três destes símbolos, e no caso de existiremmais para além destes, é colocado como quarto símbolo de “reticências” para indicar queexistem outros tipos dentro do grupo gerado (figura 2.10). O portal de turismo da regiãoSchleswig-Holstein na Alemanha exibe também este tipo de operador (figura 2.11). [3]

Figura 2.10: Tipificação no trabalho de [2]. Em cima tipificação homogénea e em baixo tipificaçãoheterogénea.

Figura 2.11: Tipificação na página oficial de turismo da região alemã de Schleswig-Holstein [3]

DeslocamentoO deslocamento configura os símbolos de forma a resolver conflitos movendo-os em

direcções distintas, para que se afastem mutuamente. Este é visto como um problema deoptimização onde o objectivo é encontrar a melhor aproximação para que um conjunto delocalizações satisfaça um conjunto de restrições. Para além dessas restrições incluírem

18


a resolução de conflitos, devem também incluir considerações para preservar relaçõesespaciais. As posições finais determinadas para uma acção de deslocamento devem terem conta uma análise do espaço envolvente, para que haja uma noção do espaço livre eassim saber para onde os elementos deslocados se podem mover. [19]A imagem 2.12 contém uma demonstração gráfica do que consiste este operador.

Figura 2.12: Operador de deslocamento

[2] utiliza este operador como alternativa à tipificação. Justifica o seu uso para quandoo utilizador explicitamente solicita na interface para visualizar pontos de interesse especí-ficos e para maiores níveis de zoom, isto é, quando os anteriores não podem ser utilizadospelo maior risco de sobreposição de ícones. Em comparação com a figura 8 e à seme-lhança do que pode ser verificado no Google Earth, é colocado uma linha entre a posiçãofinal do ícone e o ponto no mapa onde existe ponto de interesse (figura 2.13).

Figura 2.13: Operador de deslocamento em acção no trabalho de [2]

2.3.3 Estratégias para generalização

A generalização decompõe-se em dois instantes sequenciais de processamento: gene-ralização do modelo e generalização (carto)gráfica. O primeiro pretende preparar o con-junto de dados a ser generalizado a uma resolução apropriada, ou nível de detalhe paraa escala actual do mapa. Deve recolher padrões existentes na distribuição da informaçãono mapa para preservar a variação espacial dos elementos, particularmente a variação es-pacial de primeira ordem — densidade da informação. A segunda pretende assegurar alegibilidade da informação em respeito a restrições gráficas (p.ex. mínima separação en-tre os elementos simbólicos). A generalização cartográfica cria modificações na estruturada variação espacial para resolução dos conflitos gráficos, e deve estar preocupada com avariação espacial de segunda ordem —distribuição espacial.Os operadores selecção global, agregação e simplificação são exemplos de operadores

19


de modelo. Actuam globalmente nos dados de forma a determinar o nível de abstrac-ção simbólica (selecção, agregação) e o nível de densidade da informação (simplificação,agregação).Selecção local, tipificação e deslocamento são operadores de generalização gráfica. Ac-tuam localmente para resolver conflitos gráficos. No entanto, estes devem ser utilizadosem conjunto com algumas informações reunidas na fase anterior de generalização do mo-delo. Caso contrário, pode resultar em soluções locais satisfatórias que se afastam dopadrão geral do mapa, violando a sua consistência. [19]

2.4 Resumo

Realizou-se neste capítulo uma introdução aos GIS partindo da sua definição maisaceite actualmente. O desenvolvimento de um sistema deste tipo, envolve principalmenteas pessoas que irão utilizar o sistema e também os dados. Estes dados têm uma ligeiradiferença relativamente às bases de dados comuns. Associados aos seus atributos encon-tramos coordenadas (determinadas por uma projecção bem definida) definindo os pontosgeográficos onde estes fenómenos se encontram.Foi demonstrado algumas das mais valias e potencialidades que os GIS têm para umaeficiente gestão e planeamento urbano. A adopção desta tecnologia deve ter em conta ascinco razões enunciadas para que se possa tirar melhor partido das aplicações. Por essarazão, esses pontos devem ser considerados para realizar uma avaliação do benefício.Justificou-se a importância da ciência da visualização de informação no estudo dos mapasWeb. São impostos factores de usabilidade, determinada pela legibilidade e transmissãode informação presente no mapa. É importante que se tenha em atenção que a metodolo-gia adoptada pode influenciar em grande escala a eficiência da sua utilização, e que podetrazer consequências de desempenho para quem os utiliza para realizar uma determinadatarefa.As diferentes formas com que os diferentes elementos são representados no mapa, desdea sua forma mais abstracta (textual) até uma mais realista (imagens fotográficas) afectama cognição e consequentemente a usabilidade da interface. As representações icónicas sãoas mais utilizadas na gama das aplicações comerciais e nas disponibilizadas gratuitamentena Web (Google/Bing Maps, Google Eath e outros). Ficou assente também que os níveisde zoom do mapa necessitam de ajustes quer no nível de abstracção visual do ponto, querna estratégia de generalização.A tabela 2.4 sumaria os diferentes operadores de generalização descritos neste capítulode acordo com a possibilidade de redução do nível do detalhe no mapa e resolução deconflitos. [19]

20


Tabela 2.4: Resumo dos operadores de generalização

Operador Redução do nível do detalhe Resolução de conflitos gráficosSelecção global Sim NãoSelecção local Sim SimSimplificação Sim NãoAgregação Sim NãoTipificação Sim SimDeslocamento Não Sim

21


22

Capítulo 3

Solução para gestão de equipamentosurbanos

Este capítulo está reservado à apresentação da solução para o problema de gestãode equipamentos urbanos. A este projecto resolveu dar-se um nome e ficou denominadocomo Urbest - Gestão de Equipamentos e Mobiliário Urbano. São descritos os conceitos erequisitos para que a solução possa funcionar e ter os resultados esperados. É apresentadaa arquitectura da solução bem como o modelo de dados a utilizar no desenvolvimento.O conceito criado foi apresentado sob a forma de protótipo não funcional à DirecçãoMunicipal da Via Pública da CMP que não só deu o conceito como válido como contribuiucom algumas ideias de forma a tornar mais realista e viável a aplicação. A prototipagemapresentada à CMP encontra-se no anexo A.

3.1 Visão geral

Como ficou assinalado no capítulo introdutório, a gestão de equipamentos e mobiliá-rio urbano revela algumas dificuldades caso não seja utilizada a tecnologia necessária paraa gestão de todos os objectos disseminados pela cidade. Estão em causa razões de eficiên-cia, erros humanos e pouca precisão na localização de cada um dos equipamentos. Tem-secomo exemplo de uma das maiores autarquias do país em que a informação não é georre-ferenciada. As informações existem em documentos digitais do tipo folha de cálculo emque a edição dos diferentes atributos é pouco controlada, e torna o resumo de informaçãopara tomada de decisão pouco prático. Partindo destas necessidades é prioritário criar umsuporte informático que colmate as necessidades básicas desta gestão:

• O que existe?

23

Solução para gestão de equipamentos urbanos

• Onde existe?

• Qual a situação actual?

É preciso ter em conta nesta solução os diferentes intervenientes no processo de gestão(secção 3.2). Para tal é necessário fornecer as funcionalidades necessárias a cada um dosutilizadores para permitir o acesso à informação necessária para a execução do seu ofício.Um dos tipos de utilizadores identificados realizam as suas tarefas no espaço geográficogerido pela autarquia, razão pela qual se promove a utilização de dispositivos móveis eGPS para a interacção com o sistema. Como é comum nos sistemas de informação, osdados são distribuídos electronicamente para cada um dos intervenientes e cabe a cadacategoria de utilizador, determinado(s) tipo(s) de documento(s). No conceito apresentadoa seguir, existem três tipos de utilizadores envolvidos na gestão de equipamentos pro-priamente dito – os fiscais, o departamento de gestão e o departamento de execução – ecompete a cada um deles gerir o tipo de documento de que está encarregado – Tarefas,Pedidos e Processos respectivamente. Os restantes utilizadores apenas têm uma contri-buição para informações extra e gestão do sistema.O sistema a desenvolver permite também a integração do público neste processo. Nesteponto a aplicação aplica o paradigma PPGIS (Public Participation GIS) para permitir ainteracção entre o público e o núcleo central de gestão, contribuindo com informaçõessobre locais onde existe necessidade de acções correctivas por parte da instituição gover-namental. Esta funcionalidade é particularmente importante na medida em que a maiorparte das acções tem como base informações provenientes do público em geral e por di-ferentes métodos de comunicação.O aumento da eficiência das pessoas da instituição passa pela eliminação das tarefas re-petitivas. Desta forma é possível libertar a mão-de-obra disponível para outras funçõesque carecem de atenção humana aumentando desta forma a eficiência e a produtividadede todo o mecanismo de gestão (pessoas e tecnologia).

3.2 Utilizadores

O aspecto funcional de qualquer sistema de informação tem que contar com um dosactivos mais importantes – os activos humanos – são estes que aplicam o seu conheci-mento para que a missão organizacional seja cumprida, neste caso a conformidade dosequipamentos e consequentemente a segurança e satisfação dos habitantes. Considerartodos os níveis hierárquicos do processo de gestão é importante mas não suficiente. Defacto, o conhecimento da situação presente e sempre actualizada é improvável numa áreaque pode ser tão grande como a correspondente a uma cidade, e em que podem estar en-globados dezenas de milhar de equipamentos. Por esse facto a participação dos habitantes

24


é fundamental e estes devem obviamente estar cientes da possibilidade de colaborar coma gestão da zona onde habitam.Antes de passar à descrição dos requisitos é necessário identificar as categorias de uti-lizadores que irão interagir com o sistema, e que tipos de contribuições no sistema sãoesperadas. Faz-se de seguida uma breve análise dos tipos de utilizadores a ter em conta.

3.2.1 Fiscal

Um fiscal verifica o estado de cada um dos equipamentos da cidade in loco mediantetarefas que lhe são atribuídas no espaço geográfico da cidade. A cada tarefa está associadoum equipamento e sobre este podem recair algumas decisões no caso de este não estar emconformidade. Este utilizador permite a actualização das características e inventariaçãodos equipamentos pela sua verificação presencial, contribuindo com georreferenciação detodos aqueles itens.

3.2.2 Departamento de gestão

Cabe aos utilizadores do departamento de gestão a validação dos pedidos criados pelosfiscais e análise das informações enviadas pelo público. A decisão pode ter em contanecessidades específicas, como definição de prioridades e cabimento orçamental. Estedepartamento é responsável pela gestão das actividades dos fiscais e do departamento deexecução através do redireccionamento de informação proveniente de inputs no sistema,quer pelo público em geral quer pelas acções de fiscalização.

3.2.3 Departamento de execução

Esta divisão corresponde aos utilizadores responsáveis pela resolução de problemasidentificados e comunicados pelo departamento de gestão. Corresponde à parte operáriados utilizadores neste modelo de gestão.

3.2.4 Administrador do sistema

Este utilizador é responsável pela configuração do sistema.

3.2.5 Público

O público em geral participa no processo de gestão contribuindo com as localizaçõesgeográficas que necessitam de actuação por parte dos serviços de execução da entidadeautárquica. Associada à localização, este utilizador descreve textualmente o problema.No entanto, e na maioria dos casos essa contribuição é feita utilizando outras formas decomunicação.

25


3.3 Funcionalidades

Nesta secção apontam-se as funcionalidades fundamentais que a aplicação deve pro-videnciar para o funcionamento do processo descrito na secção 3.4. Os requisitos nãofuncionais da aplicação (em 3.3.2) enumera algumas características que o sistema deveoferecer além das funcionalidades previstas.

3.3.1 Requisitos funcionais

Os requisitos apresentados estão descritos de uma forma genérica. Na descrição dis-ponibilizada sobre cada um deles é possível extrair outras funcionalidades que estão as-sociadas. Os requisitos genéricos a contemplar para o desenvolvimento do protótipo sãoos seguintes:

• Autenticação, permissões e autorização — As opções do sistema para cada tipode utilizador estão visíveis após autenticação com sucesso. O sistema verifica paracada pedido se o utilizador tem ou não permissões para aceder ao recurso solicitado.É providenciada a possibilidade de registo de novos utilizadores.

• Gerir perfil de utilizador — Cada utilizador possui informações da instituiçãocomo nome e contactos, a partir dos quais é possível entrar rapidamente em con-tacto. Como é vital que estas informações estejam sempre actualizadas, cada utili-zador pode actualizar o seu perfil em qualquer altura.

• Adicionar cadastros de equipamentos — Um requisito fundamental é a possibili-dade de adicionar novas definições de equipamentos – os cadastros. Estes incluemo nome do equipamento e a definição dos atributos que definem as característicasda categoria do equipamento.

• Gestão de equipamentos — O sistema de informação deve permitir o CRUD dosequipamentos de todos os tipos cadastrados.

• Gestão de documentos — O sistema de informação deve permitir o CRUD dosdocumentos dos quatro tipos descritos a contemplar (Tarefas, Pedidos, Processos eRelatórios). Pode ser necessário visualizar o histórico de processo de um equipa-mento, e por isso essa filtragem deve ter como base esse objecto.

• Gestão de utilizadores — O administrador do sistema tem a possibilidade de auto-rizar ou remover o acesso aos utilizadores registados no sistema bem como alteraro seu nível de acesso.

• Criar pontos de intervenção pública — O público pode participar submetendoinformações georreferenciadas. A parte do departamento de gestão que realiza o

26


atendimento ao público utiliza o mapa disponibilizado para o efeito para realizarpesquisa espacial e utiliza esta ferramenta para criar tarefas e processos.

• Visualizar mapa — A aplicação na sua interface na versão desktop, possui ummapa onde é possível visualizar todos os equipamentos da região. O mapa é porisso um atalho para a pesquisa e selecção de objectos para subsequentes operaçõessobre os mesmos.

• Verificar prazos — O sistema temporariamente verifica se as datas limite de re-alização de tarefas e processos foi ultrapassada, avisando por notificações partesenvolvidas.

• Visualizar resumo de informação — O sistema ao longo do funcionamento vaiacumulando informações úteis para análise e tomada de decisão. Estas podem estarna forma de tabelas, gráficos ou outras.

• Agendar tarefas — Permite a criação de tarefas automaticamente, quer a partir deprocessos dados como concluídos, quer a partir da proximidade de uma próximaverificação.

• Seleccionar tarefa — Os fiscais utilizando o seu dispositivo móvel podem selec-cionar a tarefa a realizar, optando por seleccionar a tarefa mais próxima, ou deixarque a aplicação realize essa selecção.

• Visualizar posição no mapa — Os fiscais devem poder visualizar sobre o mapa asua posição actual ao mesmo tempo que verificam a localização da tarefa seleccio-nada, oferecendo contextualização geográfica relativamente ao objectivo.

• Associar ficheiros — O sistema permite associar fotografias a documentos criadosno decorrer do processo de gestão. Para além desse tipo de ficheiros, pode serútil associar outro tipo de documentos como por exemplo documentos técnicos acategorias de equipamentos.

Para tornar facilitada a pesquisa de informação, a actividade de filtragem deve serpossível em todos os casos em que a quantidade de informação é elevada. As opções defiltragem disponíveis são conforme os atributos associados ao tipo de informação apre-sentada.

3.3.2 Requisitos não funcionais

De seguida são descritos os requisitos suplementares que a aplicação deve ter emconta.

27


• Eficiência — É fundamental que o acesso e tratamento das informações e posteriorvisualização na interface seja feita de forma eficiente.

• Fiabilidade — Dado que o sistema irá ter que suportar a gestão de uma quantidadeelevada de objectos e integrar um determinado número de utilizadores nas suas fun-ções interligados pelo processo, o sistema tem que oferecer uma fiabilidade elevadaoferecendo um alto grau de confiança ao utilizador.

• Portabilidade — A aplicação deve ser apresentada de forma coerente e acessívelnos browsers mais utilizados actualmente. Para além disso, o servidor a desenvolverdeve ser o mais independente possível do sistema operativo utilizado.

• Usabilidade — A interface com o utilizador deve ser simples e de fácil utiliza-ção, apresentando a informação de forma concisa e clara. Todas as opções para asfuncionalidades devem estar perfeitamente visíveis e coerentes em todo o sistema,tornando a utilização o menos cansativa e mais agradável possível.

• Segurança — Como existem diferentes funcionalidades para diferentes tipos deutilizadores, e como a informação a gerir pelo sistema tem uma importância elevada,a segurança neste tipo de aplicação é crucial. Para tal é preciso um correcta definiçãode permissões e autorizações no sistema.

• Disponibilidade — É importante o funcionamento do sistema 24 horas por dia,visto que as informações podem ser criadas e actualizadas em qualquer altura. Ofacto de algumas instituições camarárias terem atendimento ao público durante atotalidade do dia, é mais uma razão para a necessidade do sistema estar disponívelem qualquer momento.

• Manutenção — O sistema deverá ser construído com o mínimo de dependênciasentre os seus módulos, possibilitando no futuro o desenvolvimento de novas funci-onalidades aproveitando os recursos anteriormente já implementados. Desta formagarante-se uma manutenção facilitada, auxiliando a adição, remoção e actualizaçãode funcionalidades de forma simplificada.

3.4 Processo de gestão

O modelo do processo de gestão tem que ter em conta a hierarquia de serviços interna.Num sistema de suporte á decisão existe uma estrutura de topo que utiliza as informaçõesadquiridas pelo sistema para apoio à tomada de decisão. A fonte de tomada de decisãoé constituída neste modelo pela documentação gerada pelo funcionamento do processo,notificações externas do sistema, estatísticas geradas a partir dos dados entre outras possi-bilidades. Geralmente este topo da hierarquia é composto por um conjunto de directores

28


que funcionam como centro de comando e comunicam as suas decisões para os coorde-nadores do nível imediatamente abaixo (figura 3.1).

Figura 3.1: Hierarquia de serviços na gestão de equipamentos

A comunicação entre níveis pode ser realizada por via de documentos que circulaminternamente entre os intervenientes do sistema. Cada um dos intervenientes é responsá-vel pela gestão de um tipo de documento ao qual tem que dar resposta de acordo com asregras de negócio internas.O fluxo de negócio a ter em conta na aplicação encontra-se esquematizado no diagramade fluxo presente na figura 3.2. No topo encontram-se as acções realizadas externamenteao ambiente da organização. Nesta secção incluiem-se os inputs do público em geral aosserviços internos, quer via Web, telefone ou qualquer outro mecanismo de comunicação.No canto superior esquerdo da imagem encontram-se os fiscais responsáveis pela verifi-cação dos equipamentos no terreno. A estes utilizadores encontra-se atribuído um tipode documento denominado Tarefa. Este documento traz associado um determinado equi-pamento que se encontra georreferenciado e sobre o qual a verificação terá que incidir.Neste conceito, após o fiscal ter seleccionado uma Tarefa e ter realizado a análise in locodo equipamento, este utilizador tem duas opções:

• Criar um Relatório de verificação — Este documento permite actualizar o estadoda Tarefa e dá-la como terminada e actualizar a informação sobre a qualidade doequipamento.

• Criar um Pedido — Se no momento da verificação for detectada uma não con-formidade do equipamento, o fiscal cria uma necessidade de acção aos serviços

29


internos. Este Pedido, como veremos adiante é o documento que vai desencadearum fluxo documental entre departamentos.

Figura 3.2: Processo de negócio idealizado para o problema de gestão de equipamentos e mobi-liário

Neste processo existe ainda a possibilidade de o fiscal poder criar pedidos mesmo quenão lhe tenha sido criado uma Tarefa para o equipamento em causa. Tal como no casodo público que submete informações sobre ocorrências aleatórias, o fiscal pode detectarigualmente alguma destas necessidades.No momento em que este sistema iniciar a sua produção, não vão existir quaisquer ele-mentos georreferenciados, a não ser que a instituição já os possua e nesse caso tem quehaver um trabalho de migração de dados. No caso de isso não ser possível, o auditor teráque realizar o levantamento dos equipamentos existentes numa determinada região. Aactividade “Adicionar novo equipamento” oferece o meio para essa necessidade.Relativamente aos serviços internos da organização, neste conceito ficaram definidos duasgrandes divisões departamentais:

30


• Departamento de gestão — Corresponde ao core neste modelo de negócio. Nestadivisão tratam-se todos os inputs de informação para serem correctamente redirec-cionados tendo em vista a resolução de problemas.

• Departamento de execução — Corresponde a um termo genérico. Parte-se doprincípio neste modelo que a resolução de problemas que dizem respeito aos equi-pamentos, é da responsabilidade da instituição e esta possui os meios necessáriospara os resolver. Esta responsabilidade de execução pode no entanto ser repartidapor vários departamentos deste tipo, e neste caso passamos a ter, não um departa-mento de execução, mas vários.

O departamento de gestão gere os inputs de informação tanto dos fiscais como do pú-blico. Este departamento gere um tipo de documento chamado Pedido que correspondeaos pedidos criados directamente pelo fiscal e pedidos criados pelos serviços de atendi-mento ao público. Estes pedidos carecem na maioria dos casos de validação (por motivosde orçamento p.ex.) e sempre que um documento do tipo Pedido é validado é gerado umnovo tipo de documento denominado Processo ou Processo de execução. Este processo édirigido ao(s) departamento(s) de execução. Após determinado processo estar concluído,este é marcado no sistema como tal. A necessidade desta marcação, tal como da con-clusão das tarefas realizadas pelos fiscais é a possibilidade de verificação automática dosprazos de execução e fiscalização. No caso de determinado prazo de execução/fiscaliza-ção não ter sido cumprido o sistema envia alertas para as divisões envolvidas. A criaçãode tarefas é em parte um processo automático que é iniciado pela proximidade da data dapróxima verificação do equipamento. O departamento de gestão pode no caso de um inputdo público querer averiguar quais as condições reais da situação e por essa razão pode sercriada uma Tarefa a partir desse feedback. No caso de a informação ser confirmada existea possiblidadade de criar um Processo directamente.O processo apresentado é constituído por um ciclo Tarefa » Pedido » Processo

sendo apenas dado como terminado quando existir uma submissão de um Relatório deverificação por parte de um fiscal.

3.5 Arquitectura

Para a definição do que irá ser apresentado a seguir foi tido em conta a estruturagenérica da maioria dos sistemas de informação institucionais. Existem recursos queapenas funcionam numa LAN, e outros que são acessíveis a partir de uma WAN (nestecaso a Internet). Neste sistema existe a necessidade de expor determinados serviços parao exterior, para os serviços de fiscalização e serviços de participação pública.O diagrama de arquitectura (figura 3.3) mostra a relação entre cada um dos componentes

31


físicos do sistema e como estão relacionados numa rede de computadores. Neste diagramafaz-se menção à tecnologia a ter em vista na fase de desenvolvimento, embora esta possaser alterada conforme os requisitos da instituição. A aplicação consiste numa arquitecturacliente-servidor comum sendo que o servidor é constituído por três camadas embora acamada de lógica da aplicação possa ser vista como um conjunto de duas – camada demapeamento objecto-relacional e camada de lógica aplicacional. Assim temos:

• Servidor Web — Realiza atendimento aos dispositivos clientes numa rede de com-putadores.

• Camada lógica — Manipula informação adquirida a partir dos utilizadores parainserção na camada de dados, criando e manipulando objectos de fluxo de negócio.Reforça ainda a lógica de negócio implementando uma política de autenticação eautorização.

• Camada de abstracção objecto-relacional — Módulo que cria abstracção que per-mite a criação de objectos na linguagem de programação utilizada e que permitemapear facilmente os atributos de um domínio.

• Camada de dados — Funciona como um repositório centralizado de informaçãoque inclui todos os dados necessários para o funcionamento do sistema de informa-ção.

Qualquer aplicação cliente funciona numa rede e em ambiente Web, uma Intranet nocaso de utilizadores internos (departamentos de gestão e execução) e a Internet no casodos fiscais e público. Os clientes apenas têm a camada de interface. Podemos considerarainda como parte integrante desta arquitectura os servidores de mapas Google que sãoessenciais para esta aplicação.

3.6 Módulos da aplicação

É descrita nesta secção a divisão modular da aplicação e desenvolvem-se as funciona-lidades apresentadas em 3.3.

3.6.1 Autenticação

Para utilizar o sistema os utilizadores devem estar autenticados. Este módulo incluiainda a possibilidade de registo de utilizadores que é feito através de um formulário comas informações necessárias, incluindo o seu tipo se este registo for realizado a partir darede interna. No caso de um registo realizado a partir de uma gama de IPs externos, o

32


Figura 3.3: Diagrama de arquitectura

tipo de utilizador é imediatamente considerado pelo sistema como público. O tipo deutilizador vai definir as autorizações do utilizador no sistema. Como deverá haver con-firmação dos dados do utilizador, este ficará num estado inactivo i.é, sem possibilidadede realizar login até que esteja devidamente aprovado por um administrador do sistema(ver módulo 3.6.2). O utilizador autenticado passa então a ter acesso aos recursos dispo-nibilizados no sistema, sendo que as opções visíveis são adaptadas ao tipo de utilizador(política de autorização) e os recursos pedidos são verificados (política de permissões).

3.6.2 Administração do sistema

A administração deverá incluir a gestão de utilizadores e definição de característicasfísicas e lógicas do sistema. As funcionalidades incluídas neste módulo incluem a possi-bilidade de cada utilizador poder actualizar as suas próprias informações, como númerode telefone, extensão, etc. Como foi descrito atrás, o registo de utilizadores carece deaprovação do mesmo por parte de um administrador do sistema, e por essa razão deve serpossível aceitar/rejeitar os novos registos criados e que surgem numa listagem.A gestão de cadastros de equipamentos é uma das funcionalidades que o sistema tem quenecessariamente suportar. O registo de um cadastro vai mais tarde permitir a gestão de

33


novas categorias de equipamentos. Para a definição de um cadastro é necessário especi-ficar diversos parâmetros como nome e atributos dos equipamentos, definindo o domíniode valores que o atributo pode tomar.

3.6.3 Documentação

Entende-se como um documento qualquer Relatório, Pedido ou Processo criado nodecorrer do fluxo de gestão. A documentação pode incluir ficheiros associados comofotografias que permitem visualizar o estado real do equipamento em determinada alturado seu tempo de vida, documentos técnicos ou outros que se considerem valiosos.

3.6.4 Gestão de equipamentos

Este é o módulo central da aplicação. Todos os outros módulos de alguma forma estãoligados a este. Permite que um callcenter de atendimento ao público e fiscais possam criarPedidos sobre os equipamentos e pontos da cidade. Os utilizadores do departamento degestão podem listar estes Pedidos e criar a partir deles novos Processos de resolução que setornam visíveis na listagem de processos. Esta listagem é disponibilizada ao departamentode execução, sendo possível visualizar por meio de filtragem os itens com maior grau deprioridade. Um processo executado é marcado como terminado pelos utilizadores dodepartamento de execução. Posteriormente cabe ao elemento cron a criação automáticade uma nova tarefa de verificação para o equipamento em causa fazendo continuar o cicloprevisto no fluxo de negócio.Este módulo cria a listagem dos equipamentos existentes a partir da qual e, seleccionandoum equipamento, o utilizador pode verificar o histórico processual do mesmo. Este é oponto de ligação com o módulo descrito em 3.6.3.

3.6.5 Gestão de tarefas

A criação de uma Tarefa associa um fiscal, um equipamento e uma data limite paraa concretização da acção. O fiscal através do seu equipamento móvel, pode actualizar elistar as tarefas que tem a realizar. A concretização de uma tarefa, tanto por criação deum Pedido ou por submissão de um Relatório de verificação permite actualizar automa-ticamente o estado da tarefa, sendo dada como realizada. Para o equipamento associadoà tarefa realizada, é gerada uma nova data de verificação com base num número de diaspredefinido.

3.6.6 Mapa

Pretende-se que o componente Mapa seja a porta de entrada para a aplicação de ges-tão. A partir deste é possível realizar pesquisa e selecção de equipamentos existindo sobre

34


cada um, atalhos sobre acções a realizar sobre eles. Associado a este componente deveexistir um filtro que permita visualizar apenas os objectos pretendidos.O mapa Web vai permitir que um fiscal visualize a sua posição geográfica bem comoa localização das tarefas que tem a realizar. A selecção de um objecto (simbolizandoum equipamento) sobre este componente, permite que o utilizador o manipule de formaa interagir com o módulo de gestão de equipamentos ( 3.6.4) seleccionando as opçõesprevistas - criação de pedido e submissão de relatório. Pode-se considerar a pesquisa eselecção dos equipamentos descrito em 3.6.4 um processo alternativo ao mapa. A utili-zação do mapa para o mesmo efeito permite uma outra visão alternativa sobre o mesmoconjunto de dados, permitindo chegar ao mesmo objecto e suas opções de forma maisprática e intuitiva.É este o módulo responsável pelo tratamento dos dados para visualização que apenas érelevante no caso da aplicação desktop já que, no caso de uma aplicação móvel, o fiscalapenas possui sobre o mapa o ponto da sua tarefa actual seleccionada e a própria posição.As abordagens a tomar irão variar conforme os diferentes níveis de zoom e têm em contaalgumas das ideias captadas durante a revisão bibliográfica (capítulo 2).

3.6.7 Visualização estatística

O sistema a ser desenvolvido acumula com o tempo informações que podem ser uti-lizadas para análise e suporte à tomada de decisão. Este módulo pode ter em vista todaa área geográfica da cidade bem como somente as regiões administrativas, sendo nesteúltimo caso apenas útil de um ponto de vista político. A acção do utilizador baseia-se naselecção de regras de resumo de informação para apresentação gráfica (tabelas, gráficos,cores sobre o mapa entre outros).

3.7 Modelo de dados

O esquema relacional de dados foi criado tendo como base o conceito exposto atrás eem alguns ficheiros no formato excel obtidos no início do projecto contendo o cadastro dealguns equipamentos. Estes ficheiros contêm alguns atributos que dizem respeito a cadaum dos equipamentos geridos pela CMP, juntando-se os atributos partilhados de formaa criar uma superclasse para todos os tipos de equipamentos - tabela equipment. Omodelo de dados resultante é apresentado na figura 3.4.

As tabelas do esquema de dados providenciam suporte para guardar as informaçõesnecessárias ao funcionamento da aplicação e pretendem satisfazer os requisitos. A finali-dade das tabelas descreve-se da seguinte forma:

35


Figura 3.4: Modelo de dados

• equipment — Contém os atributos comuns a todos os equipamentos, funcionandocomo a superclasse para uma estrutura de herança

• user — Os utilizadores do sistema, identificados pelo seu tipo, contactos e creden-ciais.

• document — Contém todos os tipos de documentos identificados no processo denegócio descrito anteriormente. O tipo de documento é identificado por uma ta-bela de domínio e a estrutura desta tabela contém os atributos de todos os tipos dedocumentos numa herança com tabela única.

• meta — Guarda referências (URL) para ficheiros, como imagens, documentos téc-nicos e outros que possam ter interesse, e que dizem respeito a um equipamentonuma determinada altura ou a uma determinada classe de equipamentos.

36


• equipment_catalog - Permite fazer a gestão e referenciar novos cadastros de equi-pamentos. Esta tabela contém os nomes das tabelas criadas em tempo de execuçãona definição de novos tipos de equipamentos. Cada entrada contém o URL para oícone que representa o equipamento no mapa. Um aspecto importante é o atributotable_schema que contém todas as informações sobre a definição do cadastro econtém a definição da tabela criada para o mesmo no formato XML.

• public_point — Contém os pontos georreferenciados submetidos pelo público emgeral.

• public_comment — Comentários textuais colocados pelo público sobre cada umdos pontos contidos na tabela public_point.

As restantes tabelas existentes no modelo de dados (a cinza) dizem respeito a tabelasde domínio para alguns dos atributos contidos nas tabelas a que têm associação.

3.8 Resumo

Neste capítulo foi apresentado o problema e conceptualizada uma abordagem para asua resolução tecnológica utilizando georreferenciação. Os tipos de utilizadores reflectema estrutura da organização que se encontra envolvida na gestão dos equipamentos onde opúblico tem que ser visto como um actor importante.O modelo de dados apresentado foi desenvolvido com base em informações oficiais, noque diz respeito aos atributos dos equipamentos. As restantes tabelas da relação permitema integração dos requisitos de informação necessários para o funcionamento da soluçãono domínio para o qual será desenvolvido.

37


38

Capítulo 4

Implementação e análise

No capítulo anterior foi especificada uma arquitectura de alto nível para a plataformade gestão a desenvolver. O presente capítulo, descreve com detalhe os pormenores maisimportantes da implementação do protótipo.Este capítulo foi estruturado em três partes distintas para organizar a informação contidae tornar a leitura mais estruturada.

• 4.1 Processo de gestão — Funcionalidades que descrevem o funcionamento do pro-cesso de gestão. Está relacionado com o fluxo de negócio do conceito da aplicaçãoapresentado no capítulo anterior.

• 4.2 Visualização — Descreve as características do tratamento de informação paravisualização sobre o mapa. Aborda conceitos verificados no estado da arte (capí-tulo 2).

• 4.3 Aplicação móvel — Descreve os princípios básicos e as funcionalidades desen-volvidas em torno das actividades de fiscalização.

Cada uma destas secções contém algumas análises realizadas sobre o que foi desen-volvido, e em jeito de autocrítica sugerem-se ideias para possíveis melhorias.Para finalizar este capítulo, realiza-se uma síntese do seu conteúdo realçando os aspectosconsiderados mais importantes neste desenvolvimento.

4.1 Processo de gestão

Para implementar correctamente o processo de negócio é necessário relacionar cadaum dos intervenientes da aplicação com o tipo de documentação que é atribuída a cada um

39


deles, bem como qual o documento produzido em função da sua actividade. Esta secçãoexplica a ideologia deste protótipo tendo em vista a integração no sistema de informaçãotodas as classes de utilizadores e os seus objectivos.

4.1.1 Entidades e documentos

Os fiscais realizam a sua actividade mediante tarefas que lhes estão atribuídas, querpelos intervenientes humanos da gestão, quer pelo módulo de automação. Estas tarefassão representadas na forma de um documento específico – Tarefa. No ciclo processualdeste modelo, uma tarefa produz um novo documento – um Pedido – que é dirigido àsecção de gestão. Os Pedidos podem ser também criados internamente para formalizare dar suporte a processos a serem criados. Os tipos de pedidos suportados pelo sistemamediante opções na interface são:

• Colocação — Colocação de um equipamento num ponto específico no espaço geo-gráfico;

• Reparação — Assistência correctiva sobre um equipamento/ponto público;

• Remoção — Levantamento de um equipamento existente;

• Movimentação — Alteração do ponto geográfico de um equipamento;

Os indivíduos do departamento de gestão, mediante regras de negócio previamenteconcebidas pelos decisores (superiores hierárquicos) ou decisão instantânea (no caso denenhuma regra se aplicar) podem ou não dar seguimento ao pedido. Para ajudar este pro-cesso de decisão, cada um dos documentos possui um nível de prioridade – enumeradosna tabela document_priority – que permite determinar o grau de relevância a dar aodocumento em causa. A confirmação de um pedido permite a criação de um documentodo tipo Processo dirigido ao departamento de execução.Este fluxo inclui um motor de fluxo (workflow engine em inglês) representado pelo mó-dulo de automação da aplicação apresentado já a seguir nesta secção. Este módulo fazutilização das datas de expiração presentes nos documentos dos tipos Tarefa e Processopara gerar alertas (p.ex. e-mails) dirigidos aos intervenientes envolvidos. A acção desteprocesso concorrente no servidor, permite facilitar o fluxo de informação libertando agestão de actividades supérfluas, neste caso a criação de documentos do tipo Tarefa. Afigura 4.1 esquematiza este fluxo de documentação entre intervenientes.

O caso das entradas de informação provenientes do público é um assunto especial aser discutido já que estas podem dar entrada de diferentes formas para além da parte daaplicação que tem em conta este input. Em princípio os casos mais urgentes relatados

40


Figura 4.1: Fluxo de documentação entre entidades

pelo público serão comunicados via telefone. O problema que tem a ver com a instituiçãoé o redireccionamento destes telefonemas para o serviço correcto do departamento degestão. O mapa de domínio público pode ser utizado para definir a zona de intervenção aser marcada como destino dos funcionários de fiscalização ou de execução. A partir dessemomento o departamento de gestão pode ter uma de duas hipóteses:

• Criar uma tarefa — Permite averiguar o estado real da situação relatada pelo enviode um fiscal;

• Criar um processo — Permite agir de imediato, embora em situações de real emer-gência, pode ser necessário o reforço da mensagem por via telefónica ou presencial;

A política de autorização existente no sistema vai permitir que cada tipo de utilizadortenha acesso ao tipo de documentos de que estão responsáveis de gerir. No caso especí-fico dos utilizadores do departamento de gestão e administração, estes têm acesso a todaa documentação e informação existente no sistema, de forma a poderem actualizar as in-formações de acordo com as necessidades. As permissões sobre o sistema são verificadasmediante variáveis de sessão criadas no momento de autenticação.Os mapas da aplicação disponibilizados nos serviços internos servem como meio para acriação de tarefas e processos. No caso da criação directa de um processo a partir de umobjecto sobre o mapa geral ( 4.2) ou público, é criado um documento Pedido antes dacriação do Processo. Desta forma fica especificado qual o tipo de necessidade de acordocom os tipos de pedidos existentes no sistema. É o primeiro Pedido de um ciclo proces-sual, que vai definir no final as modificações a efectuar nas informações presentes na basede dados.

41


4.1.1.1 Automação do processo

Em sistemas baseados em Unix existe já por defeito uma aplicação para definir coman-dos a serem executados periodicamente. Este processo activo denominado cron permiteainda criar logs das operações realizadas oferecendo algum controlo sobre o seu funcio-namento. Foi implementado um novo controlo na aplicação e neste algumas acções querespondem a pedidos GET. As verificações podem ser todas feitas de uma vez, embora naimplementação e para ter algum controlo sobre as acções realizadas, optou-se por separarcada uma das verificações. Utilizando o cron e programando a chamada ao executávelwget (também das distribuições UNIX), utiliza-se o URL das acções do servidor a seremchamadas. As duas verificações realizadas são:

• Verificação do estado de execução de processos

• Verificação da proximidade da data de verificação dos equipamentos

Em ambos os casos é criado um novo documento Tarefa associado a um determinadofiscal. A selecção do fiscal é no momento, seleccionado com base num algoritmo ganan-cioso i.é, selecciona o que tiver menos tarefas atribuídas naquele instante.A verificação das datas limites de execução de tarefas e processos é realizada em back-ground pelas páginas dos utilizadores. Existe uma chamada definida com setTimeout

em javascript que realiza um pedido AJAX ao servidor. A notificação surge então sobre ainterface, numa div flutuante contendo o texto que traduz a informação ao utilizador.

Figura 4.2: Exemplo de notificação ao utilizador sobre a interface

4.1.2 Gestão de utilizadores

Os utilizadores da instituição criam um pré-registo que tem que ser aprovado. Osestados possíveis dos utilizadores estão inseridos logo desde o início do funcionamentoda aplicação na tabela user_state. Para além de algumas informações básicas comocontactos, este deve seleccionar o tipo de utilizador no sistema. Numa situação real em

42


que parte do sistema é disponibilizado ao domínio público, seria necessário existir a pos-sibilidade de registo deste tipo de utilizador – o que não foi realizado nesta fase. Nestecaso deveria existir um domínio de registo público e outro interno baseando-se na classede IP da máquina cliente.Permite-se que a criação de utilizadores seja feita pelos administradores do sistema. Aeliminação de utilizadores (e outros elementos da base de dados) é feita utilizando o mé-todo de lazy delete. Desta forma evitam-se conflitos na base de dados por violação deintegridade referencial.

4.1.3 Gestão de cadastros de equipamentos

A criação de novos cadastros de equipamentos é realizada mediante um formulário di-nâmico. O utilizador pode inserir novos atributos ao equipamento a criar. A cada campoestá associado o tipo de dados a ser atribuído, sendo que nesta fase de desenvolvimentoforam permitidos os tipos string, float, booleano, data, texto e um tipo definido pelo uti-lizador que consiste de uma enumeração de valores possíveis. Obviamente este tipo deoperação deve ser feita por alguém previamente treinado para a utilização de mais baixonível da aplicação, alguém com conhecimento técnico do funcionamento do sistema. Paraalém destes campos, uma checkbox serve para indicar se o campo é ou não obrigatório.No fundo a interface assemelha-se a um cliente Web de bases de dados, e foi dessas apli-cações que surgiu a inspiração. Para além destes campos a interface permite seleccionaro ícone gráfico representativo do equipamento.A submissão do conteúdo do formulário implica o processamento no servidor de formaa validar e tratar o nome da tabela e dos seus atributos e finalmente criar a nova tabelana base de dados. Após a criação com sucesso da nova tabela na base de dados, é cri-ado um novo registo na tabela equipment_catalog. Nesta tabela são mantidos noformato relacional alguns aspectos mais requisitados sobre o equipamento, como o nomeque define o equipamento, um nome curto utilizado para efeitos de scripting javascript(utilização exemplificada adiante em 4.2) e o URL do ícone representativo. O total dainformação sobre o cadastro do equipamento e as definições da tabela do equipamentoespecífico fica contido num documento XML no atributo table_schema. Um exemplodeste documento XML é como o apresentado a seguir:

<?xml v e r s i o n =" 1 . 0 " e n c o d i n g ="UTF−8" ?><equipment >

<equipment_name > S i n a l i z a c a o v e r t i c a l luminosa < / equipment_name ><shor t_name >SVL</ shor t_name >< tab le_name > s i n a l i z a c a o _ v e r t i c a l _ l u m i n o s a < / tab le_name ><icon > images / map−i c o n s / a d m i n i s t r a t i o n . png </ icon ><columns ><column knownname=" A t r i b u t o i n t e i r o " columnname=" a t r i b u t o _ i n t e i r o "

d a t a t y p e =" i n t e g e r " a l l o w n u l l =" t r u e " / >

43


<column knownname=" A t r i b u t o f l o a t " columnname=" a t r i b u t o _ f l o a t "d a t a t y p e =" f l o a t " a l l o w n u l l =" t r u e " / >

<column knownname=" A t r i b u t o s t r i n g " columnname=" a t r i b u t o _ s t r i n g "d a t a t y p e =" s t r i n g " a l l o w n u l l =" t r u e " / >

<column knownname=" A t r i b u t o b o o l e a n o " columnname=" a t r i b u t o _ b o o l e a n o "d a t a t y p e =" b o o l e a n " a l l o w n u l l =" t r u e " / >

<column knownname=" A t r i b u t o d a t a " columnname=" a t r i b u t o _ d a t a "d a t a t y p e =" d a t e " a l l o w n u l l =" f a l s e " / >

<column knownname=" A t r i b u t o t e x t o " columnname=" a t r i b u t o _ t e x t o "d a t a t y p e =" t e x t " a l l o w n u l l =" f a l s e " / >

<column knownname=" A t r i b u t o l i s t a " columnname=" a t r i b u t o _ l i s t a "d a t a t y p e =" u s e r _ d e f i n e d " a l l o w n u l l =" f a l s e ">< o p t i o n >opt1 < / o p t i o n >< o p t i o n >opt2 < / o p t i o n >. . .

</ column ></ columns >

</ equipment >

No momento em que é solicitada informação sobre um determinado equipamento paraeditar as suas informações específicas, é realizado parse deste documento XML com abiblioteca REXML incluída por defeito na distribuição de Ruby. [23]A figura 4.3 mostra a interface de criação de cadastros.

Figura 4.3: Interface de criação de cadastros

4.1.4 Participação pública

A ideia para o desenvolvimento desta parte da aplicação tem como base de inspira-ção um projecto concluído pelo INESC-Porto em 2005 que associa um mapa Web a um

44


fórum de discussão pública. A aplicação permite aos utilizadores, habitantes do con-celho de Águeda, debater na Internet o plano rodoviário. [24] Nesta parte da aplicaçãopretendeu-se utilizar o conceito de PPGIS (Public Participation GIS). A noção de PPGISrelaciona-se com o uso de tecnologia GIS para envolver o público em geral na produçãode conhecimento para auxiliar à avaliação e gestão dos processos. Como já está estabe-lecido, a informação fornecida pela população local um veículo de peso no processo degestão. Uma das dificuldades que pode surgir a partir dos contactos realizados pelos ha-bitantes é a definição de “lugar” quer por dificuldade de localização quer por dificuldadede expressão. A utilização do mapa Web, associado ao que foi definido pode em parteajudar nesta definição do local.Associou-se um mapa a uma espécie de feed como se passa a explicar e está visível nafigura 4.4.

Figura 4.4: Interface de participação pública

O público tem acesso a uma página Web com o mapa da cidade e comentários co-locados por outros utilizadores. Estes comentários estão associados a pontos no mapa,onde os habitantes submetem informações sobre as necessidades e problemas que encon-tram. A navegação no mapa permite verificar se já existe o ponto para o qual se pretendecontribuir com informação, e existindo, se já contém alguma reclamação/sugestão. Nãoexistindo, o utilizador indica o ponto geográfico da cidade e adiciona um texto explicativoque pretende associar ao ponto. Se verificar que o comentário existente para um ponto emquestão não é suficientemente esclarecedora pode então adicionar um novo comentário. Aselecção de um ponto sobre o mapa cria no cliente um pedido AJAX dirigido ao servidor,enviando o id do ponto para obter a listagem de comentários realizados para este.O departamento de gestão utiliza estas informações georreferenciadas para avaliar com

45


mais precisão a situação do problema, para desta forma poderem definir a estratégia atomar. A fase inicial do atendimento de um ponto é actualizado como tal. A finalizaçãodo atendimento de um destes pontos faz com que este seja removido da lista de pontossubmetidos pelo público deixando de surgir sobre o mapa.

4.1.5 Análise e possíveis melhorias

Embora não tenha sido possível obter que tipo de informações são necessárias paradar apoio à decisão ao nível estratégico da gestão, emergem algumas ideias possíveis. Oexemplo dado exige mais alguns campos na base de dados salientando os custos associ-ados às acções realizadas sobre os equipamentos. Usando técnicas de data mining seriapossível saber que zonas ou equipamentos têm sido mais afectados por acções correctivas.A acumulação destas acções ao longo do tempo acarretam custos financeiros, que no finalde determinado período pode ultrapassar o custo da substituição. É possível também acaracterização regional dos custos e acções para prever antecipadamente custos a ter emconta nos orçamentos anuais previstos.As notificações via interface nitidamente são insuficientes. Outros tipos de notificaçõesmais eficazes podem incluir e-mails para os grupos de gestão de cada departamento, SMSdirigido aos fiscais e provavelmente outras vias.

4.2 Visualização sobre o mapa

Esta secção aborda a forma de implementação do tratamento e apresentação da infor-mação sobre o mapa Web. A implementação tem em conta noções abordadas no levanta-mento bibliográfico (capítulo 2).

4.2.1 Server-side vs Client-side clustering

Um problema que se colocou e tido em conta no desenvolvimento é se o processa-mento de informação haveria de ser feito no servidor ou no lado do cliente. É possívelrealizar este processamento no lado do cliente até algumas centenas de pontos com umbaixo atraso de resposta. No entanto, a partir de um determinado ponto a dinâmica da in-terface vai-se deteriorar e a utilização da aplicação pode frustrar o utilizador pelo bloqueiodo navegador Web. No caso do script nos bastidores da aplicação cliente estar a demorardemasiado tempo a processar, é comum surgirem mensagens como a exemplificada nafigura 4.5.

Visto que o número de pontos pode atingir uma centena de milhar de equipamentostorna-se impossível submeter o cliente a este volume de processamento, e devido também

46


Figura 4.5: Notificação de script prolongado

ao custo de envio de dados pela rede associada. Para além destes aspectos fica mais baratoem relação à variável tempo ser o servidor a processar grandes quantidades de informa-ção, já que esta é idealmente uma máquina apropriada e bem mais poderosa no que dizrespeito à capacidade de processamento.

4.2.2 Minimização da quantidade de informação transferida

Outro problema que pode ser relevante é o volume de transferência de dados. A comu-nicação entre o servidor e cliente seria baseado no envio de grandes quantidades de dados,o que se pode revelar problemático se a instituição tiver um débito de rede baixo. O su-cesso das aplicações interactivas na Web e em particular as baseadas em mapas, consistenos pedidos realizados em background (AJAX) ao servidor sem refrescamento da página.Os componentes da página Web são actualizados automaticamente mediante a acção doutilizador. No caso de estes pedidos serem muito frequentes, a quantidade de informaçãoa processar incrementa numa proporção onde a quantidade de dados (KB) a processar temum peso relevante. Mais pedidos significa mais tráfego e consequentemente uma respostamais lenta a não ser que se invista em hardware mais capaz para suportar um tal volumede processamento. Para evitar estes investimentos, existem opções viáveis para resumira quantidade de informação a processar. O conteúdo da resposta do servidor pode serbaseado em HTML, JavaScript, XML e JSON. No caso de se querer obter novos pontos acolocar sobre o mapa, as 3 últimas opções parecem ser viáveis. No entanto se quisermosenviar apenas a mínima informação possível, resumida ao essencial a resposta à discussãopode ser demonstrada como exposto a seguir.

47


Se tivermos um conjunto de n pontos a colocar sobre o mapa, a mesma informaçãoem JavaScript, XML e JSON, tendo em conta 5 casas decimais para a localização, érepresentada por:

Tabela 4.1: Resposta JavaScript

nr caracteresnew google.maps.Marker(map:map,new google.maps.GLatLng(1.23456,1.23456)) 74 * n

Tabela 4.2: Resposta XML

nr caracteres<pts> 5<p><lat>1.23456</lat><lng>1.23456</lng></p> 43 x n</pts> 6

Tabela 4.3: Resposta JSON

nr caracteres{pts:{ 6p001:{lat:1.23456,lng:1.23456} 30 x n}} 2

O volume de dados enviado varia de forma muito distinta entre os três formatos dedados, como se pode verificar no gráfico 4.6 que evidencia a diferença nesse volumeentre 1 pontos e 300 pontos a visualizar.

Figura 4.6: Comparação do volume de resposta do servidor usando JavaScript, XML e JSON

Nitidamente para este efeito a utilização de objectos JSON é a melhor aposta. Se umpedido ao servidor resultar numa resposta que inclui 300 pontos, termos um conjunto dedados com menos 13000 caracteres, o equivalente a uma redução de 13 KB em relação àresposta JavaScript. A única desvantagem é a menor legibilidade, mas não é intenção darao utilizador a possibilidade de interpretar estes fluxos de dados. A redução da quantidade

48


de dados atribuída às variáveis permite igualmente uma maior rapidez no processamentoe consequentemente no tempo de resposta e actualização da aplicação. Se tivermos emconta que o envio de informação por parte do servidor não consiste somente na localizaçãode pontos, mas também outros dados, podemos chegar à conclusão que estas diferençaspodem-se tornar mais notórias.

4.2.3 Comunicação cliente-servidor

A actualização dos dados sobre o mapa tem sempre em vista o estado actual destecomponente e dos seus filtros. O processo de comunicação é iniciado quando existe umaacção de arrastamento, zoom ou acção num dos filtros. A aplicação no cliente iniciaentão um processo assíncrono de comunicação, enviando alguns parâmetros a serem uti-lizados pelo servidor para selecção e processamento dos dados. Os parâmetros enviadosao servidor num pedido GET são:

• zoom — nível de zoom actual do mapa

• SW — a latitude e longitude mínimas no estado actual da viewport do mapa

• NE — a latitude e longitude máximas no estado actual da viewport do mapa

• categorias — lista com as categorias seleccionadas no filtro de equipamentos

As coordenadas definidas pelos pontos SW e NE vão definir a região delimitadora domapa (ou bounding box). Esta região é utilizada para realizar a selecção de pontos da basede dados georreferenciada utilizando uma função específica descrita mais adiante, e tendoem conta a lista de equipamentos a ser visualizada sobre o mapa. No caso de o nível dezoom ser inferior a um determinado valor, que na situação implementada ficou fixado novalor 13, o servidor não retorna quaisquer pontos. Tomou-se esta medida, porque nestasituação o servidor iria seleccionar todos os equipamentos da base de dados, e no casodesta possuir algumas dezenas de milhar de equipamentos o que iria saturar o servidor,principalmente numa situação em que existissem vários clientes a realizar o mesmo tipode pedido. A parte lógica da aplicação trata então da criação de clusters e arranjo dainformação para enviar no formato JSON ao cliente (figura 4.7).

A solução de [2] consiste na criação da iconografia no servidor. Na framework utili-zada neste projecto - Ruby on Rails - tal também seria possível realizar utilizando o pluginmini-magick. [25]Tendo em conta que o cliente que realiza o pedido de vários pontos sobre o mapa é umamáquina mais poderosa que um equipamento móvel, e tendo em conta que a densidadede pontos pode atingir valores muito elevados, tomou-se a decisão de deixar essa tarefaa cargo do cliente. A fase de tratamento de dados prevê essa situação de forma a libertar

49


Figura 4.7: Comunicação cliente-servidor e estágios de processamento

o cliente de alguns esforços de processamento extra, como determinar a quantidade deaglomerados na resposta e o cálculo do número de equipamentos em cada um dos aglo-merados criados. Uma razão adicional para o cliente ficar encarregue do processamentovisual dos clusters é que a API Google Maps oferece a possibilidade de criar camadaspersonalizadas, evitando carregar para cada aglomerado um ícone específico, principal-mente tendo em conta a utilização da cache do navegador Web no cliente.

4.2.4 Fase de selecção e criação de clusters

A selecção de pontos da base de dados é condicionada pelas dados enviados pelocliente como é exemplificado por:

ne =41.20 ,−8.507&sw=41.129 ,−8.75& t y p e s =SVL ; SEP ;EQNP;& z =13

onde ne/sw são os pontos que definem a bounding box, types são os tipos de equipa-mentos a visualizar sobre a interface (seleccionados pelo filtro existente – figura 4.8) e zcorresponde ao nível actual de zoom.

A selecção é então feita pela criação de um objecto geométrico – um polígono – de-finido pelas latitudes e longitudes máximas e mínimas. A biblioteca GeoRuby fornecea possibilidade de gerar um polígono utilizando a classe Polygon. Esta classe possuio método estático from_coordinates que permite criar um polígono a partir de umconjunto de coordenadas e que é utilizada para o efeito. A interrogação à base de dadosutiliza este polígono para determinar quais os pontos que estão incluídos dentro deste po-lígono. Este resultado é conseguido com recurso à função ST_CONTAINS do PostGIS. Acapacidade de mapeamento objecto-relacional da framework Ruby on Rails, permite quetodos os atributos estejam acessíveis a partir de cada um dos objectos da lista de resulta-dos.

50


Figura 4.8: Filtro de selecção de equipamentos no mapa

Teve-se em conta para esta fase do processamento do pedido do cliente a metodologiaexposta em [26, capítulo 7]. O capítulo deste livro utiliza uma abordagem simples de cri-ação de clusters pela criação de uma matriz sobre as coordenadas SW e NE indicadas pelocliente. O método consiste em dividir a região visualizada num número fixo de células(30) estando associado ao algoritmo um valor máximo de ícones sobre o mapa. O mé-todo contém um ciclo while que termina quando o tal valor máximo não é ultrapassado.Foram notados alguns inconvenientes no método:

• Ordem de complexidade temporal elevada - No caso de existir uma densidadegrande de equipamentos na região, e tendo em conta que esta região é dividida numamatriz com 30x30 células, o ciclo pode ocorrer diversas vezes. Apenas no caso dea densidade de pontos não ser elevada, temos na melhor das hipóteses uma ordemde crescimento O(n) e isto sem contar com processamentos subsequentes como oincluído nesta implementação. Neste caso a ordem temporal seria na melhor dashipóteses O(n2).

• Efeito surpresa no arrastamento - Este efeito surpresa é um acontecimento quepode confundir o utilizador. Sendo que a região é dividida numa matriz definidapelos pontos SW e NE, as células não vão ter posições e dimensões constantes.Acontece que o arrastamento provoca uma alteração brusca no posicionamento dospontos sobre o mapa.

• Concentração de pontos em limites da região - Se existir uma densidade de pontossomente num dos lados da viewport do mapa, e como a subdivisão da região começapor dividir as diferenças de latitudes/longitudes no valor 30, a quantidade de íconessobre o mapa é muito elevado e o efeito pretendido de aliviar a carga de informaçãosobre o mapa não é de todo alcançado.

51


Utilizou-se na implementação a criação de uma matriz fixa a coordenadas geográficasconforme o nível de zoom do mapa. Foram criadas duas estruturas de dados que indi-cam os valores utilizados neste processo segundo diferentes níveis de zoom. A primeiraestrutura (bounding_box_round_level) indica a quantidade de número de casas de-cimais a que os valores SW e NE devem ser arredondados. Com zoom_coords_steps

passamos a ter um valor para cálculo dos limites de cada uma das células da matriz agerar, que corresponde ao valor a adicionar ao valor base determinado pelo arredonda-mento anterior. Cada um dos valores anteriores - casas decimais de arredondamento eincremento - foram definidos por tentativas tendo em vista a separação gráfica dos íconesa serem contidos em cada célula. Após a obtenção dos pontos é criada uma nova estruturade dados tal como definido em [26]. Associa-se a cada célula da matriz os equipamentosincluídos na generalização.Com o resultado desta iteração sobre o conjunto de dados, passa a ter-se um conjunto depontos associado a uma célula da matriz. O passo seguinte é o processamento de infor-mação num formato pré-definido a ser enviado ao cliente.

4.2.5 Fase de tratamento da informação

A estrutura de dados resultante da fase anterior é reprocessada para determinar aglo-merados e conter apenas a informação essencial na resposta, visto que no momento emque termina a fase anterior, a estrutura contém objectos “Equipamento”. O conteúdo dahash criada anteriormente tem o seguinte aspecto:

{ " xa_yb " : [ equip_1 , equip_2 , . . . equ ip_x ] , . . . }

Esta fase tem como objectivo o envio do id do equipamento e do seu tipo, e determinarse é um ícone isolado ou um aglomerado e no último caso qual a quantidade de categoriasrepresentada. Aproveita-se a iteração adjacente para calcular a média da posição dospontos incluídos no aglomerado a ser usado na colocação do ícone representativo sobre omapa.Todos os ícones são colocados numa mesma frase de resposta:

[ { " c " : " 1 " , " i n f o " : { "MOB" : 1 , "COMM" : 1 , "TX" : 1 , " c o u n t " : 3 , " pos " : { " l a t " : 4 1 . 1 2 3 4 , " l n g ": −8 .1234}}} ,{ " c " : " 0 " , " t y p e " : "SH" , " pos " : { " l a t " : " 41 .2345 " , " l n g " : " −8.2345 " } , "o i d " : 4 1 0 6 } ]

O exemplo em cima mostra os dois casos distintos. Um ponto é um equipamentoindividual (c=0) e outro é um aglomerado (c=1). No primeiro caso é enviado o id doequipamento na base de dados juntamente com o seu tipo e coordenadas. No caso docluster é enviada a quantidade de categorias incluídas (count) já que não existe possi-bilidade de saber o comprimento do conjunto de dados numa string JSON em javascript

52


(falta a função length ou semelhante), e por essa razão aproveita-se a iteração dos da-dos no lado do servidor para criar esta variável. A contagem de pontos incluídos numacategoria é enviada e associada à sua abreviatura no sistema.

4.2.6 Processamento no cliente

O primeiro passo na recepção da resposta é verificar o tipo de ponto a criar, um íconeindividual ou um aglomerado. No primeiro caso, a chamada à função

a d d M a r k e r O v e r l a y _ S i n g l e ( id , type , p o s i t i o n )

coloca o ícone sobre o mapa, tal como definido na API do [27] Maps. Caso contrário amanipulação do conjunto de dados e colocação da camada sobre o mapa é manipuladapor

a d d M a r k e r O v e r l a y _ C l u s t e r ( i t e m _ i n f o )

A colocação de um aglomerado sobre o mapa vai ser influenciado por algumas variá-veis como, nível actual de zoom do mapa e contagem de categorias do aglomerado. Paragerir a criação de cada um dos tipos de representações generalistas desenvolvidas (tipifi-cação homogénea, tipificação heterogénea e deslocamento) utilizou-se a possibilidade dedesenvolvimento de classes para representar objectos em JavaScript com a utilização deprototype. Desta forma é possível encapsular funções e variáveis para se tornar facilitadaa manipulação do estado dos objectos criados. O código desenvolvido para cada um dostrês tipos de classes de generalização está presente no anexo B.A implementação das tipificações teve como base prática o exemplo existente na do-cumentação da API da versão 3 do [27] Maps que consiste em criar uma subclasse deOverlayView da API. Esta foi a forma de manipular o conteúdo de um elemento div

da DOM do documento HTML alocando facilmente a uma posição geográfica.Se a informação do item passada à função inclui apenas uma categoria, é criado um ob-jecto do tipo SingleIconClusterOverlay que define a estrutura para uma tipificaçãohomogénea. O resultado pode ser visualizado na figura 4.9.No caso do número de categorias de um aglomerado ser superior a 1 é utilizada a tipifica-ção heterogénea cuja representação gráfica é realizada pela classe MultipleIcon-ClusterOverlay. Nesta fase torna-se necessário que cada ícone representativo de umacategoria tenha o seu equivalente num tamanho reduzido, utilizado nesta representação.O construtor do objecto recebe um array com os ícones das categorias incluídas no aglo-merado. Para não sobrecarregar a visualização optou-se por limitar a quantidade de cate-gorias às primeiras seis. Quando o número de categorias ultrapassa este valor, é colocadoum ícone “reticências” para representar essa ocorrência (ver figura 4.10). Esta ideia sur-giu pela leitura do trabalho de [2].

53


Figura 4.9: Tipificação homogénea desenvolvida

Figura 4.10: Tipificação heterogénea desenvolvida com 2, 4, 6 e 6+ categorias

Quando no último nível de zoom não é possível ter uma distinção de pontos no mapapela proximidade entre eles, é utilizado o operador de deslocamento. A criação e efeitovisual deste operador foi implementada na classe DisplacementManager. A região deafastamento é representada por um círculo translúcido sobre o mapa. Esta circunferênciaavisa o utilizador que naquele espaço existe um conjunto de pontos onde pode realizaraquela operação (ver figura 4.15). O afastamento é iniciado pela acção do utilizador nobotão direito do rato e os ícones voltam às suas posições originais quando o ponteiro dorato sai da região circular. Para ajudar o utilizador na selecção do ícone, o z-index doícone sobre o qual o ponteiro do rato está posicionado, é incrementado.

Figura 4.11: Operador de deslocamento desenvolvido

4.2.7 Integração com Google Street View

A terceira versão da API do Google Maps disponibilizou recentemente a possibilidadede utilizar a vista Street View. Na aplicação desenvolvida a cada marker apresentado sobreo mapa é guardado o id do equipamento que representa. Registou-se um evento sobre a

54


acção de click sobre cada um dos ícones presentes no mapa. Sempre que é pressionado umícone, é criado no servidor um pedido AJAX para obter opções e informações mínimassobre o objecto. A resposta do servidor contém markup HTML para ser incluído no balão(InfoWindow) a visualizar sobre o equipamento. Por uma questão de usabilidade apenas épermitido ter uma InfoWindow de cada vez. No caso de ser premido um ícone já com umbalão visível, este é fechado antes de criar o seguinte. O resultado do pedido ao servidore consequente abertura da balão está visível na figura 4.12.

Figura 4.12: Visualização de detalhes de um equipamento numa InfoWindow

Anexas às informações do equipamento surgem algumas opções já enunciadas atrás,juntamente com a possibilidade de visualizar este item sobre o Google Street View. Oresultado desta opção é como o apresentado na figura 4.13.

Figura 4.13: Visualização de um equipamento com Google Street View

55



Considerando a quantidade de pontos que a base de dados pode vir a conter, analisou-se a capacidade de resposta do servidor em cada um dos estágios do processamento refe-rido nesta secção. Estes testes foram realizados num computador portátil com as seguintescaracterísticas de hardware e software:

Tabela 4.4: Características da máquina de teste

Processador Intel Core 2 Duo T5600 (1,83GHz)Memória 2 GBSistema operativo Ubuntu Desktop 10.04 LTS 32bitRuby v1.8.7Rails v2.3.5Base de dados v8.4.3Servidor Web WEBrick v1.3.1Browser Google Chrome 5.0.375.55 beta (debian)

Os tempos de resposta presentes na tabela 4.5 referem-se à média de três pedidos con-secutivos eliminando outliers que surgiram em algumas situações. Estes valores foramconsiderados como inválidos e podem ser devidos a ocupação do tempo de processadorcom outros processos do sistema operativo. Para cada teste, apontam-se o número de pon-tos na base de dados, nível de zoom, número de pontos seleccionados da base de dadose tempos de criação de aglomerados, tratamento da informação para envio e total entrepedido/resposta. No que toca ao processamento no cliente, regista-se o tempo entre re-cepção da informação e colocação de todos os ícones sobre o mapa, anotando-se ainda aquantidade de pontos individuais (i) e aglomerados (c). A ligação de rede entre servidore cliente é feita usando o endereço loopback (localhost). O resumo da informação da ta-bela para a situação mais crítica (grande quantidade de pontos seleccionados) encontra-seresumida no gráfico da figura 4.14.

Relativamente ao tempo de query à base de dados, pode ser verificado que o tempoacresce bruscamente quanto maior a quantidade de informação resultante da interroga-ção. Para uma grande quantidade de pontos (20000 a nível de zoom=13), o tempo deinterrogação pode mesmo ultrapassar os dois segundos, este foi o maior pico de temponesta interrogação. Visto que a máquina de teste não é um computador com uma exce-lente capacidade de processamento, podemos dizer que um segundo de processamentoclustering em matriz é aceitável, o mesmo não podemos dizer relativamente ao processa-mento de dados que neste caso chegou a ultrapassar os três segundos. No caso extremode muita informação a processar (20000 a nível de zoom=13) um tempo superior a cinco

56


Tabela 4.5: Análise do tempo do processamento geo-espacial (msecs)

# Pontos na Nível de # Pontos ∆t ∆t ∆t tratamento ∆tbase de dados zoom seleccionados query clustering da informação cliente

100 13 100 (c=18,i=2) 23.15 11.75 9.01 6100 19 1 (c=0,i=1) 16.90 6.17 0.28 2

1000 13 10000 (c=24,i=0) 91.28 56.06 101.13 61000 19 3 (c=0,i=3) 17.89 6.58 0.42 310000 13 10000 (c=24,i=0) 875.87 582.89 1124.86 610000 19 14 (c=1,i=11) 17.20 6.90 1.63 1220000 13 20000 (c=18,i=2) 1890.23 1069.13 2320.07 620000 19 28 (c=2,i=21) 19.03 10.05 2.67 23

Figura 4.14: Tempos de resposta no processamento de todos os pontos

segundos não é de todo aceitável, visto que degrada a usabilidade da aplicação. Uma boaforma de solucionar este excesso no tempo na resposta, é realizar uma pré-processamentoda informação utilizada na resposta utilizando o nível de zoom e regiões que delimitamcada um das células da matriz utilizada naquele zoom. Nesta solução, qualquer alteraçãosobre um equipamento, quer seja remoção, inserção ou actualização na base de dados, ne-cessitaria de um processo paralelo, que actualiza as células que dizem respeito à alteração.

4.3 Aplicação móvel

Os conceitos por detrás da criação da aplicação móvel a ser desenvolvida tendo emvista a utilização pelos fiscais da instituição são expostos nesta secção. Esta documen-tação expõe a forma de como é obtida a posição geográfica do utilizador numa interface

57


Web e como esta posição é utilizada para as operações a realizar pelo fiscal.

4.3.1 Geolocalização em aplicações Web

A W3C Geolocation API [28] providencia uma API JavaScript para permitir que pági-nas Web solicitem informação sobre a localização do dispositivo cliente - latitude, longi-tude, direcção, velocidade e precisão - a partir dos navegadores Web, seja este um dispo-sitivo móvel ou computador pessoal. A API não controla a forma como o browser obtéma posição geográfica, enquanto um telemóvel pode obter a posição geográfica a partirusando o componente de GPS, um computador pessoal pode fazê-lo por triangulação dasredes Wi-fi ao ser redor ou inferindo a partir do seu IP.As páginas Web podem solicitar a posição uma única vez, para centrar a posição do uti-lizador num mapa ou mostrar pontos de interesse ao seu redor, ou é criado um registo nonavegador solicitando a actualização da posição sempre que esta for alterada. Este últimocaso é o indicado para fornecer a posição sempre actualizada do utilizador sempre queeste se move p.ex. numa cidade. [29]Este JavaScript corre internamente no navegador cliente e pode comunicar a posição ac-tual do utilizador para um servidor remoto o que levanta questões de privacidade. Apesarde estar ainda numa versão draft a maioria dos browsers mais recentes (ex. Safari Mobile,Firefox 3.5+ e Android 2.0+) já suportam por defeito esta nova funcionalidade, que fazcom que alguns domínios e aplicações Web já façam uso para disponibilizar diferentesserviços. A seguir apontam-se algumas dessas aplicações:

• Flickr — Apresenta fotografias na região do utilizador [30]

• OurAirports Mobile — Permite obter um listagem dos aeroportos ordenados pelaproximidade do utilizador [31]

• Google Mobile — Fornece uma listagem de pontos de interesse na região do utili-zador [32]

Os navegadores Web móveis comunicam com o componente de hardware GPS atra-vés de uma interface disponibilizada para o efeito. Utilizando este novo paradigma móvelpara localização é possível enriquecer as aplicações Web móveis fornecendo informaçõespersonalizadas conforme a posição do utilizador. Este tipo de aplicações denomina-secomo Location-Based Services (LBS) e a lista apresentada em cima são alguns exemplossimples. A aplicação móvel inclui-se nesta classe de aplicações visto que utiliza a posiçãodo utilizador para fornecer informações baseadas nessa localização. No caso específicodesta aplicação, as informações obtidas do servidor consiste em pontos de interesse -equipamentos - associados às tarefas de cada fiscal. O funcionamento desta integração

58


entre dispositivo móvel, e mais especificamente browser móvel e servidor encontra-se es-quematizado na figura 4.15.

Figura 4.15: LBS e Geolocation API

A posição actual do utilizador é colocada como centro do mapa utilizando a funçãosetCenter() da API Google Maps. Quando uma tarefa se encontra seleccionada évisualizado sobre o mapa a distância e direcção relativas à posição do fiscal e o objecto averificar.

4.3.2 Utilização da W3C Geolocation API

Alguns dispositivos móveis mais populares – como o iPhone e telemóveis Android –suportam dois métodos para determinar a posição actual do utilizador. O primeiro con-siste na triangulação da posição baseada na proximidade de diferentes células móveisdo operador. Este método é rápido e e não necessita que hardware GPS dedicado, masapenas fornece uma posição aproximada à posição real. Dependendo de quantas célulasexistem na área, esta aproximação pode ser restrita a um quarteirão de uma cidade ou atéum quilómetro em qualquer direcção. O segundo método usa hardware GPS dedicadono dispositivo móvel para realizar a triangulação com satélites artificiais que orbitam asuperfície do planeta.Este hardware permite determinar a localização do utilizador com um erro de poucosmetros. A desvantagem é que um harware GPS num destes dispositivos consome muitaenergia, e por essa razão este telemóveis desligam o componente GPS até que seja so-licitado, o que significa que existe um atraso sempre que este é ligado e consiga obtera informação necessária para obter o fix, i.é, obter o número de satélites necessário parauma triangulação apropriada. A indicação da posição do utilizador na aplicação GoogleMaps é feita numa primeira instância com um círculo com raio maior que indica uma

59


aproximação à posição actual do utilizador (através das células móveis) e de seguida estecírculo diminui (por triangulação com outras células). Por fim surge um ponto que indicaa posição “exacta” obtida pelo hardware GPS. Esta diferença pode ser verificada na fi-gura 4.16.

Figura 4.16: Aplicação Google Maps Mobile com triangulação por células de telemóvel (à es-querda) e por GPS (à direita)

A precisão da posição do utilizador pode ser definida, como será exposto de seguidautilizando a W3C Geolocation API. No caso da aplicação a criar, e já que a precisãoneste domínio aplicacional é importante, é necessária a utilização do componente GPS dodispositivo. A utilização desta nova API encontra-se documentada no technical report daW3C. [28]Para determinar apenas uma vez a posição actual do utilizador utiliza-se uma chamada àfunção getCurrentPosition(). Esta função pode receber três parâmetros:

• Função callback em caso de sucesso — Nome da função a ser chamada no caso daobtenção da posição ter sido realizada com sucesso. A função callback deve receberum único parâmetro que irá corresponder à posição do utilizador. Esta posição podeentão ser utilizada para os fins a que a aplicação exige, i.é, receber a(s) tarefa(s)mais próxima(s)

• Função callback em caso de erro — Nome da função a ser chamada no caso daobtenção da posição ter criado uma excepção. Esta corresponde à função que irádeterminar qual a causa do erro gerado através do parâmetro positionError quedeve existir na função. Os valores e seus significados são exlpicados no technicalreport [28], no entanto estes erros não estão a ser verificados nesta fase.

60


• Opções — As opções da função são enviadas num objecto tipo array associativo.Um dos parâmetros essenciais enunciado atrás, define a precisão da localização.Esta opção – enableHighAccuracy – com o valor boleano true permite obteras coordenadas a partir do hardware GPS. O tempo máximo para obtenção da posi-ção do utilizador é definido pela propriedade timeout cuja contagem se inicia nomomento em que o utilizador aceita divulgar a sua posição.

A função watchPosition tem a mesma estrutura da anterior (duas funções call-back e array de opções). No entanto a primeira função callback é chamada sempre quea posição é actualizada. Com esta utilização não há necessidade de estar continuamentea interrogar activamente a posição do utilizador com getCurrentPosition. Esta é afunção utilizada para mostrar a posição actual do utilizador no mapa, actualizando o seucentro à medida que o utilizador se move. Esta função retorna um valor que é guardadonuma variável. Esta variável é depois utilizada para terminar a actualização da posiçãodo utilizador, terminando entao a chamada à função callback. O fecho deste processo érealizado com a função clearWatch da API.

Na função callback para tratamento da posição é enviado um parâmetro correspon-dendo a um objecto Position que contém o parâmetro coords. A partir deste parâ-metro é possível determinar latitude, longitude, precisão, direcção entre outros valores.Destes parâmetros, apenas são garantidos que se consigam determinar os três primeirosvalores. Todos os outros, no caso de não ser possível preencher tais variáveis, estas ficamnull.

4.3.3 Modelo da aplicação móvel

Para detectar no servidor se o cliente que realizou um pedido HTTP é um dispositivomóvel, verifica-se o user agent desse pedido. Para tal utiliza-se uma expressão regularpara verificar se a string do user agent contém a palavra “Mobile” que surge na maioriados dispositivos móveis. A página http://www.zytrax.com/tech/web/mobile_ids.html contém uma listagem bastante extensa dos user agents dos navegadores mó-veis e não móveis. Com esta verificação pode-se por exemplo criar folhas de estilo espe-cíficas para cada tipo de cliente móvel.É possível em Ruby on Rails criar tipos mime adicionando as linhas pretendidas no fi-cheiro

c o n f i g / i n i t i a l i z e r s / mime_types . rb

do projecto. Assim é possível personalizar todo o layout da página de acordo com odispositivo móvel para que se está a desenvolver. A linha adicionada neste ficheiro foi:

Mime : : Type . r e g i s t e r _ a l i a s " t e x t / h tml " , : mobi l e

61

http://www.zytrax.com/tech/web/mobile_ids.html

http://www.zytrax.com/tech/web/mobile_ids.html


desta forma temos um formato HTML alternativo para dispositivos móveis. Neste sen-tido podemos manipular a variável request para poder alterar o formato associado aorequest atribuindo a variável mobile. Os documentos com conteúdo HTML que se des-tinarem a dispositivos móveis, passam a ter a extensão .mobile.erb e é este o tipo deficheiro enviado como resposta a um pedido de um cliente desse tipo.

A interface móvel foi criada com a framework de desenvolvimento Web móvel deno-minada jQTouch cujas aplicações resultantes tornam-se semelhantes a aplicações nativasiPhone. [33]

4.3.4 Funcionalidades

Considerando as possibilidades de localização do utilizador e necessidade de integra-ção das actividades de fiscalização com o fluxo de negócio concebido, foram implemen-tadas algumas das funcionalidades previstas e necessárias para execução das tarefas destetipo de utilizador. Para o desenvolvimento foi utilizado um emulador iPhone [34], noentanto o comportamento deste, juntamente com a framework utilizada não permitiu con-cretizar a implementação de funções onde deveria estar incluído um mapa. No caso dasopções da interface inicial, bem como a actualização do movimento do utizador sobre omapa Web, apenas ficou implementado a interacção com servidor, tendo sido desenvolvi-das pequenas aplicações que permitem obter uma prova de conceito.

• Autenticação — A autenticação é realizada utilizando AJAX. O servidor verifica ascredenciais e se o utilizador corresponde a um fiscal. Nestes casos o servidor enviauma mensagem traduzindo o erro. Na situação em que a autenticação é efectuadacom sucesso, o servidor envia um URL pessoal para as opções iniciais. As figurasdo ecrã de login e página inicial podem ser analisadas na figura 4.17.

• Aquisição de tarefas — A aquisição de tarefas é feita no momento da autenticaçãoe está contida na página inicial. A framework jQTouch permite criar na mesmapágina diferentes interfaces que se mantêm invisíveis até que o utilizador realizealguma selecção sobre um botão da interface. No ecrã inicial (figura 4.17) já surgema quantidade de tarefas atribuídas ao utilizador. A selecção desta opção permitevisualizar a sua listagem com alguma informação básica presente no documento(figura 4.18).

• Visualização de uma tarefa — A figura 4.18 ilustra a visualização do conteúdo deuma tarefa. Nesta interface existe um opção para visualizar a tarefa sobre um mapaWeb.

62


Figura 4.17: Aplicação móvel: Login (à esquerda) e página inicial (à direita)

Figura 4.18: Aplicação móvel: Lista de tarefas (à esquerda) visualização de tarefa (à direita)

• Navegar para próxima tarefa — Este é um extra ao conceito inicial que permiteo cálculo do próximo objectivo automaticamente. A ideia foi a reutilização do con-ceito criado por Furnas em [21] e explorado no capítulo 2. Para tal e para calculara distância a priori do ponto alvo utiliza-se a prioridade definida para o documento,multiplicando-se esse valor por 100. A distância ao ponto da tarefa é utilizado parasubtrair ao resultado anterior. A distância é previamente dividida por 10 para os

63


valores ficarem dentro do mesmo domínio (três casas decimais). Os cálculos re-alizados neste exemplo para a determinação da próxima tarefa do utilizador estãorepresentadas na tabela 4.6.

Tabela 4.6: Determinação da próxima tarefa do fiscal por sugestão

Tarefa Prioridade da API(x) D(x,y) DOI(x) tarefa x (metros)A 5 5 * 100 = 500 1000 500 - 1000/10 = 400B 1 1 * 100 = 100 250 100 - 250/10 = 75C 2 2 * 100 = 200 500 200 - 500/10 = 150D 3 3 * 100 = 300 750 300 - 750/10 = 225

A divisão por 10 serve para permitir que a distância entre na gama de valores daimportância a priori, i.é, três dígitos. Neste caso a tarefa A será a seleccionada.Pode acontecer que uma tarefa com maior prioridade e por ter uma maior distânciaD(x,y), ter um valor de grau de interesse (DOI) menor que uma tarefa com menorprioridade.

• Visualizar no mapa a tarefa mais próxima — Como as tarefas estão associadasa equipamentos, estas encontram-se indirectamente georreferenciadas. Deste modoé possível calcular as distâncias entre a posição geográfica actual do utilizador e oconjunto de tarefas atribuídas. Este cálculo é realizado com suporte da função Post-GIS ST_Distance juntamente com a opção de ordenação ORDER BY. A primeiralinha do conjunto de resultados da interrogação à base de dados corresponde à tarefamais próxima. Esta opção torna-se útil no caso de ter sido previamente seleccionadauma tarefa e o fiscal ter-se dirigido ao local em modo offline. Ao chegar ao local,esta opção pode ser utilizada para prosseguir nas acções seguintes a realizar sobre oequipamento.

• Criação de um documento — A conclusão de uma tarefa implica a criação de umdocumento de um dos dois tipos já referidos atrás. A não criação de um documentopara uma tarefa seleccionada implica a não conclusão da tarefa, tal como repre-sentado no fluxo documental presente na imagem 4.1. Neste conceito, aquando dodeslocamento do utilizador, seria calculada a distância deste ao ponto alvo. Quandoo resultado do cálculo desta função for inferior a um metro, a página do utilizadorseria possível visualizar uma lista de opções que retratam o final da realização deuma tarefa.


O desenvolvimento da interface móvel como aplicação Web tem algumas vantagenscomo:

64


• Maior facilidade de manutenção e desenvolvimento — O desenvolvimento de inter-faces Web utilizando HTML, CSS e JavaScript é mais rápida e mais barata que odesenvolvimento de interfaces na linguagem nativa dos equipamentos

• Portabilidade da aplicação entre diferentes tipos de dispositivos — Todos os equi-pamentos móveis que possuem browsers com deteminadas características comunspodem visualizar a interface da mesma forma, ou caso contrário apenas são neces-sárias pequenas alterações

• Possibilidade de geolocalização — A W3C Geolocation API é uma mais valia nodesenvolvimento de aplicações que fazem uso do componente GPS do dispositivomóvel

No entanto tem também algumas desvantagens a anotar:

• Custos de acesso à rede móvel

• Interface tem resposta dependente da velocidade da rede

No final deste processo de desenvolvimento, chegou-se à conclusão que por exemplo atarefa do utilizador adicionar uma fotografia do equipamento a partir do dispositivo móvelimplica a utilização da aplicação da câmara fotográfica, seguido de, utilizar a aplicaçãopara então realizar upload da imagem. Este processo não é prático e pode inclusivé darorigem a erros, como realizar upload do ficheiro errado.Para além disso o uso de uma aplicação nativa abre um conjunto de possibilidades nãopossível com uma aplicação Web. Relativamente aos mapas, tem-se a possibilidade deconseguir utilizar mapas offline diminuindo os custos de acesso à rede. Neste caso, aligação à rede seria utilizada somente para obter as tarefas a realizar e submeter docu-mentação. O acesso a componentes de hardware traz também algumas possibilidades emvoga actualmente. Pode trazer a possibilidade de utilização de realidade aumentada parao processo de gestão através do acesso á câmara; leitura de QRCodes (apenas no casoorganização se dispor a etiquetar todos os equipamentos) e/ou RFID que consistem emcomponentes electrónicos de produção muito barata e que pode facilitar o processo deidentificação dos equipamentos; acesso directo à câmara fotográfica para envio de me-tainformação a anexar aos documentos.

4.4 Portabilidade da solução

As tecnologias utilizadas para o desenvolvimento deste protótipo estão disponíveispara os principais sistemas operativos (Microsoft Windows, Linux e MacOS). Apenasexiste uma reserva no que toca à portabilidade, o mecanismo de automação. Nos sistemas

65


Microsoft apesar de não existir por defeito as aplicações cron e wget, existem disponí-veis gratuitamente versões para Windows destas aplicações. Nas versões mais recentesdo Microsoft Windows (a partir da versão 2000) existe uma aplicação própria do sistemaoperativo denominada Schedule service que permite agendar acções para datas e horasespecíficas.

4.5 Resumo

Abordaram-se as opções tomadas para o desenvolvimento da aplicação realizando-sesempre que possível uma breve análise sobre o implementado. As análises apresentadastêm em vista algumas considerações para optimizar a aplicação no seu global. O protótipoobtido neste desenvolvimento permite integrar as entidades de forma a orquestrar algumada dinâmica esperada envolvida num processo de gestão neste domínio.A secção de visualização aplica alguns dos conceitos enunciados no capítulo do estadoda arte, e permite resumir a informação existente a ser apresentada no mapa, permitindoaumentar a sua usabilidade. O desenvolvimento móvel utiliza algumas novidades actuaissobre geolocalização em interface Web. Na secção que descreve este desenvolvimentodescreveu-se a interacção com o servidor Web.

66

Capítulo 5

Conclusão

O principal objectivo desta dissertação foi a criação de um conceito e especificaçãode alto nível de uma plataforma para gestão de património municipal, baseando o desen-volvimento em algumas das possibilidades que os sistemas GIS oferecem. A arquitecturasugerida e a forma de desenvolvimento permitem que o sistema seja facilmente extensívele adaptável a outras estruturas organizacionais.O conceito Urbest aqui apresentado permite responder à necessidade de agilizar os pro-cessos da cadeia de gestão de equipamentos urbanos, tornando-os mais eficientes e autó-nomos, sem esquecer uma parte importante que é a contribuição do público e integraçãodessas informações com o próprio sistema de gestão. Embora seja apenas um protótipo,pode-se afirmar que colmata necessidades específicas deste domínio. Embora as ideiasdeste projecto tenham sido validadas numa única reunião com a Direcção Municipal daVia Pública da CMP e esta tenha contribuído com noções e funcionalidades consideradasimportantes faltou no final do projecto a validação funcional da aplicação.

5.1 Notas finais

As autarquias fazem uso actualmente de tecnologias GIS internamente e disponibili-zam informações públicas facultando mapas interactivos. [35, 36]No entanto, e tomando o exemplo da CMP, a gestão de equipamentos urbanos não é ba-seada em informação georrefenciada. A solução proposta apresenta uma abordagem paraeste problema integrando diferentes níveis da estrutura hierárquica da instituição pública.Tem em conta a utilização de equipamentos móveis e possibilidades de geolocalizaçãoque dispositivos recentes oferecem de raiz. A utilização destes aparelhos permite agili-zar o processo nas classes hierárquicas mais baixas e que trabalham no terreno junto dosequipamentos.

67

Conclusão

A utilização de PPGIS é uma mais valia nesta gestão já que internamente é impossívelsaber em tempo real a situação de cada equipamento no espaço geográfico da cidade. Aparte da aplicação que permite a participação pública é um conceito não recente mas queaplicado nesta solução permite envolver o público integrando a informação recebida nosistema de gestão.O desenvolvimento desta aplicação realizou-se utilizando exclusivamente ferramentasgratuitas. Torna-se possível criar aplicações de cariz geográfico e de suporte à gestãoutilizando estas ferramentas, finalizando-se num projecto com custos de produção maisbaixos e de qualidade semelhante.Foram desenvolvidos alguns dos conceitos analisados no capítulo 2 sobre a API do Go-ogle Maps. Tal como esta, a versão de Web Maps da Microsoft (Bing Maps) permiteigualmente recriar estas alternativas de visualização.

5.2 Desenvolvimento futuro

As três grandes partes tal como estão descritas no capítulo 4 foram desenvolvidas inde-pendentemente, faltando a integração principalmente ao nível da utilização dos cadastros.O desenvolvimento da aplicação Web móvel foi penalizado pela não existência de umdispositivo real para testes. Apesar disso foram criadas pequenas funcionalidades a seremintegradas na aplicação final. Nos casos em que não foi possível realizar um teste noemulador, foi criada apenas uma mini aplicação para testar a validade do conceito.No final de cada secção do capítulo 4 foi realizada uma breve análise em jeito de autocrí-tica sobre o que foi desenvolvido. As críticas realizadas ao resultado de cada uma destaspartes permite obter uma visão geral sobre o que ainda existe por melhorar e correspon-dem a ideias que foram surgindo no decorrer do projecto. Na falta de uma avaliaçãofuncional e de usabilidade da aplicação pretendeu-se realizar um desenvolvimento o maisgenérico possível envolvendo as funcionalidades essenciais previstas, tornando a imple-mentação o mais escalável possível, recorrendo à modularização das partes constituintesdo projecto. A adição de novas funcionalidades que poderão surgir pela análise funcio-nal, ou por necessidades específicas de uma instituição estão asseguradas não só devidoà forma como o desenvolvimento foi estruturado como pela arquitectura MVC que a fra-mework seleccionada oferece, sendo esta bastante flexível.Ficou por saber concretamente qual o tipo de informação que é essencial para a tomadade decisão, e para tal, que tipo de decisões são necessárias fazer. Para tal é necessáriofuturas reuniões para refinamento de requisitos para determinar estas especificidades queo tempo não permitiu no decorrer desta dissertação.Ainda por melhorar ficam aspectos de segurança, usabilidade e verificação/tratamento deerros ao nível dos formulários das interfaces, que nesta fase foi considerado como secun-dário.

68

Conclusão

5.3 Trabalho futuro

A flexibilidade da implementação e da arquitectura MVC da framework permite ex-tender ou modificar este conceito para que possa ser aplicado a outros modelos de negóciodistintos.No segmento de gestão pública uma forte possibilidade consiste em fazer o mapeamentocriminal da zona urbana em que a participação pública passa a ter um papel importante.A acumulação de informações por um sistema deste tipo permite organizar operaçõesde reforço por parte da autoridades da segurança pública. Este tipo de sistema não énovidade nos Estados Unidos que utilizam uma aplicação baseada em mapas Web paraauxiliar os departamentos policiais no combate ao crime e providenciar informação aoscidadãos. [37] No entanto o registo destes crimes são realizados exclusivamente pelasautoridades, falhando na integração com informações providenciadas pelo público. Em-presas do ramo da distribuição e seus parceiros e clientes podem igualmente usufruir deuma aplicação semelhante. Neste caso um Pedido seria feito por clientes e parceiros aque as empresas distribuidoras teriam que responder. A assimilação da informação comrecurso a sistemas inteligentes, e mapas permite um planeamento óptimo na execução deoperações, aumentando a competitividade da empresa com provável redução de custosoperacionais e com a consequente satisfação dos clientes.

69

Conclusão

70

Referências

[1] John E. Harmon e Steven J. Anderson. The design and implementation of geographicinformation systems. John Wiley and Sons, 2003.

[2] P. Pombinho, M.B. Carmo, e A.P. Afonso. Evaluation of overcluttering preventiontechniques for mobile devices. Em Information Visualisation, 2009 13th Internatio-nal Conference, páginas 127–134, 2009.

[3] Sh-Tourismus.De. Schleswig-holstein, 2010. Disponível em http://www.sh-tourismus.de, acedido pela última vez em 21 de Junho de 2010.

[4] I. Zorica e D. Budic. Effectiveness of geographic information systems in local plan-ning. Journal of the American Planning Association, 60(2):244, 1994.

[5] Menno-Jan Kraak. The role of the map in a Web-GIS environment. Journal ofGeographical Systems, 6(2):83–93, Junho 2004.

[6] Vania A Ceccato e Folke Snickars. Adapting GIS technology to the needs of localplanning. Environment and Planning B: Planning and Design, 27(6):923–937, 2000.

[7] Scott Davis. GIS For Web Developers - Adding Where to Your Web Applications.Pragmatic Bookshelf, Outubro 2007.

[8] Paul Longley, Michael Goodchild, David Maguire, e David W. Rhind. GeographicInformation Systems and Science, chapter 1. John Wiley & Sons, Ltd, Fevereiro2005.

[9] Jorge Cardoso. m-gis: Mobile GIS, tese de licenciatura, 2002.

[10] Francisco Artigas, Dom Elefante, Arfaa Mujeeb, Alex Marti, e Eric Yadlovski. A re-gional approach to geographic information sharing in northern new jersey, USA. EmProceedings of the 2008 international conference on Digital government research,páginas 132–136, Montreal, Canada, 2008. Digital Government Society of NorthAmerica.

[11] Juliana Arenas e Holmes Zambrano. Web-based GIS applications for government.Em Proceedings of the 3rd International Conference on Theory and Practice of Elec-tronic Governance, páginas 383–384, Bogota, Colombia, 2009. ACM.

[12] Cláudio Chauke Nehme e Margareth Simões. Spatial decision support system forland assessment. Em Proceedings of the 7th ACM international symposium on Ad-vances in geographic information systems, páginas 85–90, Kansas City, Missouri,United States, 1999. ACM.

71

http://www.sh-tourismus.de

http://www.sh-tourismus.de

REFERÊNCIAS

[13] Francisco Artigas, Dom Elefante, Arfaa Mujeeb, Alex Marti, e Eric Yadlovski. A re-gional approach to geographic information sharing in northern new jersey, USA. EmProceedings of the 2008 international conference on Digital government research,páginas 132–136, Montreal, Canada, 2008. Digital Government Society of NorthAmerica.

[14] ESRI | the GIS software leader. http://www.esri.com/. Disponível em http://www.esri.com/, acedido pela última vez em 21 de Junho de 2010.

[15] Lan Lin, Lijun Li, e Bo Xie. Application of VRGIS in dynamic urban planning.Em Information and Automation, 2008. ICIA 2008. International Conference on,páginas 1840–1844, 2008.

[16] Paelke V. Elias B. e Kuhnt S. Concepts for the cartographic visualization of land-marks. Em Location based services and telecartography-proceedings of the sympo-sium 2005, páginas 1149–1155, 2005.

[17] Mário Freitas. A novel visualisation paradigm for Three-Dimensional Map-Basedmobile services, tese de mestrado, 2008.

[18] P. Pombinho, M.B. Carmo, e A.P. Afonso. Visualização de informação georeferen-ciada em dispositivos móveis. Em V Encontro Português de Computação Gráfica(EPCG’07), páginas 183–188, October 2007.

[19] Alistair Edwardes, Dirk Burghardt, e Robert Weibel. Portrayal and generalisation ofpoint maps for mobile information services. páginas 11–30, 2005.

[20] Maria Carmo, Ana Afonso, Paulo Pombinho de Matos, e Ana Vaz. MoViSys – avisualization system for Geo-Referenced information on mobile devices. Em Vi-sual Information Systems. Web-Based Visual Information Search and Management,páginas 167–178. 2008.

[21] G. W. Furnas. Generalized fisheye views. Em CHI ’86: Proceedings of the SIGCHIconference on Human factors in computing systems, páginas 16–23, New York, NY,USA, 1986. ACM.

[22] Maria Beatriz Carmo, Sérgio Freitas, Ana Paula Afonso, e Ana Paula Cláudio. Fil-tering mechanisms for the visualization of geo-referenced information. páginas 1–4,Bremen, Germany, 2005. ACM.

[23] REXML Working Group. Rexml. Disponível em http://www.germane-software.com/software/rexml/, acedido pela última vezem 21 de Junho de 2010.

[24] Exame Informática. O debate, rua a rua. Disponível em http://www2.inescporto.pt/noticias-eventos/nos-na-imprensa/o-debate-rua-a-rua/, acedido pela última vez em 21 de Junho de 2010.

[25] Corey J. Mini-magick. Disponível em http://rubyforge.org/projects/mini-magick/, acedido pela última vez em 21 de Junho de 2010.

[26] André Lewis, Michael Purvis, e Jeffrey Sambells. Beginning Google maps applica-tions with Rails and Ajax, chapter 7. Apress, Fevereiro 2007.

72

http://www.esri.com/

http://www.esri.com/

http://www.germane-software.com/software/rexml/

http://www.germane-software.com/software/rexml/

http://www2.inescporto.pt/noticias-eventos/nos-na-imprensa/o-debate-rua-a-rua/



http://rubyforge.org/projects/mini-magick/

http://rubyforge.org/projects/mini-magick/

REFERÊNCIAS

[27] Google. Google maps javascript api v3, 2010. Disponível em http://code.google.com/apis/maps/documentation/javascript/, acedido pela úl-tima vez em 21 de Junho de 2010.

[28] W3C. Geolocation api specification. Disponível em http://dev.w3.org/geo/api/spec-source.html, acedido pela última vez em 21 de Junho de 2010.

[29] Mark Pilgrim. You are here (and so is everybody else). Disponível em http://diveintohtml5.org/geolocation.html, acedido pela última vez em 21de Junho de 2010.

[30] Yahoo! Flickr. Disponível em http://www.flickr.com/map/, acedido pelaúltima vez em 21 de Junho de 2010.

[31] Megginson Technologies Ltd. Ourairports mobile. Disponível em http://ourairports.mobi/, acedido pela última vez em 21 de Junho de 2010.

[32] Google. Google mobile. Disponível em http://www.google.com/m/, acedidopela última vez em 21 de Junho de 2010.

[33] David Kaneda. jqtouch. Disponível em http://jqtouch.com/, acedido pelaúltima vez em 21 de Junho de 2010.

[34] Genuitec. Mobione emulator. Disponível em http://www.genuitec.com/mobile/download.html, acedido pela última vez em 10 de Junho de 2010.

[35] Câmara Municipal do Porto. Aplicação de informação geográfica da câmaramunicipal do porto, 2010. Disponível em http://sigweb.cm-porto.pt/mipwebportal, acedido pela última vez em 21 de Junho de 2010.

[36] Câmara Municipal de Lisboa. Aplicação de informação geográfica da câmara mu-nicipal de lisboa, 2010.

[37] The Omega Group. Crimemapping.com. Disponível em http://www.crimemapping.com/, acedido pela última vez em 21 de Junho de 2010.

73

http://code.google.com/apis/maps/documentation/javascript/

http://code.google.com/apis/maps/documentation/javascript/

http://dev.w3.org/geo/api/spec-source.html

http://dev.w3.org/geo/api/spec-source.html

http://diveintohtml5.org/geolocation.html

http://diveintohtml5.org/geolocation.html

http://www.flickr.com/map/

http://ourairports.mobi/

http://ourairports.mobi/

http://www.google.com/m/

http://jqtouch.com/

http://www.genuitec.com/mobile/download.html

http://www.genuitec.com/mobile/download.html

http://sigweb.cm-porto.pt/mipwebportal

http://sigweb.cm-porto.pt/mipwebportal

http://www.crimemapping.com/

http://www.crimemapping.com/

REFERÊNCIAS

74

Anexo A

Protótipo de interface

Este anexo contém os protótipos não funcionais das interfaces criadas para apresenta-ção do conceito à Direcção Municipal da Via Pública da CMP.

A.1 Slides de apresentação

Figura A.1: Apresentação à CMP: Slide inicial

A.2 Prototipagem para funcionalidades desktop - Serviços internos

75


Figura A.2: Apresentação à CMP: Utilizadores

Figura A.3: Apresentação à CMP: Exposição do fluxo de negócio criado

76


Figura A.4: Apresentação à CMP: Mapa principal

Figura A.5: Apresentação à CMP: Visualização de tarefas

77


Figura A.6: Apresentação à CMP: Criação manual de tarefas

Figura A.7: Apresentação à CMP: Listagem de pedidos

78


Figura A.8: Apresentação à CMP: Visualização de pedidos

Figura A.9: Apresentação à CMP: Listagem de equipamentos

79


Figura A.10: Apresentação à CMP: Histórico de um equipamento

Figura A.11: Apresentação à CMP: Visualização de um documento

80


Figura A.12: Apresentação à CMP: Edição de um documento

Figura A.13: Apresentação à CMP: Lista de processos

81


Figura A.14: Apresentação à CMP: Notificações sobre a interface

Figura A.15: Apresentação à CMP: Visualização do estado de um processo

82


Figura A.16: Apresentação à CMP: Visualização estatística

83


A.3 Prototipagem para funcionalidades móveis - Fiscalização

Figura A.17: Apresentação à CMP: Apresentação das funcionalidades móveis

Figura A.18: Apresentação à CMP: Listagem de tarefas em interface móvel

84


Figura A.19: Apresentação à CMP: Selecção de tarefa em interface móvel

Figura A.20: Apresentação à CMP: Visualizar tarefa no mapa em interface móvel

85


Figura A.21: Apresentação à CMP: Submissão de documentos em interface móvel

86

Anexo B

Implementação de operadores devisualização em Web maps

A terceira API do Google Maps permite criar camadas personalizadas e para tal dis-ponibiliza a classe OverlayView. A API do Google Maps é bastante esclarecedora emrelação aos métodos que são necessários implementar para ser possível traduzir coorde-nadas no ecrã em coordenadas geográficas.As implementações dos dois tipos de tipificações descritos no capítulo 2 foram realizadastendo em conta esta possibilidade. O operador de deslocamento já não envolve a criaçãode uma subclasse deste tipo.

B.1 Operador de tipificação homogénea

O bloco de código que se segue corresponde à instanciação da subclasse e ao constru-tor da nova classe. O construtor contém algumas definições importantes para a correctaapresentação gráfica e colocação sobre o mapa. As opções passadas ao construtor inclui ovalor a colocar sobre o ícone, a localização geográfica, o objecto mapa e o URL do íconea utilizar.Outras configurações possíveis e manipuladas directamente no código corresponde às de-finições dos objectos gráficos utilizados – tamanho dos ícones, ponto na imagem a utilizarcomo centro do ponto e acção automática de zoom ao clicar sobre o ícone.S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e = new go og l e . maps . OverlayView ( ) ;

f u n c t i o n S i n g l e I c o n C l u s t e r O v e r l a y ( o p t i o n s ) {/ / some i n i t i a l d e f i n i t i o n st h i s . image_wid th_ = 3 2 ; / / icon widtht h i s . i m a g e _ h e i g t h _ = 3 7 ; / / icon heightt h i s . i m a g e _ a n c h o r _ p o s i t i o n _ x = 1 5 ;t h i s . i m a g e _ a n c h o r _ p o s i t i o n _ y = 3 4 ;t h i s . zoomOnClick = t rue ;

t h i s . v a l u e _ = o p t i o n s . l a b e l V a l u e ;t h i s . p o s i t i o n _ = o p t i o n s . p o s i t i o n ;t h i s . d i v_ = n u l l ;t h i s . map_ = o p t i o n s . map ;t h i s . i c o n _ = o p t i o n s . i c o n ;t h i s . setMap ( t h i s . map_ ) ;

}

87

Implementação de operadores de visualização em Web maps

A API invoca o método onAdd() para notificar ao objecto mapa, que uma nova ca-mada foi adicionada. Este método manipula a DOM do documento criando os elementosHTML necessários para a apresentação do operador. No final os novos elementos sãoadicionados ao mapa.

S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . onAdd = f u n c t i o n ( ) {/ / Create the DIV to hold our elementsv a r d i v = document . c r e a t e E l e m e n t ( " d i v " ) ;d i v . s t y l e . p o s i t i o n = " a b s o l u t e " ;d i v . s t y l e . background = " t r a n s p a r e n t " ;d i v . s t y l e . padd ing = 0 ;d i v . s t y l e . c u r s o r = ’ p o i n t e r ’ ;d i v . s t y l e . wid th = t h i s . image_wid th_ ;d i v . s t y l e . h e i g t h = t h i s . i m a g e _ h e i g t h _ ;

i f ( t h i s . zoomOnClick )$ ( d i v ) . c l i c k ( f u n c t i o n ( ) {

c l e a r C u r r e n t M a p M a r k e r s ( ) ;map . setZoom ( map . getZoom ( ) + 1) ;

} ) ;

/ / add the image and labe ld i v . innerHTML = ’<img s r c =" ’+ t h i s . i c o n _+ ’ "/ > < span c l a s s =" s i n g l e C l u s t e r L a b e l " s t y l e =" l e f t : ’+ ( t h i s . image_wid th_ − 10) + ’ px ; t o p :− ’+ ( t h i s . i m a g e _ h e i g t h _ + 10) + ’ px"> ’+ t h i s . v a l u e _ + ’ </ span > ’ ;

v a r panes = t h i s . g e t P a n e s ( ) ;panes . o v e r l a y L a y e r . appendCh i ld ( d i v ) ;

t h i s . d i v_ = d i v ;}

Quando o elemento é adicionado ao mapa pela primeira vez e sempre que é necessárioredesenhar o objecto (p.ex. no final de uma acção de zoom), a função draw() é invocada.Esta permite realizar um mapeamento entre as coordenadas geográficas do objecto e aposição relativa sobre o mapa Web.

S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . draw = f u n c t i o n ( ) {v a r o v e r l a y P r o j e c t i o n = t h i s . g e t P r o j e c t i o n ( ) ;v a r p o i n t P x = o v e r l a y P r o j e c t i o n . f romLatLngToDivPixe l ( t h i s . p o s i t i o n _ ) ;t h i s . d i v_ . s t y l e . w id th = t h i s . image_wid th_ + " px " ;t h i s . d i v_ . s t y l e . h e i g h t = t h i s . i m a g e _ h e i g h t _ + " px " ;t h i s . d i v_ . s t y l e . l e f t = ( p o i n t P x . x − t h i s . i m a g e _ a n c h o r _ p o s i t i o n _ x ) + " px " ;t h i s . d i v_ . s t y l e . t o p = ( p o i n t P x . y − t h i s . i m a g e _ a n c h o r _ p o s i t i o n _ y ) + " px " ;

}

A remoção do ícone do mapa faz-se pela invocação de métodos nativos de manipu-lação da DOM que permitem navegar sobre a estrutura do XML da página e remover oobjecto div criado anteriormente.

S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . onRemove = f u n c t i o n ( ) {t h i s . d i v_ . pa ren tNode . removeChi ld ( t h i s . d i v_ ) ;t h i s . d i v_ = n u l l ;

}

A manipulação das propriedades CSS permite esconder e mostrar o objecto.

88


S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . h i d e = f u n c t i o n ( ) {i f ( t h i s . d i v_ ) t h i s . d i v_ . s t y l e . v i s i b i l i t y = " h id de n " ;

}

S i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . show = f u n c t i o n ( ) {i f ( t h i s . d i v_ ) t h i s . d i v_ . s t y l e . v i s i b i l i t y = " v i s i b l e " ;

}/ / toggle the layer ’ s v i s i b i l i t yS i n g l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . t o g g l e = f u n c t i o n ( ) {

i f ( t h i s . d i v_ ) {i f ( t h i s . d i v_ . s t y l e . v i s i b i l i t y == " h id de n " )

t h i s . show ( ) ;e l s e

t h i s . h i d e ( ) ;}

}

B.2 Tipificação heterogénea

Este operador é semelhante na implementação, apenas muda na apresentação da in-formação. Como pré-requisito é necessário criar miniaturas dos ícones utilizados pararepresentar os objectos. O método construtor recebe como parâmetros um array com osURLs para os ícones a incluir, o objecto do mapa e o centro calculado para colocar ob-jecto resultante.Neste construtor é definido também a partir da informação recebida a quantidade de íco-nes máxima visualizar numa linha.M u l t i p l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e = new go og l e . maps . OverlayView ( ) ;

f u n c t i o n M u l t i p l e I c o n C l u s t e r O v e r l a y ( c e n t e r , map , imagesToConta in ) {/ / basic c lass d e f i n i t i o n st h i s . max_columns_ = imagesToConta in . l e n g t h == 2 ? 2 : Math . round (

imagesToConta in . l e n g t h / 2 ) ;t h i s . image_wid th_ = 1 6 ;t h i s . i m a g e _ h e i g t h _ = 1 6 ;t h i s . bo rde rWid th_ = 1 ;t h i s . b o r d e r C o l o r _ = ’ #FFC345 ’ ;t h i s . c o n t a i n e r P a d d i n g _ = 1 ;t h i s . imageMargin_ = 1 ;t h i s . c o n t a i n e r B o r d e r R a d _ = 4 ;t h i s . zoomOnClick = t rue ;

t h i s . c e n t e r _ = c e n t e r ;t h i s . d i v_ = n u l l ;t h i s . map_ = map ;t h i s . images_ = imagesToConta in ;t h i s . setMap ( map ) ;

} ;

A função onAdd() cria o elemento div e adiciona as imagens recebidas no constru-tor.M u l t i p l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . onAdd = f u n c t i o n ( ) {

/ / Create the DIV represent ing our rec tanglev a r d i v = document . c r e a t e E l e m e n t ( " d i v " ) ;d i v . s t y l e . b o r d e r = t h i s . bo rde rWid th_ + " px s o l i d " + t h i s . b o r d e r C o l o r _ ;d i v . s t y l e . p o s i t i o n = " a b s o l u t e " ;

89


d i v . s t y l e . background = " #FFFD8B" ;d i v . s t y l e . o p a c i t y = 0 . 8 5 ;d i v . s t y l e . padd ing = t h i s . c o n t a i n e r P a d d i n g _ + " px " ;d i v . s t y l e . c u r s o r = ’ p o i n t e r ’ ;d i v . s t y l e . l i n e H e i g h t = 0 ;d i v . s t y l e . b o r d e r R a d i u s = t h i s . c o n t a i n e r B o r d e r R a d _ + " px " ;

/ / add the imagesd i v . innerHTML = " " ;f o r ( v a r i = 0 ; i < t h i s . images_ . l e n g t h ; i ++)

d i v . innerHTML += ’<img s t y l e =" margin : ’ + t h i s . imageMargin_ + ’ px;−webki t−borde r−r a d i u s : 3 px " s r c =" ’ + t h i s . images_ [ i ] + ’ " / > ’ ;

i f ( t h i s . zoomOnClick )$ ( d i v ) . c l i c k ( f u n c t i o n ( ) {

map . setZoom ( map . getZoom ( ) + 1) ;} ) ;

v a r panes = t h i s . g e t P a n e s ( ) ;panes . o v e r l a y L a y e r . appendCh i ld ( d i v ) ;

t h i s . d i v_ = d i v ;} ;

Na função draw() as propriedades de apresentação são definidas tendo em contatodas as dimensões definidas.As restantes funções são idênticas às descritas no operador B.1./ / desenhar o layerM u l t i p l e I c o n C l u s t e r O v e r l a y . p r o t o t y p e . draw = f u n c t i o n ( ) {

v a r o v e r l a y P r o j e c t i o n = t h i s . g e t P r o j e c t i o n ( ) ;v a r p o i n t P x = o v e r l a y P r o j e c t i o n . f romLatLngToDivPixe l ( t h i s . c e n t e r _ ) ;

v a r n r _ l i n e s = t h i s . images_ . l e n g t h / t h i s . max_columns_ ;v a r t o t a l C l u s t e r W i d t h = t h i s . max_columns_ ∗ t h i s . image_wid th_ + t h i s .

c o n t a i n e r P a d d i n g _ ∗ 2 ;

t h i s . d i v_ . s t y l e . w id th = ( t h i s . max_columns_ ∗ t h i s . image_wid th_ + t h i s .max_columns_ ∗ t h i s . imageMargin_ ∗ 2 ) + " px " ;

t h i s . d i v_ . s t y l e . h e i g h t = ( n r _ l i n e s ∗ t h i s . i m a g e _ h e i g h t _ ) + " px " ;t h i s . d i v_ . s t y l e . l e f t = ( p o i n t P x . x − ( t o t a l C l u s t e r W i d t h / 2 . 0 ) ) + " px " ;t h i s . d i v_ . s t y l e . t o p = ( p o i n t P x . y − ( n r _ l i n e s ∗ t h i s . i m a g e _ h e i g t h _ / 2 . 0 ) −

t h i s . c o n t a i n e r P a d d i n g _ ) + " px " ;} ;

As restantes funções são semelhantes às enunciadas em B.1 e não existe nada de novoa apontar.

B.3 Deslocamento

A classe DisplacementManager não especializa a classe OverlayView comoas anteriores. No entanto foi implementado este operador usando o paradigma OOP.O construtor recebe um array de objectos do tipo google.maps.Marker e o objectomapa.O círculo trigonométrico é dividido em partes iguais dividindo pela quantidade de íconesincluídos no cluster. Depois para evitar que sejam calculadas as novas posições cada vezque é invocada a função de afastamento, os valores das novas posições são précalculados.

90


Para finalizar é criado um círculo que circunda todos os ícones do aglomerado e registadoseventos apropriados.

f u n c t i o n Disp lacementManager ( m a r k e r s _ a r r a y , map ) {t h i s . i s _ o p e n e d = f a l s e ;v a r o b j = t h i s ;t h i s . max_ la t = t h i s . max_lng = −999;t h i s . m i n _ l a t = t h i s . min_lng = 999 ;t h i s . c i r c l e C e n t e r L a t = t h i s . c i r c l e C e n t e r L n g = −1;t h i s . map = map ;t h i s . marke r s_ = m a r k e r s _ a r r a y ;

v a r a n g l e _ s t e p = 2 ∗ Math . PI / m a r k e r s _ a r r a y . l e n g t h ;v a r marker ;v a r r and = Math . random ( ) ; / / avoids s e t t i n g an angle to 0 − b e t t e r e f f e c tf o r ( v a r i = 0 ; i < m a r k e r s _ a r r a y . l e n g t h ; i ++) {marker = t h i s . marke r s_ [ i ] ;/ / s e t angle and preca lcu la te displacement pos i t i onsv a r markerAngle = ( i + 1 ) ∗ a n g l e _ s t e p + rand ;marker . d i s p l a c e m e n t P o s i t i o n s = new Array ( ) ;

/ / keep or ig ina l pos i t i on on the f i r s t pos i t i on of the fu ture 10 elementarray

marker . d i s p l a c e m e n t P o s i t i o n s . push ( marker . g e t P o s i t i o n ( ) ) ;f o r ( v a r j = 1 ; j < 1 0 ; j ++) {

v a r l a s t P o s i t i o n = marker . d i s p l a c e m e n t P o s i t i o n s [ j − 1 ] ;v a r n e w _ l a t = l a s t P o s i t i o n . l a t ( ) + 0 .000005 ∗ Math . s i n ( markerAngle ) ;v a r new_lng = l a s t P o s i t i o n . l n g ( ) + 0 .000005 ∗ Math . cos ( markerAngle ) ;marker . d i s p l a c e m e n t P o s i t i o n s . push ( new go og l e . maps . LatLng ( new_la t , new_lng ) ) ;

}

/ / r e g i s t e r some marker eventsgo og l e . maps . e v e n t . a d d L i s t e n e r ( marker , ’ mouseover ’ , f u n c t i o n ( ) { t h i s . s e t Z I n d e x ( 1 )

} ) ;go og l e . maps . e v e n t . a d d L i s t e n e r ( marker , ’ mouseout ’ , f u n c t i o n ( ) { t h i s . s e t Z I n d e x ( 0 )

} ) ;go og l e . maps . e v e n t . a d d L i s t e n e r ( marker , ’ r i g h t c l i c k ’ , f u n c t i o n ( ) { o b j .

o p e n D i s p l a c e m e n t ( o b j . marke r s_ ) } ) ;/ / get min /max l a t i t u d e and longi tudev a r p o s i t i o n = marker . g e t P o s i t i o n ( ) ;v a r l a t = p o s i t i o n . l a t ( ) ;v a r l n g = p o s i t i o n . l n g ( ) ;i f ( l a t <= t h i s . m i n _ l a t ) t h i s . m i n _ l a t = l a t ;i f ( l a t >= t h i s . max_ la t ) t h i s . max_ la t = l a t ;i f ( l n g <= t h i s . min_lng ) t h i s . min_lng = l n g ;i f ( l n g >= t h i s . max_lng ) t h i s . max_lng = l n g ;}

/ / ca lcu la te center coordinates of the polygon bounded by the markerst h i s . c i r c l e C e n t e r L a t = ( t h i s . m i n _ l a t + t h i s . max_ la t ) / 2 ;t h i s . c i r c l e C e n t e r L n g = ( t h i s . min_lng + t h i s . max_lng ) / 2 ;

v a r c i r c l e = new go og l e . maps . C i r c l e ( {c e n t e r : new go og l e . maps . LatLng ( t h i s . c i r c l e C e n t e r L a t , t h i s . c i r c l e C e n t e r L n g ) ,map : t h i s . map ,r a d i u s : 7 ,f i l l C o l o r : ’ # f f f ’ ,f i l l O p a c i t y : 0 . 4 ,s t r o k e C o l o r : ’ # f f f ’ ,s t r o k e O p a c i t y : 0 . 0

91


} ) ;t h i s . c i r c l e _ = c i r c l e ;go og l e . maps . e v e n t . a d d L i s t e n e r (

c i r c l e ,’ mouseout ’ ,f u n c t i o n ( ) {

i f ( o b j . i s _ o p e n e d ) o b j . c l o s e D i s p l a c e m e n t ( o b j . marke r s_ ) ;} ) ;

}

O desencadeamento da animação dos ícones é iniciado pela função a seguir, tal comoregistado nos eventos criados anteriormente.v a r cu r r en tMarke r sAn im = n u l l ;

D i sp lacementManager . p r o t o t y p e . o p e n D i s p l a c e m e n t = f u n c t i o n ( marke r s ) {i f ( cu r r en tMarke r sAn im != n u l l ) re turn ;cu r r en tMarke r sAn im = marke r s ;animateOpen ( 1 ) ;t h i s . i s _ o p e n e d = t rue ;

}

f u n c t i o n animateOpen ( n e x t D i s p l a c e m e n t P o s i t i o n ) {f o r ( v a r i = 0 ; i < cu r r en tMarke r sAn im . l e n g t h ; i ++)

cu r r en tMarke r sAn im [ i ] . s e t P o s i t i o n ( cu r r en tMarke r sAn im [ i ] .d i s p l a c e m e n t P o s i t i o n s [ n e x t D i s p l a c e m e n t P o s i t i o n ] ) ;

i f ( n e x t D i s p l a c e m e n t P o s i t i o n < 9)s e t T i m e o u t ( " animateOpen ( " + ( n e x t D i s p l a c e m e n t P o s i t i o n + 1) + " ) " , 40) ;

e l s e cu r r en tMarke r sAn im = n u l l ;}

De forma semelhante a animação inversa é chamada quando o cursor do rato sai docírculo criado em torno dos ícones.Disp lacementManager . p r o t o t y p e . c l o s e D i s p l a c e m e n t = f u n c t i o n ( marke r s ) {

i f ( cu r r en tMarke r sAn im != n u l l ) re turn ;cu r r en tMarke r sAn im = marke r s ;a n i m a t e C l o s e ( 8 ) ;t h i s . i s _ o p e n e d = f a l s e ;

}

f u n c t i o n a n i m a t e C l o s e ( n e x t D i s p l a c e m e n t P o s i t i o n ) {f o r ( v a r i = cu r r en tMarke r sAn im . l e n g t h − 1 ; i >= 0 ; i −−)cu r r en tMarke r sAn im [ i ] . s e t P o s i t i o n ( cu r r en tMarke r sAn im [ i ] .

d i s p l a c e m e n t P o s i t i o n s [ n e x t D i s p l a c e m e n t P o s i t i o n ] ) ;

i f ( n e x t D i s p l a c e m e n t P o s i t i o n > 0)s e t T i m e o u t ( " a n i m a t e C l o s e ( " + ( n e x t D i s p l a c e m e n t P o s i t i o n − 1) + " ) " , 10) ;

e l s e cu r r en tMarke r sAn im = n u l l ;}

92

Gestão de Equipamentos e Mobiliário Urbano€¦ · FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO...

Documents

Transcript of Gestão de Equipamentos e Mobiliário Urbano€¦ · FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO...