Tese - FCUL - Universidade de Lisboa

Universidade de Lisboa
Faculdade de Ciências
Departamento de Engenharia Geográfica, Geofísica e Energia
Modelação de uma Base de Dados Geográfica para a
série M888, 1:25000 do IGeoE
Agostinho José Caldas de Freitas
Mestrado em Engenharia Geográfica
2008
Universidade de Lisboa
Faculdade de Ciências
Departamento de Engenharia Geográfica, Geofísica e Energia
Modelação de uma Base de Dados Geográfica para a
série M888, 1:25000 do IGeoE
Agostinho José Caldas de Freitas
Trabalho de Projecto Orientado por: Prof. Doutor João Catalão
Mestrado em Engenharia Geográfica
2008
Resumo Os SIG (Sistemas de Informação Geográfica) desempenham um papel
fundamental no Apoio à Decisão, tornando-se numa das áreas de negócio com mais
projecção e desenvolvimento da actualidade. Estes são implementados recorrendo ao
uso de SGBD (Sistemas de Gestão de Bases de Dados) e sendo responsáveis por
armazenar a informação relativa aos objectos e fenómenos que ocorram num dado local
num dado instante, é de extrema importância a escolha adequada da forma como se
organiza, guarda e explora a informação. A Modelação de Dados é assim uma das
etapas mais importantes no projecto SIG, pois o factor chave para o sucesso desse
projecto recai na escolha adequada de um modelo que melhor se ajuste ou descreva a
realidade que pretende reflectir, uma vez que esta realidade é demasiado complexa para
permitir a sua completa e perfeita representação.
Os primeiros modelos de BDG (Bases de Dados Geográficos) apesar de
“expressivos” não permitiam uma adequada representação da realidade uma vez que
este tipo de dados pela sua natureza possui aspectos peculiares como sejam: a sua
localização espacial; o instante de observação; a sua precisão; etc.
Surgiram depois os modelos semânticos e orientados para objectos como por
exemplo: OMT; IFO; ER e mais recentemente, o OMT-G, o GeoOOA, etc... estes
modelos respondem a necessidades específicas, em relação à abstracção de conceitos e
entidades, e quanto ao tipo de entidades representáveis e relacionamento entre estas.
Neste trabalho foram utilizados pacotes de software específicos que permitiram
criar um modelo de dados em linguagem UML, posteriormente exportado para o
formato XML (eXtensible Markup Language) permitindo a partir deste último a geração
da estrutura da BDG.
Depois de gerada foi carregada de modo “automático” recorrendo a uma
metodologia de carregamento criada prepositadamente para esse fim.
O objectivo do trabalho foi Modelar uma BDG para a Carta Militar de Portugal
Continental da série M888 na escala 1:25 000 e implementar a sua utilização na
respectiva cadeia de produção do IGeoE.
Palavras-chave: SIG; Modelação; Base Dados Geográficos; UML; XML
i
Abstract GIS play an important role in any Decision Support System, becoming one of
the most developed and exploited business areas at the moment. Being implemented
according with the use of Database Management Systems (DBMS) and being
responsible for storing the information concerning features and phenomenon that occur
in any location at any time, it is of great importance the adequate choice of the way like
information is organized, kept and exploited. Data modeling is thus one of the most
important stages in a GIS project, therefore the key factor for its success is the adequate
choice of the right model that assures the best adjustment or better describes reality.
Sometimes reality is too much complex to allow it’s complete and perfect
representation.
In such a way data modeling, specifically geographic models are nothing more
than an abstraction of the real world using a set of conceptual tools to better describe
data, its semantics, relations and restrictions in order to produce a well adjusted,
simplified but convenient representation.
The first Geodatabase models although very graphic and meaningful didn’t
allow one adequate representation of reality. That happened because sometimes this
data type, possess a very peculiar nature and certain details like: its spatial location; the
instant of acquisition; its precision; etc.
Later on some semantic and object oriented models appeared, for instance:
OMT; IFO; ER and more recently, the OMT-G, the GeoOOA, etc… these models
answer to specific needs, concerning the abstraction of concepts and features, and how
they relate between them.
In this paper proper software packages had been used to create a data model in
the UML language, later exported to XML creating from this last one the Geodatabase
schema.
After generated it was loaded by “automatic” procedures specially designed for
this end. The main purpose was to design, create and load a Geodatabase for the
Military Chart of the Portuguese Mainland in the M888 series for the 1:25 000 scale and
to implement its use in the proper production workflow in the IGeoE.
Keywords: GIS; Database Modeling; GeoDatabase; UML
ii
Índice Resumo _______________________________________________________________ i Abstract ______________________________________________________________ ii Índice ________________________________________________________________ iii Lista de Figuras _________________________________________________________ v 1. Introdução _______________________________________________________ 1 1.1. Enquadramento Institucional _______________________________________ 2 1.2. O Estado da Arte _________________________________________________ 3 1.3. Metodologia e Organização do Trabalho ______________________________ 6 1.4. Objectivo Final __________________________________________________ 6 2. Concepção de uma Base de Dados Geográfica ___________________________ 8 2.1. Introdução _____________________________________________________ 8 2.2. O UML _________________________________________________________ 8 2.3. A Concepção da BDG (objectos, atributos, relações...) __________________ 11 2.3.1.A Geometria das Entidades ___________________________________ 11 2.3.2.Os Sistemas de Referência ____________________________________ 12 2.3.3.As Entidades e os seus Atributos _______________________________ 12 2.3.4.As Entidades e os Subtipos ___________________________________ 12 2.3.5.As Entidades e as Relações ___________________________________ 12 2.3.6.As Restrições aos Atributos das Entidades _______________________ 13 2.3.7.Validação de Entidades por Regras _____________________________ 13 2.3.8.As Entidades e a Topologia ___________________________________ 13 2.4. A Modelação por Objectos ________________________________________ 14 2.5. Tipos de BD e Tipificação de Workflow ______________________________ 18 2.5.1.Edição directa _____________________________________________ 21 2.5.2.Two level Tree _____________________________________________ 21 2.5.3.Multilevel Tree _____________________________________________ 21 2.5.4.Cíclico ____________________________________________________ 22 2.5.5.Extended History ___________________________________________ 22 2.6. Implementação de Redes na Modelação _____________________________ 22 2.6.1.Solvers ___________________________________________________ 25 iii
2.6.2.Netflags __________________________________________________ 25 2.6.3.Barreiras _________________________________________________ 25 2.6.4.Traçado __________________________________________________ 26 2.6.5.Pesos ____________________________________________________ 26 3. Modelação de uma Base de Dados Geográfica __________________________ 27 3.1. Introdução ____________________________________________________ 27 3.2. A Modelação em UML e a Criação da BDG ___________________________ 28 3.2.1.Criar os Temas _____________________________________________ 30 3.2.2.As Classes e suas Relações ____________________________________ 34 3.2.3.Entidades e atributos, Subtipos ________________________________ 39 3.2.4.Criar uma Rede Geométrica e Regras de Conectividade _____________ 43 3.2.5.Exportação para XMI e Validação Semântica _____________________ 44 3.2.6.Criação da IGeoE_BDG ______________________________________ 46 3.3. Uma Metodologia de Carregamento ________________________________ 49 4. Conclusão _______________________________________________________ 66 4.1. Conclusão _____________________________________________________ 66 4.2. Propostas de Melhoria ___________________________________________ 68 4.3. Propostas para trabalho futuro ____________________________________ 69 iv
Lista de Figuras Figura 1 – Exemplo do processo de Codificação (Encoding) JNITP (NMA) __________ 10 Figura 2 ‐ Exemplo do modelo de mapeamento de GML para XML (ISO19118) JNITP (NMA) ______________________________________________________ 10 Figura 3 – Uso de CASE Tools para concepção e criação do esquema da BDG, ESRI [2000b] _____________________________________________________ 28 Figura 4 – A imagem ilustra as fases da modelação de dados executadas no processo de criação da IGeoE_BDG ______________________________________ 30 Figura 5 – Estrutura base do Modelo disponibilizado pelo CASE Tools (ArcInfo UML Model) _____________________________________________________ 31 Figura 6 ‐ Temas da modelação da série M888 ______________________________ 32 Figura 7 – Tema Terreno________________________________________________ 33 Figura 8 – Tema Região ________________________________________________ 34 Figura 9 – Estrutura Base da IGeoE_BDG (Workspace) ________________________ 35 Figura 10 – Definição das Classes em cada Tema ____________________________ 37 Figura 11 – A Classe Vias de Comunicação _________________________________ 37 Figura 12 – Extracto de algumas entidades das Vias Ferroviárias ________________ 40 Figura 13 – Extracto da Classe Vias Ferroviárias _____________________________ 41 Figura 14 – Rede Geométrica ____________________________________________ 44 Figura 15 ‐ Execução do Add‐On que permite a exportação para o formato XMI ___ 45 Figura 16 ‐ Extracto do ficheiro XMI gerado_________________________________ 46 Figura 17 ‐ Execução da ferramenta Schema Wizard, para a criação da estrutura da IGeoE_BDG __________________________________________________ 47 Figura 18 ‐ Pré visualização da estrutura da BDG a criar. ______________________ 48 Figura 19 – Imagem exemplificativa da aplicação para conversão da informação IGeoE do formato DGN para SHP. _____________________________________ 51 Figura 20 – Imagem exemplificativa dos modelos e respectiva parametrização de ferramentas, criados para conversão da informação do IGeoE (anexo H pp. 3). _________________________________________________________ 52 Figura 21 – Extracto de um relatório (listagem de variáveis e processos) de um dos modelos de conversão da informação do IGeoE. _____________________ 52 Figura 22 – Algumas ferramentas utilizadas na criação automática da BDG Intermédia
___________________________________________________________ 54 Figura 23 – Ferramenta Select para carregamento da IGeoE_BDG _______________ 56 Figura 24 – Extracto da lista de entidades a converter para posterior carregamento na IGeoE_BDG __________________________________________________ 56 Figura 25 ‐ Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das ferramentas: Buffer (A e B) e Intersect (C e D). ___________ 58 Figura 26 ‐ Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das ferramentas: Simplify Line (A) e Collapse Dual Line to Central Line (B). _____________________________________________________ 58 Figura 27 ‐ Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das ferramentas: Buffer (A) e Union (B). ___________________ 59 Figura 28 ‐ Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das ferramentas: Polygon to Line (A) e Splite Line at Vertices (B). 59 v
Figura 29 ‐ Imagem exemplificativa do Aterro (A) e Desaterro (B). para implementação do Modelo de Conversão de Linha a Área. _________________________ 61 Figura 30 ‐ Exemplo dos três tipos de Molhe ________________________________ 61 Figura 31 ‐ Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta: Buffer. _________________________________ 62 Figura 32 ‐ Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta: Polygon to Line e Split Line at Vertices ________ 63 Figura 33 ‐ Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta: Feature to Polygon _______________________ 63 Figura 34 ‐ Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta: Buffer(A) e Erase (B). _____________________ 64 vi
1. Introdução
Os primeiros modelos de dados desenvolvidos foram limitados pelas estruturas
internas dos softwares existentes na altura, forçando o utilizador a ajustar a estes a sua
interpretação dos fenômenos espaciais. Consequentemente, o processo de modelação
não oferecia os mecanismos que permitiriam a representação da realidade de acordo
com o modelo mental desse utilizador. Os modelos de dados semânticos e orientados
por objectos conhecidos, tais como o modelo do relacionamento de entidade (ER)
[Chen,1976], a modelação por objectos (OMT) [Rumbaugh et al, 1991], e o modelo de
IFO [Abiteboul,1987], não oferecem nem facilitam a adequada representação da
informação geográfica. Mesmo que estes modelos sejam expressivos, apresentam sérias
limitações à modelação adequada de tal informação. As dificuldades em usar tais
modelos são incontáveis, uma vez que muitas aplicações geográficas necessitam de
manipular determinados pormenores tais como restrições ao posicionamento, diferentes
épocas de observação, exactidão da aquisição da informação, etc... [Oliveira, 1997].
Além disso, em modelos convencionais é impossível distinguir entre as classes das
entidades que têm uma referência geográfica e as classes puramente alfanuméricas. É
igualmente difícil representar a natureza geométrica das entidades e das relações
espaciais entre eles. As relações espaciais são as abstracções que nos ajudam a
compreender como, no mundo real, as entidades se relacionam [Mark and Frank, 1990].
1
Muitas relações espaciais necessitam ser representadas explicitamente na estrutura da
modelação, a fim de a tornar mais compreensível ou perceptível. As relações
topológicas são também fundamentais para a definição das regras de integridade
espacial [Borges et al, 1999], que por sua vez determinam o comportamento geométrico
das entidades. Existem, no entanto, algumas características específicas da informação
geográfica que tornam a modelação das BDG mais complexa do que as das BD (Bases
de Dados) convencionais.
Modelar os “aspectos espaciais” é fundamental na criação de uma Base de Dados
Geográfica, principalmente porque se trata de uma abstracção da realidade geográfica
onde a percepção que o utilizador possuí do mundo real não é permanente nem
imutável, dependendo também daquilo que este pretende representar e daquilo que
espera ganhar com essa representação.
Pode-se então entender que modelar informação geográfica exige modelos mais
específicos e com melhor capacidade de captura da semântica dos dados geográficos.
Dentro deste contexto geográfico, os conceitos tais como a geometria e a topologia
são importantes na determinação das relações espaciais entre entidades. Estes conceitos
são igualmente decisivos no processo de carregamento de dados, e na execução de
análise espacial.
Este projecto assume as peculiaridades que caracterizam a informação geográfica, as
exigências que um modelo de dados deve possuir para poder ser implementado na
cadeia de produção do IGeoE (Instituto Geográfico do Exército), e tenta responder às
deficiências observadas, propondo um modelo de dados para a escala 1:25 000 (série
M888), baseado na linguagem UML [ESRI, 2000b].
1.1. Enquadramento Institucional
A Missão do IGeoE é a produção de informação geográfica. Para tal, promove e
envida esforços no desenvolvimento de acções: de investigação científica, tecnológica e
outras no domínio da geomática. Nesse sentido e por se tratar de uma entidade nacional
de produção cartográfica, este Instituto mantém-se na vanguarda das ciências
geográficas quer por meio de constantes actualizações tecnológicas, quer por adequada
2
formação dos seus quadros e por criação e implementação de novos processos na área
da produção cartográfica.
A actual cadeia de produção deste Instituto é o resultado de experiências
acumuladas ao longo de vários anos e de sucessivas implementações de melhoramentos
ou refinamentos. Encontra-se, a mesma, optimizada de modo a garantir que os seus
produtos cumprem com os mais altos padrões de qualidade incluindo o cumprimento da
norma de qualidade ISO 9001 no âmbito da concepção, desenvolvimento e produção de
informação geográfica.
A informação geográfica de base produzida pelo IGeoE tem como origem principal
a estereorrestituição fotogramétrica em estações digitais. A informação vectorial depois
de adquirida e processada é então validada do ponto de vista do formato, estrutura,
geometria e topologia, sendo depois guardada para “a posteriori” ser utilizada para os
mais variados fins quer sejam estes de aplicação militar ou civil.
Desde há algum tempo a esta parte que se tem vindo a sentir a necessidade de
possuir uma Base de Dados Geográfica que permita dar resposta:
•
Às necessidades específicas da cadeia de produção da Carta Militar de
Portugal Continental da série M888 na escala 1:25 000.
•
À crescente necessidade de produtos interoperáveis (outros sistemas e
software)
•
Ao suporte a um vasto leque de informação, da mais variada natureza, que
caracteriza o catálogo de produtos que se encontra disponível ao público.
•
E ainda à criação de novos produtos conducentes à satisfação das recentes
necessidades dos nossos clientes.
1.2. O Estado da Arte
A gestão de dados espaciais em SIG é segundo Brinkhoff et al [2006] revestido de
maior importância do que em sistemas convencionais devido à elevada complexidade
dos objectos, às consultas que geralmente se efectuam e ao enorme volume e
complexidade dos dados geralmente associados.
3
As Bases de Dados Geográficas impõem restrições severas às arquitecturas de
armazenamento e acesso (índices) de dados, com o objectivo de se obter um
processamento das consultas não só célere como eficaz.
Os SGBD Relacionais estão melhor preparados para tratar dados convencionais,
apresentando algumas deficiências quando utilizado para armazenamento de dados
espaciais. Para entender o problema, Brinkhoff [2006] propõe que o objecto espacial
seja caracterizado por duas componentes: a espacial e a temática. A componente
espacial refere-se à representação do objecto no plano através de pontos, linhas ou
polígonos. Enquanto que a componente temática caracteriza o objecto segundo outros
atributos que podem ser do tipo qualitativo ou quantitativo, respectivamente e a título de
exemplo o tipo de uso do solo, ou a precipitação numa dada região.
Devido à arbitrária complexidade dos objectos espaciais, é impossível construir um
índice considerando informações completas sobre a extensão dos objectos. A solução
adoptada baseia-se no princípio de que o método não produz, na verdade, o resultado da
consulta, mas apenas filtra e refina os dados gerando conjuntos cada vez menores a
serem consultados e, a partir de outros processos, obter então o resultado. De modo
diferente das BD convencionais, esse resultado, por sua vez, necessita ser também ele
guardado para permitir análises posteriores.
Já Engenhofer [2006] refere a necessidade de uma linguagem para consultas
espaciais em BD que preserve os conceitos da linguagem SQL, manipule objectos
espaciais e incorpore operações e relacões espaciais. Duas regras são necessárias para a
definição da linguagem de consulta e de apresentação (de resultados):
•
a linguagem deve abstrair as características do armazenamento e da
implementação
•
o resultado de uma consulta espacial não pode ser apenas uma relação
(tabela) sem expressão espacial.
Este autor define também onze requisitos necessários para uma linguagem de
consulta espacial. Dentre os quais, se destacam dois:
•
A necessidade de mostrar o resultado de uma forma gráfica (a linguagem
GML (Geography Markup Language) como resultado permitirá que as
informações sejam apresentadas de uma forma visual num formato livre.
4
•
Inclusão de informação adicional associada ao contexto, essencial para a
interpretação do resultado (ex. uma dada consulta sobre a distribuição da
localização de Esquadras de Polícia num distrito do país deve mostrar, além
do posicionamento das mesmas, as localizações de bairros ou zonas mais
problemáticas desse mesmo distrito, outras instalações de Forças de
Segurança ou suas equiparadas).
Segundo Tian et al [2005] prevalecem cinco estratégias de armazenamento do XML.
Essas avaliações levaram em conta a performance de consultas. O método de acesso
mais comum entre as Bases de Dados Geográficas é o RTree, que é aplicado às
estruturas bidimensionais simples, formadas pelo rectângulo envolvente dos objectos e
organizadas em árvores, onde se utiliza este rectângulo e se obtém uma hierarquia de
níveis sucessivos de objectos neles contidos.
Também Ruberg et al [2007] avalia diversas estratégias de armazenamento e propõe
uma nova estratégia utilizando as Bases de Dados Objecto-Relacional. A mesma ideia
foi proposta por Klettke [2006] e o pelo formato de representação DOM (Document
Objetct Model) para o mapeamento entre as tecnologias XML e SGBD ObjectoRelacional.
Ruberg, bem como outros autores, sugerem a consulta através de uma conversão da
XQuery (XML Query Language) para SQL3. As regras de conversão da XQuery em
SQL3 (Structured Query Language) foram escritas com a tecnologia XSLT (eXtensible
Stylesheet Language Transformation). Ruberg explica que o mapeamento da XML em
SGBD Relacional implica a criação de estruturas auxiliares que geram comandos SQL e
um número excessivo de junções (joins), tornando a consulta extremamente dispendiosa
em termos de tempo de execução. Se for utilizado uma BD Objecto-Relacional, haverá
maior transparência entre os dois modelos e isso reduz significativamente o impacto da
transição, que, por sua vez, diminui o número de estruturas auxiliares e facilitando a
tradução da linguagem de consulta. Esta proposta baseia-se no armazenamento do XML
no formato DOM (Document Object Model).
Outra proposta, para atender às necessidades específicas dos SIG, prevê a utilização
dos ficheiros XML escritos em GML sendo a linguagem de consulta escolhida a
XQuery com a extensão GML-QL (Spatial Query Language Specification for GML)
5
proposta por Vatsavai [2006] sendo tudo isto implementado numa BD ObjectoRelacional Oracle com extensão espacial.
1.3. Metodologia e Organização do Trabalho
Este trabalho está estruturado em 4 capítulos. O primeiro capítulo faz uma breve
introdução ao tema, efectuando o enquadramento na instituição que o acolhe, uma breve
descrição do estado actual do conhecimento no que toca à modelação de Bases de
Dados Geográficas culminando com a referência ao objectivo final a atingir.
O Capítulo II (Concepção de uma BDG) aborda, os princípios subjacentes à
construção de uma BDG e a sua estrutura base em linguagem UML, a modelação por
objectos seus princípios e implementação, a tipificação das Bases de Dados e dos
Workflows da sua utilização, sendo também abordada a implementação de redes
geométricas e lógicas.
O Capítulo III (Modelação de uma BDG para a série M888) apresenta o trabalho
realizado nas fases de modelação em UML da BDG, da sua criação e posterior
metodologia de carregamento.
O Capítulo IV (Conclusões) traduz-se numa síntese conclusiva e indica ainda
propostas de melhoria, bem como futuros trabalhos a desenvolver.
Existe ainda um conjunto de outros documentos anexos, que contêm não só
informação que melhor ilustra o modelo conceptual concebido mas também outros
documentos considerados relevantes e igualmente utilizados durante a produção deste
trabalho, como sejam os modelos de carregamento e conversão.
1.4. Objectivo Final
Pretende-se, aquando da conclusão do presente trabalho, obter a Modelação de uma
Base de Dados Geográfica para a Carta Militar de Portugal Continental da série M888
na escala 1:25 000.
Neste contexto é também proposto como objectivo a criação de uma BDG
(IGeoE_BDG), a ser integrada na cadeia de produção do IGeoE, gerada a partir do
6
referido modelo. É ainda objectivo a criação não só da metodologia bem como os
respectivos modelos de carregamento automático.
Espera-se deste modo contribuir para a actualização e optimização da cadeia de
produção, com uma nova abordagem, novos processos e metodologias de trabalho de
modo a dar resposta às necessidades apontadas.
Prover o mercado com novos produtos, mais apelativos, com maiores
potencialidades e com procura crescente.
7
2. Concepção de uma Base de Dados Geográfica
2.1. Introdução
Neste capítulo pretende-se abordar de uma forma sucinta mas clara, a problemática
inerente à construção de uma BDG com recurso à linguagem UML. A modelação por
objectos, juntamente com os seus princípios e implementação, a tipificação das Bases
de Dados e dos respectivos Workflow, sendo também abordada a problemática
associada à implementação de redes.
2.2. O UML
Na sequência de ínumeras comparações e apreciações entre várias linguagens de
modelação, o UML foi seleccionado para as normas da família ISO 19100 (elaboradas
pela ISO/TC 211) para os diagramas de estrutura estática e a UML OCL (Object
Constraint Language) como linguagem para os esquemas conceptuais de especificação
das partes normativas. A selecção da linguagem e a sua aplicação foram objecto de um
8
documento normativo (Technical Specification) designado 19103 – Geographic
Information – Conceptual Schema Language.
Se nalguns dos documentos normativos a utilização de UML não apresenta
expressão significativa, já noutros, como na norma relativa à definição dos metadados
(19115 – Geographic Information – Metadata), a sua utilização é feita de forma
exaustiva e muito evidente.
O que justifica a utilização do UML nos documentos normativos é o facto de estes
procurarem traduzir de forma simples, organizada e sucinta os esquemas normativos.
Desse modo poderão ser implementados de um modo mais rápido e fácil pelas
existentes linguagens de programação (processo designado por codificação ou
encoding).
Como será lógico pensar, nas situações onde a aplicabilidade de uma tal codificação
é óbvia, como a da norma relativa aos metadados, a utilização desta linguagem
apresenta um enquadramento natural. Já em normas como as da qualidade (ISO 19113 e
19114) a utilização de UML afigura-se desnecessária excepto na ligação à norma dos
metadados.
A importância da utilização do UML para codificação é mais interessante do ponto
de vista operacional na norma 19118 – Geographic Information – Encoding. Neste
documento são definidas regras para codificação a partir de esquemas UML que
conduzem à sua codificação em XML.
No entanto, recentemente, foi apresentada a proposta de integração de uma norma
proveniente da OGC (Open GIS Consortium), ao abrigo do protocolo de colaboração
entre esta organização e a ISO/TC 211, para um perfil de XML designado por GML que
conhecerá, previsivelmente, uma grande expansão.
Um conjunto de vários países (Finlândia, Noruega, Dinamarca, Suécia e Islândia)
liderados pela NMA (Norwegian Mapping Authority) propôs-se como objectivo
verificar a capacidade de utilização (veja-se a figura 1) e avaliação de benefícios na
utilização do modelo proposto pela ISO/TC 211 como norma de interoperabilidade
(Joint Nordic Implementation Test Project, veja-se a figura 2).
9
Figura 1 – Exemplo do processo de Codificação (Encoding) JNITP (NMA)
Figura 2 - Exemplo do modelo de mapeamento de GML para XML (ISO19118) JNITP (NMA)
10
Até à altura as conclusões publicadas são:
•
A experiência mostra que é possível a utilização de ferramentas para a
automatização da geração do XML Schema baseado numa modelação
(application schema) concebida em UML e fazendo uso das XML Encoding
rules.
•
Em alguns pontos os diagramas em UML ou não são explícitos o suficiente
ou não permitem obter uma modelação conveniente.
Em suma e tendo em vista uma avaliação objectiva e imparcial pode-se concluir que
as normas necessitam de ser revistas e melhoradas se no futuro se pretender atingir o
objectivo da interoperabilidade.
2.3. A Concepção da BDG (objectos, atributos, relações...)
As entidades geográficas que diariamente são observadas podem possuir uma
enorme quantidade de informação de contextualização passível de armazenamento
sendo exemplo disso não só a sua localização, a natureza dos materiais que a
compõem,o facto de possuir outros objectos circundantes, o modo de interacção com
estes, etc... Os valores que os atributos podem possuir podem ser desde os mais simples
valores numéricos, limitados por domínios de valores (um máximo e um mínimo) por
categorias destes (valores pré-definidos) ou simplesmente descritores (qualificando uma
entidade específica p.e. betão, ferro, etc...).
As entidades geográficas, enquanto elementos representados no modelo de dados da
BDG, podem assumir várias formas (dentro da liberdade admitida pela sua geometria),
vários relacionamentos, atributos e comportamentos. Estas caracteristicas são
expressivas da riqueza de contexto que as entidades geográficas podem assumir
colectivamente. Em muitas situações, as entidades representadas como vector são a
respresentação de dados geográficos mais usual e que permite a maior versatilidade,
normalmente este tipo é utilizado para as entidades que têm limites bem visíveis e
marcados. Outras entidades geográficas que podem ser consideradas fenómenos
contínuos são melhor modelados com imagens Raster ou modelos TIN (Triangular
Irregular Network).
2.3.1. A Geometria das Entidades
11
A geometria de uma entidade é armazenada num campo específico (do tipo
geometria), numa tabela da respectiva entidade. Uma entidade pode assumir qualquer
um destes tipos de geometria:
• Pontos ou multipontos (que são um conjunto de pontos).
• Linhas, um conjunto de segmentos de recta que pode ou não estar conectado.
• Polígonos, um conjunto de anéis que podem estar separados ou encaixados. Um
anel não é mais que um conjunto de segmentos de recta onde não existe intercecção mas
que se encontram conectados e fechados.
2.3.2. Os Sistemas de Referência
A geometria de uma entidade é armazenada num campo que representa a posição
(x,y) num sistema de referência previamente definido que pode ser cartográfico/
geodésico ou cartesiano rectangular.
2.3.3. As Entidades e os seus Atributos
Uma entidade armazena os seus atributos como campos numa tabela pertencente à
referida entidade. As tabelas referidas são tabelas pertencentes a uma base de dados
relacional. Os atributos definem propriedades padrão ou específicas das entidades e
podem ser numéricos, do tipo texto, ou simplesmente descritivos.
2.3.4. As Entidades e os Subtipos
As entidades são agrupadas em classes normalmente por existir homogeneidade de
atributos ou métodos. Uma classe que defina p.e. edifícios pode logicamente ser
subdividida em subtipos tais como habitação, habitação precária, comércio, industria,
etc... (veja-se o modelo de dados produzido). Os subtipos permitem ainda aumentar o
controlo sobre outros atributos (ou entidades) inerentes, tal como seja o domínio de
valores que os atributos podem assumir.
2.3.5. As Entidades e as Relações
Todas as entidades geográficas estabelecem algum tipo de relação com outras
entidades. Podem-se definir relacionamentos explícitos entre entidades geográficas
dentro de uma classe e entre classes. Pode-se ainda igualmente definir relacionamentos
entre entidades não geográficas (o caso tipicamente utilizado da casa e o seu
proprietário, definidos na mesma BDG ou fazendo parte de BD diferentes).
12
2.3.6. As Restrições aos Atributos das Entidades
Quer seja para guardar valores de levantamento de informação (com elevada
precisão), para tipificação de uma classificação ou qualquer outro, cada atributo de uma
entidade pode ter um domínio de valores, quer seja uma escala numérica ou uma lista de
valores válidos. Cada atributo pode igualmente ter um valor por defeito atribuído,
automaticamente, quando uma entidade é criada. Pode-se inclusivé ajustar domínios de
valores distintos bem como valores por defeito diferentes para cada subtipo de uma
classe.
2.3.7. Validação de Entidades por Regras
A existência das entidades quer seja no momento da sua criação, da sua modificação
ou da sua eliminação segue regras específicas.
Podem-se usar regras para restringir o modo como os diferentes elementos de uma
rede são conectados, definir a sua cardinalidade ou os relacionamentos implementados.
Um exemplo da validação por regras insere-se no exemplo atrás referido das casas e dos
respectivos proprietários pois este relacionamento pode ser restringido a dois
proprietários por casa.
2.3.8. As Entidades e a Topologia
Muitos tipos de entidades têm um relacionamento muito específico que pode ser
caracterizado como topologia.
Veja-se o exemplo das propriedades no meio urbano, no conjunto todas elas
definem uma dada área (freguesia, distrito, etc...) devem no entanto ser exactamente
contíguas (conexão inequívoca), sem aberturas ou sobreposições.
Porque as entidades geográficas existem e se encontram inseridas num contexto com
topologia, sistemas de referência, relacionamentos, etc... tem-se um número de decisões
para tomar quando se efectua o modelo de dados da BDG.
Pode-se trabalhar com apenas uma ou ínumeras BDG, mas em determinadas
situações agrupar ou separar conjuntos de entidades geográficas é uma solução de
optimização frequente. Estas são algumas das razões que justificam o agrupar de
entidades numa mesma BDG:
•Um conjunto dos objectos e entidades que possuem relacionamentos.
13
•As entidades que têm associações topológicas.
•Entidades
que
por
razões
próprias
necessitem
ser
editadas
simultâneamente. Podem existir várias BD, mas pode-se editar somente uma
destas de cada vez, por posto de trabalho.
Sendo as que de seguida se apresentam algumas razões para separar um conjunto de
entidades em BDG distintas:
• Se estamos perante uma grande organização (p.e. IGeoE), tendo os
diferentes departamentos (DAD, DPD, etc..) responsabilidades por cada
pacote de dados por eles produzido as BD podem ser desdobradas para
seguir a estrutura interna da organização.
• Liberdade total sem restrições em tamanho ou número para usar todas as
bases de dados relacionais que se considerem necessárias (dependendo da
área de negócio p.e. DataWarehouses de uma grande empresa como seja o
grupo Sonae ).
• Por questões de licenciamento quando se utiliza uma BDG do tipo Access,
os limites práticos do tamanho podem exigir uma divisão da informação por
várias BDG (slice).
2.4. A Modelação por Objectos
Um modelo de dados de uma BDG é uma abstracção do mundo real que utiliza um
conjunto específico de informação, neste caso do tipo geográfica, para dar suporte a:
visualização, edição, análise, etc...
O modelo de dados do CAD, desde a década de 60 e 70 armazenava a informação
relativa aos dados geográficos dentro de ficheiros em formato binário com
respresentações para pontos, linhas e áreas.
O subterfúgio encontrado para guardar a informação sobre os atributos, das
entidades, foi a categorização destas e a sua distribuição pelos níveis, com tipos de
linhas, espessuras e cores específicas para cada categoria da informação. As anotações
funcionavam como se tratasse de representações preliminares dos atributos.
14
O novo modelo de dados orientado por objectos permite ao utilizador criar as suas
próprias entidades definindo atributos, restrições, comportamentos e permitindo que se
estabeleçam relacionamentos entre entidades.
Mais, o modelo de dados da BDG permite que sejam definidos a grande maioria
dos comportamentos que as entidades possuem, sem escrever uma única linha de
código. A maioria dos comportamentos são definidos com recurso aos domínios, às
regras da validação e as outras funções de estrutura [ESRI, 2000b].
Para se entender como um modelo de dados orientado por objectos é importante
notem-se as vantagens da sua utilização:
Quando se adicionam entidades geográficas à base de dados, o utilizador quer
assegurar-se de que as entidades estejam colocadas correctamente, de acordo com
determinadas regras, tais como:
•
Que os valores que o utilizador carrega para os atributos da nova informação
se encontrem dentro de um conjunto pré-definido de valores permitidos. Por
exemplo uma estrada ou é classificada como larga ou como estreita, os
molhes são de betão, ferro ou madeira, etc...
•
Que uma entidade pode ser colocada de modo adjacente, conectada ou
sobreposta a uma outra entidade somente se determinadas condições forem
encontradas. Por exemplo uma estrada nacional não possuí cruzamentos ou
entrocamentos de nível com uma autoestrada, pois é o que se encontra
definido por Decreto-Lei em Diário da República.
•
Que a geometria de uma entidade segue a sua colocação lógica. Por exemplo
a conexão entre as linhas e as curvas que compõem uma estrada devem ser
tangentes entre elas. Os cantos dos edifícios possuem na generalidade dos
casos ângulos rectos.
Todos os objectos que existem na superfície terrestre possuem um qualquer tipo de
relacionamento com outro objecto. Da perspectiva dos SIG, estes relacionamentos
podem ser categorizados em: topológicos, espaciais e gerais [ESRI, 2000e]. Estes são
alguns exemplos de cada um destes tipos de relacionamentos:
•
Quando se editam as entidades intervenientes num sistema rodoviário, as
estradas nacionais cruzam as IP e as IC, para passar destas para as
autoestradas definem-se acessos próprios, etc... e isso permite a execução à
15
posteriori da análise de traçado dessa rede. Um conjunto de relações
topológicas está previamente definido para que se possam carregar ou editar
as entidades intervenientes dentro de um sistema conectado mantendo a
integridade do mesmo.
•
Quando se trata de castelos ou fortes, capelas, faróis, VG (vértice
geodésico), etc... pretende-se definir que podem existir VG nos castelos, nas
capelas e nos faróis. Que um castelo pode conter uma capela e um VG ou
existir um capela ao lado de um farol com um VG sobreposto. Uma vez que
uma das funções dos SIG é a determinação se uma entidade está: dentro de,
fora de, sobreposto ou tangencial a outra entidade. Os relacionamentos
espaciais são inferidos a partir da geometria das entidades.
•
Algumas entidades possuem relacionamentos que não são visiveís na
cartografia, visto que algumas não são entidades de natureza geográfica (p.e.
o proprietário de determinada entidade).
•
Quando se constrói uma linha de contorno, pretende-se que a sua elevação
seja registada ao longo do comprimento da mesma, digamos por exemplo
em intervalos regulares de n milímetros.
•
Quando se efectua a extracção das estradas, pretende-se que esta seja
extraída como linhas paralelas com intersecções adequadas onde quer que se
encontrem cruzamentos com outras estradas (de acordo com uma prioridade
e hierarquia de estradas previamente definidas).
A modelação orientada por objectos como atrás se referiu permite uma melhor
caracterização das entidades, dos relacionamentos por elas estabelecidos, dos
comportamentos apresentados, etc. Alguns dos benefícios da utilização deste tipo de
modelo de dados, são:
•
Um repositório uniforme e homogéneo de dados geográficos.
•
Tanto a introdução de dados como a sua edição são mais céleres e menos
dados a erros grosseiros, que a maioria das vezes podem ser impedidos
apenas por processos de validação ou controlo de qualidade (adicionando
mais tempo e complexidade a todo o processo). Para muitos decisores,
apenas esta razão é suficiente para justificar a adopção deste tipo de modelo.
•
Os utilizadores trabalham com objectos mais intuitivos, estas BDG contêm
informação que melhor se aproxima ao modelo lógico do utilizador em que
16
se substítui os pontos genéricos, linhas e áreas por objectos com os quais
qualquer utilizador se identifica mentalmente (p.e. casas, estradas, lagos,
rios, pontes, etc...).
•
As entidades por possuírem uma grande quantidade de informação de
contexto que pode interessar guardar (associações topológicas, representação
espacial, relacionamentos, comportamentos,etc...) o utilizador pode definir
neste tipo de modelo não só o que caracteriza as entidades, mas também a
sua interacção com outras entidades. Isto permite especificar o que acontece
às entidades quando uma entidade relacionada é adicionada, alterada, ou
simplesmente removida.
•
Vários
utilizadores
podem
editar
os
mesmos
dados
geográficos
simultâneamente. Este modelo de dados permite fluxos de trabalho onde
vários utilizadores podem editar entidades de um mesmo local ou região
geográfica, efectuando a harmonização da informação resolvendo quaisquer
conflitos daí emergentes.
É ainda de referir que o utilizador que define o modelo de dados orientado por
objectos o efectua recorrendo a classes próprias pré-concebidas para o efeito,
normalmente designadas por geodatabase data access objects.
Existem três alicerces para executar uma boa modelação por objectos:
polimorfismo, encapsulamento e a herança.
•
O polimorfismo significa que os comportamentos (ou métodos) de uma
classe de objectos podem adaptar-se a variações desses mesmos objectos.
Por exemplo, para um método que seja definido numa classe mãe pode-se
proceder à sua implementação, idêntica ou parcialmente modificada, noutra
classe filha.
•
O encapsulamento significa que um objecto só se encontra acessível através
da elaboração de um conjunto de métodos bem definidos e organizados em
interfaces. Os geodatabase data access objects escondem os atributos dos
dados e fornecem um interface de programação padrão.
•
A herança significa que uma classe de objectos pode ser definida para incluir
o comportamento de outra classe de objectos incluir comportamentos
17
adicionais. Podem-se criar ainda novas entidades que herdam o
comportamento das entidades padrão.
2.5. Tipos de BD e Tipificação de Workflow
Algumas das BDG em uso na actualidade são projectos a longo prazo conjugando
esforços de cooperação de um grande número de utilizadores e departamentos de várias
instituições e organizações.
Estas organizações estabelecem o workflow dos processos para o desenho, a
construção, e a manutenção das respectivas BDG.
As etapas gerais incluem:
•
Concepção inicial
•
Exploração de alternativas à concepção inicial.
•
Selecção e aprovação.
•
A construção.
•
Actualização com o carregamento das entidades tal como foram concebidas.
Quando se usa um SIG nestas condições, é necessário que as várias utilizadors
possam editar em simultâneo a mesma BDG. Igualmente necessitam ter acesso a uma
visualização da BDG de modo a que somente as mudanças que os próprios ou seus
colegas de equipa façam estejam visíveis e disponíveis. Mais, a estrutura do workflow
necessita replicar as práticas empresariais correntes dos vários departamentos numa
organização. Estas necessidades são satisfeitas através da gestão de dados num esquema
designado por versioning, ou versionamento.
Este permite criar várias versões de uma BDG tantas quantas as áreas de negócio ou
os departamentos de uma dada organização, harmonizar diferenças entre versões, e
actualizar a versão base (master) de uma BDG à medida que esta for sendo construída.
De seguida são apresentados alguns dos benefícios mais relevantes referentes ao
armazenamento de dados geográficos em BD:
•
Possibilidade de integração de dados geográficos com BD de outra natureza.
•
Possibilidade de usar ferramentas usuais de administração de sistemas para
administrar a informação geográfica.
18
•
Possibilidade de criar BDG muito grandes das quais rapidamente se pode
efectuar o display e edição da informação.
•
Possibilidade de desdobrar as BDG numa outra base de dados relacional
qualquer à escolha do utilizador.
•
Possibilidade de incluir grande variedade de dados geográficos destinados a
uma também grande variedade de clientes, tais como: aplicações CAD,
aplicações Web, aplicações para dispositivos móveis, etc...
Estas são algumas das capacidades (geográficas) adicionadas à BD:
•
Pode-se armazenar e representar informação geográfica sob a forma de
imagens raster, vector, modelos TIN, etc.
•
Permite executar operações de análise espacial e topológica.
•
Permite a visualização e produção de cartografia de elevada qualidade.
•
Permite definir e utilizar entidades, definindo atributos, associações
topológicas, relacionamentos e regras de validação.
•
Permite que vários utilizadores visualizem e editem em simultâneo a
informação relativa à mesma região geográfica.
As transações numa BDG servem para preservar a consistência e a integridade da
informação assegurando-se de que todas (ou nenhumas) operações sejam executadas
para a conclusão de uma tarefa (modificação, eliminação, etc...).
As bases de dados relacionais satisfazem estas exigências recorrendo a transações
curtas, que representam as tarefas que podem ser terminadas nas fracções de um
segundo, ou um minuto ou dois no máximo. Este tipo de transacções são indicadas para
sistemas como os atrás referidos, que exigem o acesso imediato à informação, em que o
histórico não é importante ou se o é garante-se por parte de outros sistemas, mas a
informação geográfica exige um outro tipo de transacções que lhe permita manter a
ligação por mais tempo de modo garantir outro tipo capacidades (actualização da
informação, histórico, etc...).
No respeitante à edição de dados enquanto uma transação curta for executada, a base
de dados relacional impede o acesso às tabelas de modo que os dados que são
actualizados estejam protegidos das mudanças até que a transação esteja completa.
Quando a transação curta é terminada, as tabelas são libertadas. Quando múltiplos
utilizadores editam simultâneamente dados geográficos, este tipo de bloqueio de tabelas
19
são pouco práticos porque podem durar longos intervalos de tempo (vários minutos).
Uma outra razão pela qual o bloqueio é nefasto, é quando as entidades coexistem com
outras ou possuem relacionamentos activos e porventura um colega de equipa se
encontra a editar o mesmo tipo de informação, digamos p.e. a rede viária, esta situação
leva a que de dê a perda de informação uma vez que não é possível harmonizar as
diferenças com este tipo de transacções. Uma outra razão pela qual as transações curtas
não são adequadas num ambiente de edição empresarial do tipo multiutilizador é que
não permitem a constante visualização de modo actualizado da informação contida na
base de dados. Cada vez que algum outro elemento da equipa efectuasse uma alteração,
o sistema teria de actualizar a visualização em todos os outros utilizadores não sendo
aceitável este tipo de funcionamento.
O que é necessário para que vários utilizadores editem dados geográficos em
simultâneo da mesma área geográfica é a execução de um outro tipo de transações, as
denominadas longas, que permitam efectuar o seguinte:
•
Edição simultânea por parte de vários.
•
Visualização de dados correspondentes a perfis de utilizadores, de modo a
que se possa efectuar qualquer tipo de verificação ao trabalho efectuado por
cada um.
•
Licenciamento diferenciado consoante as necessidades de cada utilizador.
A utilização do versionamento começa agora a ser de uso generalizado pois permite
uma melhoria do desempenho, maior fiabilidade e facilidade de uso do que os sistemas
precedentes da gestão de dados. A razão da preferência pelo versioning basea-se na
necessidade crescente de executar os trabalhos mais rápido e por menos custos. Isto
porque a sua implementação implica que as versões não exijam nenhuma duplicação ou
réplica dos dados apesar de se possuir uma numerosa equipa a trabalhar toda na mesma
área. Internamente, usam-se identificadores e controladores de tabelas adicionais que
gravam a informação relativa às entidades adicionadas, removidas ou modificadas.
Quando se aplica este tipo de BD a uma organização, pode-se selecionar um dos
diversos tipos de fluxos de trabalho, conforme combinem melhor com as práticas usuais
estabelecidas.
20
Segue-se uma descrição sumária dos vários tipos de fluxo de trabalho suportados
pelo versioning. A sua implementação pode corresponder a um ou a uma combinação de
qualquer destes fluxos apresentados.
2.5.1. Edição directa
É o fluxo de trabalho mais simples para o acesso multiuser em que a BDG é para
muitos utilizadores acedida directamente e edita-se a versão por defeito. Porque cada
utilizador acede à versão por defeito para editar, é criada uma versão provisória. Este
utilizador não possuí indicações explicitas de que uma nova versão está a ser criada.
Sempre que o utilizador guarda o trabalho, essa versão provisória é harmonizada com a
informação existente e então automaticamente é substítuida na versão por defeito. Se
existirem conflitos, devem ser resolvidos antes que se possa guardar com sucesso o
trabalho efectuado. Se nenhum conflito for detectado, a substituição na versão por
defeito é realizada directamente.
Este fluxo de trabalho tem a principal virtude da sua simplicidade. É o mais
apropriado para organizações de pequena envergadura (ou parcos recursos) onde não
foram ponderadas nem exploradas alternativas e onde os históricos são “religiosamente”
executados.
2.5.2. Two level Tree
Muitas organizações utilizam outro tipo de fluxos de trabalho mais elaborados que
permitem manter e analisar registos relativos a tarefas específicas de adição de
informação, operações de manutenção, registo de intervalos de tempo utilizados para
executar tarefas, etc. Quando um projecto de trabalho é iniciado, é criada uma versão de
trabalho. Os vários utilizadores trabalham nessa versão até que o projecto termine, nesse
ponto, a harmonização da informação é efectuada fundindo a informação de todos os
utilizadores na versão final que se criará, após o que a versão de trabalho será
eliminada.
2.5.3. Multilevel Tree
Os projectos de algumas organizações têm um nível mais alto de especialização e
podem ser subdivididos em partes funcionais ou geográficas. Por exemplo, um projecto
do tipo MGCP (Multinational GeoSpatial Co Production Program) com o objectivo de
mapear (SIG-2D) grande parte da superfície terrestre, é lógico que seja subdividido,
21
neste caso em células de 1º por 1º, agrupado por zonas e atríbuido a diferentes equipas
(países) para execução. Para este tipo de projectos de grande envergadura (e para isso
basta incluir alguns departamentos e várias equipas), este tipo de fluxo de trabalho é um
modo muito eficaz de organizar o projecto. Uma vez que permite às equipas que estão a
trabalhar em cada um possusir a sua própria versão, com que podem manter uma
visualização confidencial do seu trabalho e divulgar apenas aquando da cocnclusão do
projecto.
2.5.4. Cíclico
Muitos projectos atravessam um conjunto pré estabelecido de fases que exigem uma
aprovação prévia antes de prosseguir para a fase seguinte. Cada versão representa cada
fase deste processo. Um fluxo de trabalho cíclico assim estabelecido actualiza a versão
por defeito quando o último estágio for alcançado e terminado. Esta versão por defeito
agora actualizada representa o estado normal da base de dados.
Este fluxo de trabalho poupa o esforço de progressivamente afixar novas versões ao
longo de todas as fases; pode-se contornar esta situação e afixá-la directamente à versão
por defeito ou a qualquer outra versão.
2.5.5. Extended History
Em alguns projectos, é desejável preservar uma versão que reflita todo o histórico de
um projecto. Pode-se definir uma versão histórica numa versão do projecto, e quando a
versão do projeto é anexada à sua versão que lhe deu origem, a versão histórica
permanece apenas como um instantâneo no tempo (semelhante a um Data Mart).
2.6. Implementação de Redes na Modelação
A rede geométrica é definida como um conjunto de entidades que participam
num sistema linear. E é normalmente associada com as redes lógicas, que não passam
de um gráfico puro da rede consistindo num conjunto de segmentos e pontos de ligação
(edges e junctions, respectivamente).
22
Juntas, estas duas representações de uma rede fornecem uma boa solução para
armazenamento e análise de sistemas lineares.
As redes geométricas como referido são compostas por segmentos e pontos de
ligação. Um segmento tem dois pontos de ligação e um ponto de ligação pode ser
conectada a um sem número de segmentos. Os segmentos podem sobrepor-se no espaço
bidimensional sem se intersectarem. Um bom exemplo disso é uma ponte sobre uma
estrada. As entidades que representam segmentos e pontos de ligação são chamadas de
entidades da rede. Somente as entidades da rede podem participar numa rede
geométrica. Uma classe das entidade da rede é uma colecção homogênea de um destes
tipos de entidades da rede: entidade simples da junção, entidades complexa da junção,
entidade simples do segmento, ou entidade complexa do segmento. Mais de uma classe
da rede pode representar um papel topológico dado numa rede geométrica. Cada classe
da rede é associada com apenas uma rede geométrica. As entidades de uma rede
geométrica, têm todas as mesmas características que as outras entidades:
•
Podem-se criar tantas classes como as necessárias. Podendo-se adicionar
os atributos julgados pertinentes.
•
Podem-se definir subtipos e aplicar valores por defeito, atribuir domínios
e comportamentos específicos.
•
Podem-se estabelecer também relacionamentos entre entidades da rede e
qualquer outra entidade.
De referir que as entidades da rede têm comportamentos específicos adicionais
responsáveis por preservar a conectividade e actualizar automaticamente os elementos
da rede.
Como uma rede geométrica, uma rede lógica é um conjunto de segmentos e de
pontos de ligação ligados entre si. A diferença reside no facto de que uma rede lógica
não possuí coordenadas associadas pois a sua finalidade principal é armazenar a
informação sobre a conectividade da rede junto com determinados atributos.
Uma vez que os segmentos e pontos de ligação numa rede lógica não possuem
geometria, não são entidades, mas sim elementos. Existe uma cardinalidade de um-paraum ou de um-para-muitos nas relacões entre entidades da rede numa rede geométrica e
numa rede lógica.
23
Uma rede geométrica é associada sempre a uma rede lógica. Os elementos da
rede lógica são automaticamente actualizados quando se editam as entidades. Esta
última não costuma aparecer directamente nas aplicações de uso mais generalizado e é
com a geométrica que se interage. A rede lógica é por assim dizer a base que define o
comportamento das entidades na rede.
O pilar de uma rede lógica é a tabela de conectividades, pois descreve como os
elementos da rede são conectados. Para cada ponto de ligação na rede, a tabela de
conectividades lista os pontos de ligação adjacentes, os segmentos intervenientes e
ainda os pontos de ligação no extremo oposto do segmento a que está ligado.
É recorrendo à tabela de conectividade que a rede geométrica mantem a sua
integridade.
Relativamente às regras de conectividade verifica-se que na maioria das redes,
nem todos os segmentos se podem ligar a outros pontos de ligação. Também, nem todos
os segmentos se podem ligar aos outros segmentos restantes através de um ponto de
ligação específico.
Estas mesmas regras de conectividade da rede restringem o tipo e número de
entidades da rede que podem ser conectadas a outras. Permitem ainda e de um modo
fácil manter a integridade das entidades da rede geométrica pois em qualquer momento
é possível efectuar a validação das entidades na BDG e gerar os relatórios a respeito
dessas entidades relativamente ao cumprimento de regras de conectividade ou outras.
Seguem-se alguns exemplos de regras de conectividade para entidades
pertencentes a uma rede:
•
Regra Segmento-Ponto de Ligação
Esta regra restringe as combinações dos pontos de ligação que podem ligar-se a
um dado tipo de segmento.
•
Regra Segmento-Segmento
Esta regra estabelece que combinações de segmentos podem ligar-se através de
um dado ponto de ligação.
•
Cardinalidade da Segmento-Ponto de Ligação
24
Esta regra permite restringir o número (cardinalidade) de segmentos que
concorrem num dado ponto de ligação.
As entidades podem assumir quatro papéis diferentes numa rede geométrica, são
eles: um segmento simples, um ponto de ligação simples, um segmento complexo e um
ponto de ligação complexo. Cada classe numa rede geométrica contém pelo menos uma
das entidades de um destes tipos mencionados.
A análise de redes é um procedimento que analisa as redes para devolver um
dado resultado, tal como encontrar todos os elementos de uma estrada a norte de um
dado ponto ou entre dois pontos designados.
2.6.1. Solvers
Um programa que execute a análise de redes é normalmente designado por
Solver, porque resolve problemas. Estes têm interfaces de utilizador para entradas
específicas e saídas padronizadas de resultados. Os vários tipos de solvers que executam
tarefas similares podem geralmente ser encontrados numa estrutura comum da interface
do utilizador. Por exemplo, numa barra de ferramentas comum. Há quase uma variedade
infinita de solvers para muitos tipos de análises de rede.
2.6.2. Netflags
NetFlags é um local na rede, não é parte da rede lógica. São usados para
descrever algumas posições na rede. Há dois tipos de NetFlags: EdgeFlags e
JunctionFlags. As propriedades de NetFlag incluem as classe da rede lógica, a
identificação da entidade, etc.
2.6.3. Barreiras
As barreiras produzem o mesmo efeito que se obtem num elemento colocando o
seu estado como inactivo, exceptuando o pormenor de que as barreiras não podem ser
guardadas na rede lógica e são apenas perceptíveis aos solver.
Estas
na verdade são ferramentas que permitem incapacitar temporariamente
determinados elementos e podem assumir a forma de segmentos ou pontos de ligação.
Existem quatro métodos para representar barreiras num solver. Uma boa ferramenta
permitirá a utilização destes quatro métodos. Os métodos referidos, são:
•
Interactivamente adicionar barreiras simples.
25
•
Utilizar as entidades (alteração dos atributos).
•
Inactivar classes.
•
Aplicação de pesos com funcionamento semelhante ao de um filtro.
2.6.4. Traçado
Traçado significa seguir o fluxo numa rede até que se encontre uma condição.
Alguns solver de traçado mais conhecidos incluem: upstream trace; downstream trace;
isolation trace e path trace [ESRI, 2000e].
2.6.5. Pesos
Dependentemente dos solver disponíveis assim será efectuada a escolha dos
atributos dos segmentos ou dos pontos de ligação que serão considerados pesos na rede
lógica.
É inútil adicionar pesos a redes se estes não possuirem um solver que o possa
usar. Por exemplo, os solver de traçado tipicamente não usam nenhum peso apenas a
informação sobre a conectividade encontrada na rede lógica.
26
“… um bom modelo é um modelo que começa por
não ser mau e que depois dá bons resultados…”
António Brotas, IST
3. Modelação de uma Base de Dados Geográfica
3.1. Introdução
Existem, na actualidade, várias estratégias para criação de uma BDG, estando
agrupadas em três categorias principais [ESRI,2000e]. As duas primeiras agrupam
métodos de migração de BDG, pressupondo a existência não só de dados, bem como de
uma estrutura e organização destas. A terceira que é aqui abordada baseia-se na criação
de um modelo de dados recorrendo ao uso do UML e das ferramentas disponibilizadas
pelo CASE Tools do software ArcGis® da ESRI®.
O modelo de dados foi construído recorrendo ao Microsoft Visio® 2003 SP1, foi
posteriormente exportado para o formato XML Metadata Interchange (ficheiro XMI,
standard da OMG) recorrendo ao Add-On disponibilizado pela Microsoft® (XMI
EXPORT VISIO ADD-ON UTILITY).
Depois de gerado o ficheiro XMI, executa-se uma verificação semântica e não
havendo erros gera-se o schema (estrutura) da nossa BDG (veja-se a figura 3).
27
No caso específico deste trabalho e uma vez que existe a possibilidade de criar uma
BDG do tipo pessoal ou empresarial, optou-se por uma do segundo tipo que pelo menos
no campo teórico apenas é limitada, em termos de dimensões, pelo número e tamanho
de discos rígidos que lhe possamos juntar. O que do ponto de vista da garantia de
continuidade do território Português, no que respeita à sua plataforma continental é
essencial.
Procedeu-se de seguida à criação de uma metodologia de carregamento, que
permitisse de um modo, o mais automático possível, o carregamento da BDG.
Figura 3 – Uso de CASE Tools para concepção e criação do esquema da BDG, ESRI [2000b]
3.2. A Modelação em UML e a Criação da BDG
Este projecto além de previsivelmente trabalhoso, por se enquadrar numa instituição
com responsabilidades de produção cartográfica e de poder vir a substituir parte da
cadeia de produção de toda uma série cartográfica, foram respeitadas algumas
directrizes. Assim sendo, e porque a cadeia de produção do IGeoE se encontra
estruturada por processos, foi particularmente acautelado:
28
•
O envolvimento das pessoas que actualmente gerem os respectivos processos
afectados, através da sua contribuição por meio de sugestões e opiniões.
•
A execução do projecto por fases (figura 6), uma vez que é um processo
interactivo e iterativo (dadas as suas dimensões e complexidade) de modo a
facilitar a sua execução, manter o ímpeto da mesma e ainda merecer o apoio
dos gestores de processos.
•
A criatividade, pois tratando-se de algo novo é uma excelente oportunidade
para pesquisar e implementar não só novas tecnologias e as suas
possibilidades inerentes, como novas abordagens ou metodologias para a
resolução de problemas.
•
Manter os objectivos institucionais em foco de modo a que os requisitos
sejam cumpridos.
•
A flexibilidade da modelação, de modo a esta poder evoluir no tempo
juntamente com a instituição, garantindo assim a capacidade de esta poder
migrar.
Apresentam-se, na figura 4, as fases executadas na modelação de dados efectuada. O
processo seguido para a criação e carregamento da BDG é apenas uma metodologia de
trabalho possível, não inviabilizando por isso qualquer outra.
A modelação da IGeoE_BDG passou, então, por várias fases. Durante a primeira
fase foi efectuado o levantamento de todas as entidades geográficas actualmente em uso
na produção da série M888. Após o qual se seguiu o levantamento dos respectivos
atributos e geometria que as caracterizam.
Na segunda fase procedeu-se ao agrupamento das entidades atrás levantadas por
Classes. Este agrupamento foi executado tendo em vista duas prioridades diferentes, a
partilha de atributos por um lado e por outro a partilha de métodos. Procedeu-se ainda
ao agrupamento das Classes em Temas pela mesma afinidade de atributos e/ou métodos.
Na terceira fase da modelação depois de identificadas e listadas as relações entre
objectos estas foram implementadas.
Na quarta e última fase, a geometria de algumas Entidades Geográficas bem como
a sua colocação dentro das Classes e Temas foi alterada de modo a que conjuntamente
29
com algumas regras de conectividade permitisse a geração de uma rede geométrica e a
posterior utilização por parte de qualquer software de redes.
Figura 4 – A imagem ilustra as fases da modelação de dados executadas no processo de criação da
IGeoE_BDG
3.2.1. Criar os Temas
Como base de partida foi utilizado o ArcInfo UML Model, presente na ferramenta
CASE Tools. Este modelo na verdade não é mais que um template do formato
específico do Visio, que permite a utilização de ferramentas padronizadas.
30
Este modelo já possui a estrutura interna necessária para suportar a utilização da
linguagem UML na modelação da BDG (veja-se figura 5). Além do mais tratando-se de
uma ferramenta específica para criação de Bases de Dados é ainda possível integrar
código C#, C++, IDL e VB. Como nos encontramos perante uma padronização
efectuada para os CASE Tools possui ainda associado os ArcObjects da ESRI.
Figura 5 – Estrutura base do Modelo disponibilizado pelo CASE Tools (ArcInfo UML Model)
Neste modelo já se encontram definidos 5 pacotes, que possuem um comportamento
similar ao de directorias ou pastas onde se guardam as diferentes partes do modelo.
A Logical View é a directoria base (vide Anexo A - ArcInfo UML Model) onde se
guardam todos os outros pacotes, tendo sido utilizada a pasta Workflow para guardar a
modelação da base de dados. Apesar de ser possível criar pastas ou pacotes adicionais
caso a complexidade assim o exija, não foi necessário neste caso pelo menos até este
ponto do projecto.
A pasta ESRI Classes contém a porção de informação necessária à criação do
modelo de objectos. As Classes existentes nesta pasta representam componentes
utilizados para aceder a informação normalmente designada por geográfica, e que pode
ser encontrada numa organização típica de Base de Dados. Tanto as Classes como as
Entidades Geográficas geradas neste modelo herdam características das classes prédefinidas nesta pasta (vide Anexo A - ArcInfo UML Model).
Aquando da criação de Entidades Geográficas, que se pretende possuir com
características específicas, e quando se pretende gerar código para definir tais
características (por exemplo métodos não padronizados) este é guardado na pasta ESRI
Interfaces (vide Anexo A - ArcInfo UML Model).
31
Assim foram criados dois tipos de pastas no Workspace, os correspondentes à
definição dos domínios de valores, que cada classe pode assumir, dentro de cada Tema
proposto, e o tipo de pasta referente à estrutura propriamente dita da nova BDG.
Na pasta, que contém a estrutura, vamos encontrar por cada tema uma outra pasta
contendo a definição não só das Classes que se definiram, mas também as entidades
geográficas que as compõem.
Neste caso optou-se por definir os Temas que se mostram na figura 6.
Figura 6 - Temas da modelação da série M888
Se por um lado a utilização de alguns destes temas é intuitivo e até lógico, por outro
lado existem alguns que não fazem muito sentido, como é o caso do Terreno, Limites e
Região.
32
O Tema Terreno (figura 7) inicialmente não existia, foi criado numa fase mais
avançada do projecto, pois consegue-se juntar entidades geográficas que ao
descreverem a superfície terrestre partilham atributos, nomeadamente ao nível da sua
natureza e composição (são exemplo disso: areal, areeiro, duna, etc...) e ainda para mais
possuem a singularidade do facto de que quando se altera uma delas as outras,
usualmente associadas, também são alteradas com igual frequência, ou por outro lado
simplesmente não se alteram ou a sua frequência de alteração não é numericamente
expressiva (são exemplo: gruta, escarpado, etc...).
Figura 7 – Tema Terreno
Por questões que se prendem não só com a importância mas também com a própria
natureza e origem da informação, foi introduzido o Tema Limites. Este é constítuido
pelos limites de:
•
País (Comissão Nacional de Limites - IGeoE)
•
Concelho (CAOP v8.0 - IGP)
•
Distrito (CAOP v8.0 - IGP)
•
Freguesia (CAOP v8.0 - IGP)
•
Áreas de Servidão Militar (IGeoE)
•
RAN, REN, etc... (DL)
33
O caso específico da criação do Tema Região (figura 8) justifica-se pela necessidade
de guardar a informação da toponímia que não se encontra associado a nenhuma
entidade geográfica específica, como por exemplo os nomes dos lugares. Uma vez que
se trata de uma entidade que não partilha atributos ou métodos com mais nenhuma, foi
criado um tema diferente para a albergar. Pela mesma razão e estando na fase de entrada
em testes, mais especificamente na de aquisição directa para BDG julgou-se útil criar
uma outra entidade geográfica, do tipo ponto, denominada dúvida, possuindo dois
atributos de escrita livre, denominados de comentário. Tal como a própria designação o
sugere, esta serve para identificar qualquer dúvida de qualquer natureza que o
fotogrametrista possua, nesta fase e no momento da aquisição da informação. Mais tarde
quando se possuir uma tipificação das dúvidas esta entidade será reformulado ganhando
novos atributos diferentes dos actuais de modo a diminuir não só o tamanho como o
tempo de acesso à informação na BDG.
Deste modo se no futuro for desenvolvida alguma ferramenta que permita obviar o
uso deste tema este poderá ser eliminado sem grande risco de afectar a integridade da
IGeoE_BDG.
Figura 8 – Tema Região
3.2.2. As Classes e suas Relações
Após definir os Temas agruparam-se as entidades geográficas em Classes que
partilham a mesma estrutura e comportamento [O’Neill, Nunes, 2004].
As Classes apresentadas, no âmbito do trabalho, foram constítuidas dando
prioridade à partilha de atributos por parte das entidades que as compõem e como
segunda prioridade a partilha de comportamentos.
34
A implementação das Classes, no respeitante ao software utilizado, é de difícil
implementação. Uma vez que é necessário respeitar a estrutura interna do template
utilizado. Se assim não for deparamo-nos com um modelo conceptualmente correcto
mas que no momento da sua conversão para linguagem XML gera código errado ou
sem sentido, não tendo por isso qualquer utilidade que não a gráfica.
Para se proceder à correcta criação das classes é imperioso a observância rigorosa
dos seguintes passos.
1. No diagrama de base (na pasta Workspace) definir a seguinte estrutura
(figura 9):
a. tipificação da geometria das entidades (ponto, linha ou polígono)
b. definição dos atributos base, ou seja, aqueles que se podem
encontrar em toda e qualquer entidade (com a geometria agora
definida), que poderão eventualmente ser predefinidos à partida
(com valores específicos), ou classificados como de preenchimento
obrigatório caso seja necessário.
Figura 9 – Estrutura Base da IGeoE_BDG (Workspace)
35
2. Após a tipificação da geometria e definição dos atributos comuns a todas as
entidades passa-se para a definição das Classes (figura 10). Esta definição
para ser implementada correctamente e poder gerar código utilizável na
construção de uma BDG necessita ser efectuada em dois locais diferentes:
a. Como se referiu no início, foram criadas dois tipos de pastas no
Workspace, uma para albergar a estrutura propriamente dita
(denominada MOD_25K) e um outro conjunto de pastas. É neste
conjunto de pastas divididas por Temas que vão incluir a definição
das Classes que cada Tema possuí e ainda o espectro de valores que
elas podem assumir.
b. Assim sendo e dentro de cada uma das pastas ou seja Temas, após
uma cuidadosa reflexão foram criadas as respectivas Classes. Este
processo, nesta fase, não é mais que a identificação e definição da
designação da Classe e ainda a enumeração das entidades que a
compõem. Assim sendo para cada Tema:
i. Criam-se as Classes julgadas necessárias, definindo-se o
estereótipo, das mesmas, como Range Domain e nos
atributos
para
além
dos
obrigatórios
(FieldType,
MergePolicy e SplitPolicy) enumeram-se todas as entidades
que dela fazem parte. Em simultâneo terão de ser
identificadas para cada um destes atributos o tipo de variável
associada, se se trata de um atributo com carácter privado ou
público, a sua multiplicidade e ainda o valor por defeito. Para
a correcta utilização das Classes o valor inicial a definir para
as entidades que as compõem tem de ser único dentro de
cada Classe pois é através deste campo que as entidades são
definidas quando são introduzidas na estrutura da BDG.
36
Figura 10 – Definição das Classes em cada Tema
Tratando-se de uma estrutura hierárquica, em que a criação ou definição dos seus
elementos se efectua à custa de outros que os precedem ou que se encontram na mesma
estrutura mas em nível superior, é de extrema importância a definição correcta dos
atributos bem como o patamar da hierarquia em que se efectua a mesma, uma vez que
vai condicionar o tamanho, a velocidade de resposta da BD e a capacidade de esta se
adaptar a mudanças futuras.
Assim sendo e a título de exemplo apresentam-se as Classes definidas para o Tema
Vias de Comunicação (figura 11), para os restantes Temas veja-se o Anexo B – As
Classes da IGeoE_BDG.
Figura 11 – A Classe Vias de Comunicação
37
Para o Tema atrás referido foram definidas as seguintes Classes, agrupando as
entidades mencionadas (para uma melhor visualização vide Anexo C – As Classes da
IGeoE_BDG e exemplos de Relacionamentos pp.4):
•
Classe Vias Ferroviárias (contém Via Larga Unica, Via Larga Dupla, etc...)
•
Classe Vias Rodoviárias (contém Estrada Larga, Estrada Estreita,
Autoestrada, Acesso Auto, etc...)
•
Classe Vias Pedonais (contém Vau a Pé, Caminho Pé Posto, etc...)
•
Classe Vias Outras (contém Teleférico, Passadeira ou Tapete Rolante, etc...)
Com o propósito de manter o relacionamento correcto entre as possíveis entidades
geográficas são criadas relações entre entidades, estas são implementadas na
IGeoE_BDG como classes de relacionamento (relationship classes in [ESRI,2000e]).
A cardinalidade das associações propostas são reflectidas pela cardinalidade
presente na relação que se lhe encontra associada. O nome desta Classe de
Relacionamento (Anexo C pp. 2) é o nome da associação. As chaves Primária e
Estrangeira são específicadas directamente no modelo UML como tagged value (veja-se
3.2.3 [ESRI, 2000a]) da associação definida.
Os atributos desta Classe de Relacionamento são modeladas tal e qual uma classe
mas com o nome da Classe de Relacionamento, sendo o esterótipo do tipo relationship
class e os atributos modelados como qualquer outra classe.
As notificações, mensagens de alerta, são modeladas como tagged values e as regras
de relacionamento são modeladas como associações entre os subtipos das classes (vejase o exemplo que se segue do castelo e da capela, Anexo C, fig C-5 pp2) que participam
na Classe de Relacionamento [ESRI, 2000b]).
Nas relações implementadas verificamos que existe sempre uma das entidades que
controla a existência das outras associadas. Veja-se o exemplo do relacionamento
existente entre os faróis, as igrejas, as casas, as capelas, os depósitos de água elevados e
os VG (Vértice Geodésico) controlados pelas anteriores, ou ainda as pontes e as
estradas, os castelos e as capelas ou as autoestradas e as portagens (em que as primeiras
controlam as segundas).
38
No caso dos Castelos e das Capelas, define-se uma classe de relacionamento com
base numa associação do tipo contém, de cardinalidade 1 para 1.
Já no caso da Ponte e das Estradas (Anexo C, fig C-6 pp3, relação múltipla) a
associação é uma agregação de cardinalidade 1 para muitos.
No primeiro caso se a entidade castelo for eliminada a entidade que lhe está
associada a capela também o será. No segundo caso se qualquer uma das entidades for
alterada qualquer uma das duas será notificada da alteração.
Tratando-se da implementação de relacionamentos entre várias entidades
pertencentes a uma mesma Classe ou a várias Classes mas todas do mesmo Tema, e não
só entre duas, surgiu a oportunidade de implementar e testar as class extension.
Estas são definidas tal como uma qualquer outra entidade apenas diferindo no
pormenor da designação desta. As restantes propriedades válidas para as entidades
também o são para esta nova Classe. O nome que terá de ser definido é constítuido pelo
mesmo nome da Classe mãe com o sufixo ClassExtension e permite a título de exemplo
especificar regras (que se tornam de outro modo incomportável por parâmetros) regras
para restrição espacial (área urbana exceptuando industria) de selecção de atributos (do
tipo altura do edificio>= numero pisos*5m), etc...
Para mais informação veja-se o Anexo C – As Classes da IGeoE_BDG e exemplos
de Relacionamentos
3.2.3. Entidades e Atributos, Subtipos
Após a explanação do método de criação dos temas, classes e domínios de valores
resta apenas referir qual a metodologia utilizada para a criação das entidades
geográficas que compõem todas estas.
As entidades são criadas tendo em conta os princípios até aqui enunciados para os
temas, classes, etc... Por outras palavras, não nos poderemos esquecer que este modelo
possuí características próprias e é no seu íntimo um modelo hierárquico. As entidades
ao serem definidas, numa dada Classe e Tema herdam todas os atributos destas. Como
exemplo do descrito veja-se no modelo proposto (Figura 11) a situação definida para
toda e qualquer entidade que pertença a esta BDG.
Uma vez que se encontra definido que para qualquer entidade, seja qual for o tipo de
geometria que esta possua, os seus atributos serão pelo menos: o Código FACC, LV,
39
CO, LC, WT, Nome Célula, Numero de Folha M888, Toponimo e um campo auxiliar
do tipo string denominado AUX1. Então todas as entidades subordinadas herdam estes
atributos, independentemente do tema ou classe de que façam parte. Também aqui
podem ser definidos valores a priori para atributos, determinar o seu preenchimento de
carácter obrigatório, ou simplesmente impedir a sua alteração. Na proposta apresentada,
por se tratar de um projecto de Tese que ainda carece de testes para entrada em
funcionamento na cadeia de produção, não foram ainda implementadas nenhum tipo de
limitações à sua utilização.
Passando agora para o nível dos Temas e tendo em vista a definição das entidades
dentro destes, note-se que aqui se agrupam as entidades por tipo de geometria e que a
sua inclusão nas respectivas Classes se faz por meio de um campo denominado Subtype
Field (figura 12). Este campo faz a ligação ao definido atrás em 3.2.2 As Classes e as
Relações entre Classes no ponto 2.b.i.
Figura 12 – Extracto de algumas entidades das Vias Ferroviárias
Vejamos o caso específico das Vias Ferroviárias (figura 13). Antes de mais, estão
incluídas no tema Vias de Comunicação e possuem uma geometria do tipo linha. Além
de possuirem todos os atríbutos definidos para as entidades deste tipo, possuem ainda
um campo que define a classe a que pertencem e um outro com a designação que
possuem.
Como se pode ver pelas figuras apresentadas, estas entidades ou melhor a sua
definição, encontra-se dispersa por vários objectos. A razão de ser desta apresentação da
modelação de objectos prende-se com a natureza não só da linguagem UML mas
40
também da solução de software pela qual se optou. Esta impõe que para cada entidade
que se pretenda definir se crie:
•
uma classe mãe onde se colocam todos os atributos herdados de níveis
superiores e ainda um campo que define a Classe a que pertence (uma vez
que aponta directamente para a entidade que se pretende definir e se
encontra referenciada na respectiva definição de Classe).
•
define-se um subtipo (classe filha) que vai incluir, pelo menos, um campo
para especificação da entidade através da Classe a que pertence e outros
relativamente a atributos específicos para este objecto caso sejam
necessários.
Figura 13 – Extracto da Classe Vias Ferroviárias
A razão de ser deste tipo de estruturação e de hierarquização da definição das
entidades de uma qualquer BDG explica-se pelo facto de poderem existir entidades que
pela sua natureza possam ser um subtipo de outra.
Não se tratando da opção efectuada para este projecto e cujas razões serão
apresentadas logo de seguida veja-se o exemplo apresentado das vias Ferroviárias.
41
Aparentemente nada leva a crer que as Vias: Metro, Metro de Superfície e
MonoCarril não possam ser cada uma um subtipo de um único tipo de via. E na verdade
assim seria não fosse as relações que estas entidades possuem com entidades terceiras. É
que a mesma regra que impõe que estas entidades podem ser todas um subtipo de uma
única via também impõe a partilha de relações. Ou seja basta que uma delas possua uma
relação com uma outra qualquer entidade que não seja partilhada pelas outras duas que
então esta não pode ser definida (ou o subtipo ou a relação). É o caso do monocarril
cujo suporte à navegação se pode encontrar à superfície ou montado numa estrutura
aérea que possui relações específicas com pontes e passagens superiores não sendo
partilhadas por mais nenhuma das outras. Também o Metro de Superfície possui
relações específicas com passagens de nível com guarda que não são partilhadas com
mais nenhuma das outras.
Esta é a razão, pela qual, na proposta de modelação de BDG do presente trabalho as
entidades geográficas se constituem num único subtipo. Deste modo ao se construir a
estrutura da BDG permite-se uma máxima liberdade na construção de relações entre
entidades em detrimento do volume de informação (nesta modalidade tratando-se de
entidades diferentes não há partilha de atributos logo o espaço de memória ocupado será
maior, e dependerá directamente do número de entidades nesta situação). De qualquer
modo estabelecidas as relações que se pretendem implementar é sempre possível
agrupar em subtipos as que partilham os mesmos atributos e relações, optimizando
então o volume de espaço ocupado. Não esquecendo que a reversibilidade desta etapa é
extremamente difícil deixa-se para mais tarde a decisão de agrupamento das ditas
entidades que partilham os mesmos atributos e as mesmas relações, caso se considere
vantajoso do ponto de vista de optimização do espaço ocupado.
É ainda importante referir que os atributos definidos para cada entidade são na sua
grande maioria um resultado da análise do trabalho desenvolvido e da compilação de
informação, efectuada ao longo do tempo, no IGeoE. Contribuíram para tal: o Guia de
Extracção da Informação para o Fotogrametrista, o Manual do Cadastro Militar, o
Catálogo de Objectos em vigor e o FACC. Por esta razão e porque o suporte papel não
permite uma leitura confortável ou adequada de toda esta informação, todas as figuras
apresentadas são apenas um extracto da informação mais relevante e julgada necessária
de cada uma das entidades, classes, etc... (Anexo D – As Entidades Geográficas da
IGeoE_BDG).
42
3.2.4. Criar uma Rede Geométrica e Regras de Conectividade
A construção de redes não constítuiu prioridade aquando da modelação da
IGeoE_BDG, no entanto foi preocupação do autor preparar a presente modelação para
que, com algum processamento posterior se possa utilizar software de cálculo e análise
de redes. Desta forma foram testadas algumas metodologias e tecidas algumas
considerações sobre o modo não só de aquisição de informação como de processamento
da já existente.
Uma vez que este tipo de implementação exige uma alteração profunda na cadeia de
produção em vigor optou-se por efectuar uma implementação da modelação por fases,
constituindo a rede geométrica uma fase posterior à presente.
De qualquer modo é importante salientar os seguintes pontos (Anexo E – Rede
Geométrica e Regras de Conectividade):
•
Na rede geométrica, as Classes e as entidades são definidas, na linguagem
UML, como uma classe e entidade, em tudo semelhante às outras. Apenas
diferente no esteriótipo, que é do tipo rede geométrica.
•
Todas as classes e entidades afins terão de ser criadas numa directoria ou
pasta específica para a rede geométrica (à semelhança do que se passava com
os Temas).
•
A Classe base que pode ser duplicada e alterada para definir todas as
entidades é a que se encontra por defeito no documento ArcInfo UML
Model e se apresenta na figura 14 (TemplateGeometricNetwork).
•
Existe apenas um único atributo e este define exclusivamente o tipo de rede
(esriNetworkType).
•
Depois de definidas as entidades utilizam-se as relações para definir as
regras de conectividade.
•
Definem-se dois tipos de regras de conectividade, as edge-edge ou as edjejunction [ESRI, 2000d]. As primeiras supõem a existência de pelo menos
duas edje e várias junctions onde uma destas terá de ser a padrão (utiliza-se a
N-ary Link), já nas edje-junction
as regras possuem uma cardinalidade
específica dependendo do subtipo pretendido (1-2 ou 1-5, etc...), neste caso
43
usa-se a associação binary association. Qualquer uma das duas pode também
ser definida recorrendo à Generic Junction Subtype.
•
Para que a BDG assim criada seja realmente compatível com a utilização de
software de redes é necessário garantir previamente o processamento
adequado da informação de modo a poder garantir-se a adequação ou melhor
a compatibilização desta com os ditos softwares. Não nos podemos esquecer
que a informação é oriunda de um sistema do tipo CAD e que por norma a
informação nunca se destinava a este tipo de utilização.
Figura 14 – Rede Geométrica
3.2.5. Exportação para XMI e Validação Semântica
A exportação do modelo em UML é feita numa primeira fase para XMI (veja-se a
figura 15) e depois, numa segunda fase validado, caso não exista erros, é então criada a
BDG.
44
As ferramentas utilizadas para a execução desta fase do trabalho são as disponíveis
nos softwares utilizados. Exceptuando o Add-on utilizado para exportar para o formato
XMI.
A ferramenta que permite a exportação do formato proprietário do Visio para o
formato XMI não se encontra disponível para utilização imediata ou directa. A
Microsoft disponibiliza apenas o código fonte (na linguagem C++), que depois de
devidamente adaptado e compilado permite criar um add-on que deverá ser colocado, de
modo adequado, no Visio.
Depois de se obter um modelo que se pretende exportar, quer seja para testes ou
para utilização final executa-se, normalmente, o Add-on que se compilou (Anexo F).
Figura 15 - Execução do Add-On que permite a exportação para o formato XMI
Após este procedimento obtem-se um ficheiro do tipo XMI contendo a estrutura da
BDG que se encontrar definida no modelo utilizado (veja-se a figura 16).
Após a geração, com sucesso, do ficheiro acima descrito tem-se duas hipóteses:
1. A utilização do software para criação de um projecto em C++ para o
Developer Studio, de modo a gerar a estrutura da BDG em código fonte e
permitir a sua manipulação dessa forma (adicionando código ou removendo
código desnecessário).
45
2. A utilização do software apropriado para executar a validação semântica.
Se no ínicio a primeira hipótese foi largamente explorada, com o decorrer do tempo,
esta rápidamente caíu em desuso. Não só pela quantidade de informação como pela sua
complexidade.
Figura 16 - Extracto do ficheiro XMI gerado
Assim sendo a geração do ficheiro XMI e a sua posterior validação semântica sem
recorrer ao código fonte foi a modalidade mais utilizada.
A validação semântica é efectuada recorrendo a uma ferramenta específica
denominada ESRI Semantic Checker.
No fim da sua execução é apresentado um relatório dessa mesma validação. De
salientar no entanto que os erros apresentados a existirem apenas reflectem erros de
semântica (regras de construção) não são reflexo de erros de estrutura nem reflectem a
qualidade da modelação efectuada em termos de concepção.
Para uma mais cuidada abordagem ao assunto, veja-se o Anexo F – Exportação para
XML e Validação Semântica.
3.2.6. Criação da IGeoE_BDG
O processo de criação da BDG agora modelada passa pela utilização de software
proprietário. A única permissa é que seja compatível com a linguagem XML.
46
A solução adoptada neste projecto permite não só a criação de uma BD a partir de
código XML mas também o carregamento ou alteração de uma BD já existente com um
novo modelo em XML.
Após a criação e validação semântica do modelo, passa-se para a criação da
IGeoE_BDG. Este passo é bastante simplificado e quase não requer intervenção do
utilizador.
Uma das ferramentas disponibilizadas pela ESRI, o schema wizard (figura 17)
permite depois de identificar o ficheiro XML, que contém a modelação da BDG, e após
criar uma BDG “vazia”, utilizar o mencionado ficheiro para criar a respectiva estrutura
nesta última.
Figura 17 - Execução da ferramenta Schema Wizard, para a criação da estrutura da IGeoE_BDG
A intervenção do utilizador efectua-se aquando da:
•
Criação inicial da BDG e escolha do seu tipo (empresarial ou pessoal).
•
Verificação da estrutura criada na BD.
Escusado será referir a importância de que se revestem tais tarefas uma vez que
delas depende não só a validade do trabalho até aqui produzido, mas também a validade
e integridade da própria BDG.
47
No final deste processo de criação, possui-se ainda a hipótese de corrigir pequenas
imperfeições ou esquecimentos ocorridos durante qualquer fase anterior, uma vez que o
schema wizard, imediatamente antes da criação da estrutura modelada efectua uma pré
visualização (figura 18) da modelação pretendida. Deste modo podemos navegar,
naquela que virá a ser a BDG, podendo aceder a todas as entidades, classes e temas tal e
qual o produto final disponibilizado, antes de ser criado.
Figura 18 - Pré visualização da estrutura da BDG a criar.
Esta simples pré-visualização na verdade torna-se bastante eficaz e uma excelente
oportunidade que permite ao utilizador efectuar qualquer pequena alteração (que não se
reflicta na estrutura base) sem necessidade de alterar a sua modelação em UML. Claro
está que se for pretendido reutilizar o modelo, se torna menos trabalhoso corrigir este
último e não directamente os erros, aquando da criação da BDG, pois estas operações
serão repetidas tantas e quantas as vezes o modelo for reutilizado.
A título de exemplo as correcções que se podem introduzir, são:
•
Nas Entidades ao nível dos atributos (novos ou não) e respectivos valores
(mesmo as que se encontrem classificadas como predefinidas).
48
•
Não se podem criar novas Classes mas dentro das existentes podem ser
alterados os valores pré-definidos, a tipificação das variáveis que definem os
atributos, as próprias entidades que constituem as classes, etc.
•
A geometria de qualquer entidade.
•
A renomeação de entidades
As operações que não se podem realizar são:
•
Criar ou alterar relações entre entidades
•
Renomear Classes e Temas
•
Redefinir valores de domínios
•
Criar novas Classes ou dentro destas novos subtipos, etc...
É ainda possível, nesta fase definir o sistema de coordenadas, caso ainda não tenha
sido feito na fase da modelação. Esta BDG assim criada permite possuir no máximo um
sistema de coordenadas por cada Tema criado. O razoável será utilizar apenas um único.
Para a presente BDG
optou-se por implementar o sistema Hayford-Gauss Datum
Lisboa.
Para uma análise mais cuidada, veja-se o Anexo G – Criação da IGeoE_BDG.
3.3. Uma Metodologia de Carregamento
A proposta que a seguir se apresenta constitui apenas uma metodologia para
carregamentoembora não seja a única nem a mais célere. É no entanto uma proposta,
testada e já parcialmente em uso (desde Janeiro último), que permite não só carregar a
IGeoE_BDG mas também, em simultâneo, obter alguns produtos que representam os
pedidos mais usuais dos clientes deste Instituto.
Enumeram-se de seguida os passos para o carregamento da IGeoE_BDG:
1. Conversão da informação do IGeoE do tipo CAD para o tipo Shapefile
(SHP).
2. Conversão do SHP para Base de Dados Geográfica Genérica (sem estrutura
específica).
3. Carregamento da IGeoE_BDG a partir da BDG Genérica.
49
a. Conversões várias:
i. Célula para Linha (portagem em via única)
ii. Célula para Área (estátua, castelo, cisterna, etc...)
iii. Linha para Área (aterro, desaterro, pista de aterragem, etc...)
iv. Ponto para Área (depósito de combustível)
v. Área para Linha, (cais de acesso, ruínas,, etc..)
vi. outras
Deste modo e com a utilização da metodologia atrás mencionada não só se consegue
carregar a BDG como entretanto se podem obter de modo quase automático e muito
mais rápido vários outros produtos, ou melhor formatos (em particular o formato SHP).
Uma vez que o objectivo é a utilização da nova BDG na cadeia de produção e só
agora se iniciaram os testes de aquisição de informação directamente para a BDG, é de
todo aconselhável garantir um modo de carregamento o mais automatizado possível da
referida BDG com a informação do IGeoE, uma vez que a aquisição da informação
ainda permanece estritamente ligada ao CAD.
Para esse fim é de seguida exposta e descrita (por passos) a metodologia criada para
o carregamento.
3.3.1. Conversão CAD para SHP
Neste primeiro passo, tal como o próprio título sugere pretende-se passar de forma o
mais automática possível, toda a informação CAD, relativa à série M888 para o formato
SHP.
Este procedimento só é possível uma vez que a informação utilizada não é a que o
fotogrametrista produz directamente mas sim, depois de passar pelo processo de
validação. Deste modo garante-se que toda a informação é uniformemente adquirida.
A solução concebida é específica para o software utilizado e para a estrutura de
dados própria do IGeoE uma vez que as ferramentas utilizadas foram configuradas com
uma parametrização adequada a estes pressupostos.
Para a construção do modelo de carregamento foi utilizado o Microsoft Visual Basic
6.0 (VB), tendo como base a ferramenta Model Builder da ESRI. É também possível
50
utilizar outros aplicativos ou linguagens alguns até mais simples de utilizar e programar,
no entanto por uma razão de licenciamento estes foram os escolhidos.
Neste passo específico de conversão de formatos, estes efectuam-se por temas
diferentes dos da IGeoE_BDG, aqui utilizaram-se os “temas” usualmente associados às
cores de impressão da cartografia, ou seja, os verdes para tudo o que é vegetação, os
castanhos para a altimetria, etc...
Como o processo de conversão não é mais que a utilização repetida e recorrente das
mesmas ferramentas (figura 26) e porque a informação se encontra organizada por
ficheiros e por pastas nos servidores do IGeoE, utilizou-se a programação em VB para
desenhar e implementar um interface gráfico (figura 19) que permitisse indicar não só
quais as folhas a converter mas também a sua origem e respectivo destino para os dados
da conversão. Aqui a unidade base de conversão é a folha.
Figura 19 – Imagem exemplificativa da aplicação para conversão da informação IGeoE do formato DGN para
SHP.
Como se pode verificar pelas figuras 20 e 21 para cada entidade que se pretende
extrair e depois converter é utilizada uma ferramenta pré-existente, obviamente, depois
de devidamente parametrizada. Existem três ferramentas mais utilizadas consoante se
51
trate de entidades do tipo linha, área ou célula. A parametrização é que depende apenas
das características (CAD) de cada entidade como sejam nível, cor, espessura, etc...
Figura 20 – Imagem exemplificativa dos modelos e respectiva parametrização de ferramentas, criados para
conversão da informação do IGeoE (anexo H pp. 3).
Figura 21 – Extracto de um relatório (listagem de variáveis e processos) de um dos modelos de conversão da
informação do IGeoE.
52
Como a estrutura da informação do Instituto é um standard (sujeito a uma definição
rigorosa), é apenas necessário definir uma única vez cada uma destas ferramentas para
cada entidade. O papel do interface desenvolvido em VB é precisamente executar todos
os ciclos necessários (as ferramentas padronizadas) para a extracção de todas as
entidades (ou apenas as pretendidas) para todas as folhas M888 (ou apenas as
seleccionadas).
Como resultado deste passo obtem-se uma organização da informação por ficheiros
do tipo SHP. A informação que se encontrava organizada por temas clássicos do CAD
(correspondente por assim dizer às cores) encontra-se agora organizado por ficheiros do
tipo SHP mantendo este conceito sempre que possível.
Uma vez que os mencionados ficheiros não permitem a coexistência de entidades de
mais do que uma geometria em cada uma delas, a solução implementada passou por
manter os temas sempre que foi possível, criando novos apenas quando se tratava de
entidades de tipo de geometria diferente. Veja-se o exemplo da hidrografia
(correspondente à cor azul), esta vai originar três ficheiros diferentes um de Hidrografia,
outro de Hidrografia_A e ainda um CellHidro, conforme se trate de informação do tipo,
respectivamente, linhas, áreas ou células.
Existe ainda uma particularidade, o caso específico da toponímia (já editada), que
nesta fase e neste passo ainda não se encontra completamente resolvido, por limitação
do software utilizado (não existem ferramentas disponíveis para adequada manipulação
deste tipo de informação nestes ficheiros SHP). Assim sendo e porque se espera
resolver completamente esta questão utilizando a IGeoE_BDG foi arquitectada uma
solução temporária que passa pela criação de ficheiros SHP, unicamente com a referida
toponímia que depois são agregados à informação original, evitando assim a perda ou o
carregamento manual mais tarde já no formato BD.
Caso em determinadas folhas da série M888 não exista qualquer informação sobre
algumas das entidades, os ficheiros respectivos, simplesmente não são gerados cabendo
a responsabilidade da verificação final ao operador que executa a conversão. Sempre
que uma folha é revista, e é difundida uma nova versão a aplicação é novamente
executada para se proceder à actualização da informação.
Poder-se-á obter mais informação consultando o Anexo H – Carregamento da
IGeoE_BDG
53
3.3.2. Conversão SHP para BDG Genérica
Esta conversão apesar de simples e rápida é apenas um passo intermédio, mas
necessário, pois para se poder continuar a executar o modelo de carregamento é
necessário converter os campos associados aos atributos, de cada entidade, oriundos do
passo anterior, para o formato final pretendido na IGeoE_BDG.
Na verdade o que é produzido nesta fase é uma BDG como uma estrutura genérica,
ou seja, distribui-se a informação que se encontrava organizada em vários ficheiros do
tipo SHP, por entidades dentro de uma BDG (os temas mantêm-se os dos ficheiros
acabados de mencionar). O que muda para cada entidade é a definição do tipo de campo
de cada um dos seus atributos. Por outras palavras agrupa-se a informação numa
estrutura típica de BD, já parcialmente ajustada à final que se pretende obter.
De salientar a importância vital de acrescentar um novo tema, que neste momento
não possui informação, mas servirá para efectuar as conversões de geometria (referida
no início do ponto 3.3).
São de seguida apresentadas algumas das ferramentas (figura 22) utilizadas na
criação automática da BDG intermédia (para verificar parametrizações específicas vejase o Anexo H – Carregamento da IGeoE_BDG).
Figura 22 – Algumas ferramentas utilizadas na criação automática da BDG Intermédia
54
3.3.3. Conversão BDG Genérica para IGeoE_BDG
Para a execução deste passo devem ser efectuados os seguintes procedimentos:
•
Carregamento directo de todas as entidades que mantêm a sua geometria
inalterável.
•
Conversão e posterior carregamento das restantes entidades.
Para a execução do primeiro procedimento a selecção de entidades na BDG
intermédia para seu posterior carregamento é efectuado segundo os seus atributos
herdados do ficheiro CAD (LV; CO; LC; WT ou ainda Cell_Nome). Deste modo
estabelece-se uma correspondência unívoca entre as duas BDG, já que a primeira
condicionante da construção da BDG final é a reversibilidade a qualquer altura do
processo para o sistema CAD.
Esta capacidade garante-se ao se ter definido á partida para toda e qualquer entidade
quais os atributos “CAD” e respectivos valores que herdaram. Para além disso como a
unidade de produção do IGeoE é a folha da Carta Militar, foi também criado um campo
adicional de preenchimento obrigatório e automático (a partir do nome do ficheiro
original) que identifica a folha que originou a informação. Estes campos, por enquanto,
possuem grande utilidade em termos de garantia de reversibilidade, mas serão
eliminados num futuro próximo. Os “atributos CAD” efectivamente não necessitam de
existir e de “pesar” na BDG, não que ocupem fisicamente muito espaço, pois como já
foi visto, esta definição é feita por patamares ou hierarquias e é definido uma única vez
para um dado tipo de entidades o que acontece é que vamos possuir um enormíssimo
conjunto de apontadores guardados e isso fará com que a BDG se torne mais lenta na
resposta não só aquando da execução de Queries como aquando da utilização por vários
utilizadores (ainda que se preveja a utilização do sistema de multiversionamento). Para
obviar estes atributos basta garantir (por exemplo guardando num ficheiro tipo texto)
qual a estrutura da informação nos ficheiros CAD originais (Catálogo de Objectos da
série M888 do IGeoE).
A ferramenta utilizada para o carregamento das entidades que não sofrem alteração
ao nível da sua geometria é a Select (figura 23).
55
Figura 23 – Ferramenta Select para carregamento da IGeoE_BDG
Resta então explicar como se executa a conversão de geometria de algumas
entidades e depois o seu carregamento. De relembrar apenas que esta questão é
levantada pois a informação já existe, e porque não foi criada tendo em vista este fim
específico é necessário adaptá-la. Ou seja , assim que se iniciar a aquisição directa para
a BDG esta questão deixa de existir pois todas as entidades passam a ser adquiridas com
base na sua geometria e num conjunto de regras de extracção específico para esta BDG.
Esta é apenas uma fase transitória que se espera ser o mais breve possível.
Na conversão de geometrias foi tido em consideração, pois só assim faz sentido, o
guia de extracção de informação, para se saber por exemplo qual a orientação de uma
dada nova entidade que agora é do tipo área mas antes era adquirida como célula
(quando considerar o ângulo de rotação da célula - QRotW), para se saber quando nos
encontramos numa situação de excepção e qual a regra que foi aplicada nesse caso, etc...
Assim sendo e de acordo com a modelação efectuada algumas das conversões a
realizar são as que se apresentam na figura 24.
Entidades a converter
Conversão
Cais_de_Acesso_Ferroviario
A
L
Pista_de_Aterragem
L
A
Aterro
L
A
Desaterro
L
A
Molhe_Vermelho_Plataforma_de_Atracacao_em_Betao L
A
Molhe_Azul_Plataforma_de_Atracacao_em_Ferro
L
A
Molhe_Preto_Plataforma_de_Atracacao_em_Madeira
L
A
A
Estacao_Elevatoria
C
Estatua
C
A
A
Cruzeiro
C
Castelo_ou_Forte
C
A
Deposito_de_Combustivel
P
A
Portagem_em_Via_Dupla
C
L
Portagem_em_Via_Única
C
L
Ferramenta
Feature to Line
Feature to Polygon
Buffer
Buffer
Conversão para Área (MV)
Conversão para Área (MA)
Conversão para Área (MP)
Conversão para Área (EE)
Conversão para Área (E)
Conversão para Área (C)
Conversão para Área (CF)
Buffer
Conversão para Linha (PD)
Conversão para Linha (PU)
Figura 24 – Extracto da lista de entidades a converter para posterior carregamento na IGeoE_BDG
56
A título de exemplo, e para um melhor entendimento, não só da ferramenta
concebida mas da estrutura do trabalho, procede-se de seguida à descrição da
metodologia implementada para apenas alguns dos tipos de conversão e em particular
aqueles mais representativos das dificuldades encontradas.
Conversão de Célula para Linha, aplicada à Portagem em Via Dupla ou Única
Não sendo possível utilizar uma ferramenta capaz de realizar uma conversão de
forma directa (pois tal ferramenta não existe ou pelo menos não se encontra disponível
na solução adoptada) optou-se pela metodologia que a seguir se descreve.
Para efectuar esta conversão é necessário ter em linha de conta a rotação da célula
de origem (QRotW). Deste modo a linha a criar tem, obrigatoriamente, de ser
perpendicular ao eixo da via (AutoEstrada).
Dado que a extracção de informação da via, necessária ao processo, varia na forma
da aquisição, é necessário ter em linha de conta duas possibilidades:
1. Uma em que apenas é adquirido um segmento de recta, com base no eixo
central da via.
2. E uma outra, em que são adquiridos dois segmentos de recta, um para cada
sentido de circulação, com base no eixo central de cada faixa de circulação
(sentido).
Por este motivo, a Portagem não se apresenta sempre de um mesmo modo, já
que a célula correspondente às portagens ora vai incidir sobre a via, no primeiro caso,
ora vai situar-se aproximadamente entre os dois eixos, no segundo.
Então a solução proposta passa por extrair pequenos segmentos de recta
pertencentes à via, através da intersecção (Intersect) desta com dois tipos diferentes de
áreas em torno das células das portagens (Buffer), veja-se a figura 25.
Para que o modelo respondesse às duas metodologias de restituição da via,
realizaram-se duas áreas distintas, uma com quatro milímetros para extrair o segmento
de recta, e outra com vinte e cinco milímetros para permitir extrair pequenos segmentos
paralelos da via, quando a aquisição da via passa-se pela restituição dos dois eixos das
faixas de rodagem (estas unidades dependem em cada projecto da escala a que se
destina, ou das preferências específicas do utilizador).
57
A
B
C
D
Figura 25 - Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das
ferramentas: Buffer (A e B) e Intersect (C e D).
Para este ultimo caso, foi necessário simplificar os segmentos extraídos (Simplify
Line), já que será necessário convertê-los num único que se localize entre os dois
anteriores (figura 26), para que desta forma não se perca rigor aquando da conversão
para linha central (Collapse Dual Line to Central Line).
A
B
Figura 26 - Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das
ferramentas: Simplify Line (A) e Collapse Dual Line to Central Line (B).
No final deste processo obtemos, para os dois casos, um único segmento de recta de
orientação concordante com o sentido da via. Podendo agora intersectar a segunda
extracção com a primeira área, para que o comprimento de ambos os segmentos seja
exactamente de quatro milímetros (Intersect).
Paralelamente a esta operação, foi necessário criar uma nova entidade para alojar o
resultado dos processos anteriores (Create Feature Class). Esta nova entidade é então
carregada com as duas extracções anteriores (Append), sendo que este passo é
58
fundamental para se poder manipular os dados nos passos seguintes, cujo objectivo é
dar uma nova orientação aos segmentos de recta.
Agora que há uma uniformização das portagens
(figura 27), quanto ao
comprimento do segmento de recta que as representa, atribuí-se uma nova área aos
segmentos de recta, especificando-se em duas fases, uma para a direita e outra para a
esquerda (Buffer) da mesma, ambas com treze milímetros de comprimento e forma
rectangular. No entanto deste modo o resultado são dois polígonos separados que é
necessário unir (Union).
A
B
Figura 27 - Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das
ferramentas: Buffer (A) e Union (B).
Posteriormente (figura 28), e porque a utilização dos segmentos de recta prevalece
sobre a dos polígonos, realiza-se a conversão para linha (Polygon to Line), separando-se
logo de seguida as diferentes linhas pelos vértices (Splite Line at Vertices).
A
B
Figura 28 - Modelo de Conversão de Célula a Linha aplicado à Portagem, exemplo de aplicação das
ferramentas: Polygon to Line (A) e Splite Line at Vertices (B).
59
Deste modo pode-se então extrair os segmentos de recta com maior comprimento
(Select), porque se parte de rectângulos perpendiculares ao eixo da via, ficando
novamente com uma selecção de duas linhas paralelas, encontrando-se agora com
orientação perpendicular ao eixo da via.
Realiza-se novamente a conversão das duas linhas paralelas para uma única linha
central que passa precisamente pelo ponto de representação da portagem (Collapse Dual
Line to Central Line).
Posto isto, resta apenas eliminar os campos desnecessários da entidade, e que
entretanto foram sendo criados por via das diferentes ferramentas utilizadas (Delete
Field), e criar os novos campos que possibilitem registar todos os atributos referentes à
entidade (Add Field) calculando aqueles que sejam necessários (Calculate Field) de
acordo com a modelação inicial. Depois de convertida é carregada na IGeoE_BDG tal
como qualquer outra entidade de carregamento directo.
O resultado assim obtido permite converter e carregar esta entidade com um grau de
confiança bastante aceitável uma vez que em ambas as situações apresentadas (Via
Única e Dupla) as áreas de portagem não possuem muita variabilidade e como as áreas
de teste são representativas da realidade tudo indica, para além dos testes, que será uma
metodologia que apresente resultados satisfatórios.
Conversão de Linha para Área, aplicada a Aterro e Desaterro
Esta conversão, embora simples, atende a um aspecto importante que diz respeito ao
sentido de aquisição dos elementos (vide Guia de Extracção de Informação).
O Guia de Extracção de Informação do IGeoE para a série M888 refere que quer o
aterro, quer o desaterro (figura 29 , respectivamente A e B) são adquiridos sempre de
um ponto (1) até um ponto (2), sempre pelo lado direito da via. Para além disso, é ainda
referido que a representação é sempre efectuada da cota mais alta para a mais baixa para
ambos os casos. A dificuldade é manter o segmento de recta que identifica a cota mais
alta inalterado.
A abordagem a esta questão passa por atribuir uma área a cada elemento (Buffer),
atendendo a que esta área deverá respeitar as características impostas.
60
Assim para o aterro a área é atribuída para a direita, com uma largura máxima de
dois milímetros e com forma rectangular. Já para o desaterro, o processo é o mesmo,
variando apenas na orientação da área, sendo esta para a esquerda.
O resultado obtido, é o esperado do ponto de vista da conversão e não coloca em
causa os atributos da entidade, em particular no que respeita à localização geográfica.
A
B
Figura 29 - Imagem exemplificativa do Aterro (A) e Desaterro (B). para implementação do Modelo de
Conversão de Linha a Área.
Conversão de Linha para Área, aplicada ao Molhe
A dificuldade existente na conversão desta entidade para área, depende
exclusivamente de um único factor. Esta entidade pode ser encontrada com forma
variável em que as diferentes linhas se podem encontrar fechadas, abertas e ainda com
uma disposição de linhas que não permite atribuir-lhe forma (figura 42, A, B e C
respectivamente).
A
B
Figura 30 - Exemplo dos três tipos de Molhe
61
C
Posto isto, logicamente não é possível aplicar um único método às três modalidades
de restituição, optando-se então por uma solução que se pudesse aplicar a todos as
entidades, mas cujo resultado final não fosse distinto de caso para caso.
Para a realização desta tarefa optou-se por, em primeiro lugar fechar todas as linhas,
(claro está que para aquelas a que não era possível atribuir forma, esta técnica não
alteraria a sua condição). Para isso comecou-se por criar um ponto no ínicio e fim de
cada linha (Feature Vertices to Points) e paralelamente a criação de uma nova entidade
para alojar os dois tipos diferentes de pontos e permitir a manipulação em simultâneo
(Create Feature Class e Append).
Seguidamente, em torno de cada um dos pontos criou-se uma área com um raio de
meia unidade de medida (Buffer), veja-se a figura 31.
Realizada esta operação é possível então interceptar as áreas anteriormente extraídas
com as linhas de aquisição do objecto (Intersect).
Figura 31 - Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta:
Buffer.
Os segmentos de recta extraídos desta intercepção passam posteriormente para uma
nova fase em que lhes é atribuída uma nova área, sendo que essa área terá dez
milímetros (Buffer), e é ainda atribuída em duas fases diferenciadas, uma para a
esquerda e outra para a direita.
Este passo permite fechar todas as linhas, já que o resultado será um cruzamento de
linhas, logo que seja processada a conversão de polígono para linha (Polygon to Line) e
as linhas quebradas pelos vértices (Split Line at Vertices), veja-se a figura 32.
62
Finalmente extraem-se todos os segmentos com comprimento superior ou igual a
uma unidade de medida, ficando assim unicamente as linhas paralelas aos segmentos de
rectas extraídos inicialmente.
Figura 32 - Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta:
Polygon to Line e Split Line at Vertices
Após a realização desta operação, junta-se este resultado a uma cópia da entidade
original, obtendo deste modo objectos “completos”, no respeitante ao pormenor das
linhas estarem agora fechadas.
Assim sendo, já é possível converter a entidade para polígono (Feature to Polygon),
figura 33.
Figura 33 - Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta:
Feature to Polygon
Paralelamente (figura 34), e para evitar algumas deformações que vão surgindo com
a utilização deste método, é necessário criar uma área com uma unidade de medida em
torno da entidade original (Buffer). O objectivo é isolar a área dos elementos que são
fundamentais para a sua definição, e os defeitos de forma que vão surgindo. Esta
operação é realizada com base na eliminação das duas áreas que se sobrepõem (Erase).
63
A
B
Figura 34 - Modelo de Conversão de Linha a Área aplicado ao Molhe, exemplo de aplicação da ferramenta:
Buffer(A) e Erase (B).
Posto isto, efectua-se uma dissolução da entidade para que esta seja uniforme e
perca todas as linhas que lhe foram adicionadas por forma a completar os polígonos
(Dissolve). Seguidamente, e uma vez que foi realizada uma dissolução, é necessário
passar de uma única entidade distribuída por diferentes localizações geográficas, para
diferentes entidades (Multipart to Singlepart).
Desta forma é agora possível escolher apenas aquelas que interessam, visto que com
a operação anterior separamos as mesmas dos erros de geometria. Esta operação é
realizada através da selecção dos objectos com uma área superior ou igual a catorze
milímetros (Select), ao mesmo tempo que se efectua a atribuição de uma nova área em
torno da entidade original de meia unidade de medida (Buffer), para que compense a
porção anteriormente eliminada e ao mesmo tempo possa incluir as entidades às quais
não foi possível atribuir forma. Fica completa esta operação, com a criação de uma nova
entidade que possibilita alojar o resultado das duas operações que ocorrem neste passo
(Append), e realizando nova dissolução para unir todos os objectos num só (Dissolve),
e novamente dividi-los (Multipart to Singlepart).
Em suma e após a leitura dos exemplos apresentados podem-se verificar algumas
das diversas questões que se levantam e imaginar também outras de complexidade
diferente que igualmente se encontraram envolvidas no processo de carregamento da
IGeoE_BDG.
Em suma é de referir que esta metodologia de carregamento criada serve o propósito
único de carregar a BDG concebida e desenvolvida em UML com a informação do
IGeoE. A especificidade da arquitectura da BD bem como a organização da informação
64
impõem que esta metodologia não possa ser directamente utilizada noutras situações
sem que sejam feitas as devidas adaptações.
Tal como já se referiu estas questões apenas surgem na fase inicial do projecto em
que se converte a informação tipicamente armazenada num ficheiro do tipo CAD, em
que a unidade de produção é a folha da Carta Militar 1:25 000. Quando se iniciarem os
testes de aquisição directa para a BDG estes desaparecerão e novos irão surgir. Afinal
esta fase é apenas transitória até à completa implementação da aquisição directa para
BDG.
65
4. Conclusão
4.1. Conclusão
Dos objectivos estabelecidos para este projecto, foram atingidos com sucesso:
•
A modelação de uma Base de Dados Geográfica para a Carta Militar de
Portugal Continental da série M888 na escala 1:25 000.
•
A criação da respectiva BDG.
•
A integração na cadeia de produção deste Instituto concebendo e
implementando uma metodologia de carregamento automática eficaz.
Espera-se com o resultado obtido neste projecto contribuir para a actualização e
optimização da cadeia de produção da série M888, com uma nova abordagem, novos
processos e metodologias de trabalho de modo a dar resposta não só às necessidades
bem como às actuais condicionantes que têm vindo a pautar a nossa realidade. Sejam
elas ao nível da escassez de meios humanos, redução significativa dos fundos e aumento
generalizado dos custos (principalmente logísticos), generalização do uso de formatos
até aqui de utilização reduzida, etc.
Para a prossecução deste fim é de extrema importância possuir um bom modelo de
dados. Pois permite, de um ponto de vista conceptual, fornecer um entendimento
profundo das entidades geográficas que o constituem, das relações que estas
estabelecem e ainda da estrutura e dependências implícitas no mesmo.
Apesar da missão primordial do IGeoE ser de cariz estritamente militar, não se pode
esquecer que também a missão define como objectivo o apoio da sociedade civil. Existe
então latente uma dicotomia que se torna visível ao longo desta dissertação e que na
66
verdade levantou muitas questões no que toca às normas que iriam reger a construção
desta BDG. Se por um lado a vertente militar aconselha a observância rigorosa dos
STANAG , por outro a vertente civil aconselha o uso das ISO.
Na verdade estas não diferem muito umas das outras, apenas em pormenores muito
específicos que dizem respeito apenas a aspectos particulares de cada uma delas, na sua
essência são semelhantes.
Como o objectivo que se pretendia alcançar era criar uma BDG que se adaptasse às
necessidades específicas do IGeoE e porque na verdade a experiência adquirida mostra
que:
•
É possível a geração automática da estrutura da BDG em XML (XML
Schema) baseada numa modelação concebida em UML, fazendo uso das
XML Encoding rules,
•
Os
diagramas
em
UML
não
permitem
obter
uma
modelação
verdadeiramente completa apenas uma que seja conveniente, com soluções
de compromisso.
•
E ainda que as normas, sejam elas STANAG ou ISO, necessitam de ser
revistas e melhoradas, se no futuro se pretender realmente atingir o objectivo
preconizado da interoperabilidade e da viabilidade de uso.
Nenhuma das normas apresentadas foi seguida na sua plenitude de modo a permitir
uma maior flexibilidade na modelação. Deste modo conseguiu-se aliar as
potencialidades postas à disposição pela linguagem UML e as das soluções de software
utilizadas. Pelo método de carregamento desenvolvido é visível que a conversão de
entidades e seu carregamento entre diferentes BDG é possível estando assegurada, caso
se pretenda, a migração para qualquer uma das normas apresentadas.
Também por se tratar de um modelo que permite a geração automática de uma
BDG, se possui a vantagem de a qualquer momento alterar o modelo, criar a BDG e
carregá-la automáticamente num intervalo de tempo claramente reduzido quando
comparado com o que era possível efectuar com outros métodos.
Foi também objectivo não perder a riqueza de informação que carateriza os dados
do IGeoE (Cadastro Militar). Assim aglomerou-se na mesma BDG a informação que
67
entretanto se tem vindo a guardar separadamente pelos vários reportórios de dados
existentes.
Apresentam-se-nos, no entanto, alguns inconvenientes por se estar perante uma
cadeia de produção, com especificidades próprias, mas que não pode desacelerar muito
menos parar. Daí que a implementação deste projecto seja alongada no tempo, de
duração muito superior ao de execução desta dissertação de mestrado. Esta
implementação será efectuada por fases e ocorrerá em simultâneo com o processo de
produção actual:
1. Modelação (por objectos e em UML) de uma BDG.
2. Criação da IGeoE_BDG (realização de testes).
3. Conversão da informação e posterior carregamento da mesma (realização de
testes).
4. Implementação da IGeoE_BDG no Departamento de Aquisição de Dados
que é como quem diz no processo de Aquisição de Dados (Secção de
Fotogrametria) e Completagem (Secção de Topografia). Guardando-se para
mais tarde o estudo da viabilidade e implementação no resto da cadeia de
produção (Edição, veja-se o ponto 4.2).
Também existiu uma especial preocupação ao estruturar a nova BDG de modo a
suportar não só o fluxo de trabalho actual assente na estrutura CAD, como também o
fluxo de trabalho assente numa BD com a sua própria tipificação de estrutura, valências,
vantagens e desvantagens (veja-se 2.5 Tipos de BD e Tipificação de Workflow).
Por fim apesar de não ter sido efectuada a implementação de redes, apenas testado
com algumas entidades e de modo aleatório, procedeu-se à sua compatibilização. É
possível, está prevista e parcialmente testada. Resta descobrir se é um objectivo
remunerador (finaceiro e/ ou estratégico) pois implica não só o tratamento de alguma da
informação de base, bem como novas regras para a aquisição de informação e/ou para a
validação (que tornam o processo mais moroso e oneroso) e ainda a criação e
implementação de regras de conectividade (veja-se o 3.2.4. Criar uma Rede Geométrica
e Regras de Conectividade).
4.2. Propostas de Melhoria
68
Propõem-se como melhoria os seguintes aspectos:
•
A implementação da aquisição directa para a IGeoE_BDG (em início de
testes).
•
A criação (já em curso) e implementação da simbologia para a M888 (de
modo a que a impressão directa a partir de BD tenha o mesmo output que o
baseado nos ficheiros CAD).
4.3. Propostas para trabalho futuro
Entende-se que uma verdadeira BDG que contemple o Território Continental
Nacional que contenha toda a informação (ou pelo menos a mais relevante) que existe
neste Instituto e sirva para descrever o mesmo Território, deve conter porque já o é
possível, a informação relativa a Imagens Raster e informação relativa à descrição da
superfície terrestre.
A inclusão de informação do tipo Raster permite efectuar uma eficiente descrição da
informação geográfica, pois apesar de possuir um formato simples permite apresentar
uma grande variedade de informação p.e. do tipo temático, espectral, etc... Esta
informação Raster pode então ser utilizada para vários fins como seja representar a
Classificação e Uso dos Solos, configurações do terreno (MDT), Classificação de
Cobertos Vegetais, Delineação de Orlas Costeiras ou Orlas Florestais, etc...
No respeitante à inclusão de um Modelo de Superfície (TIN) hà que ter em conta
que a grande maioria das entidades geográficas que existem na modelação efectuada ou
em qualquer outra para o efeito, se encontram sobre a superfície terrestre. São exemplo
os edifícios, estradas, pontes, etc... sendo modeladas tendo em conta os seus atributos,
relações e comportamentos específicos. Encontram-se, no entanto, modeladas outro tipo
de entidades, os rios, os montes, as valas, etc... que não se encontram na superfície mas
se incluem nela.
Apenas incluindo estas entidades numa representação contínua da superfície se
podem executar análises (de superfície) por exemplo do tipo bacias de visão, análise
hidrográfica, etc... Constítuindo esta capacidade adicional uma mais valia considerável
naquela que se considera actualmente a ferramenta de eleição no Apoio à Decisão.
69
Bibliografia e Referências Bibliográficas
Borges K, “Modelagem de dados geográficos”, Escola de Governo-Fundação João
Pinheiro, Belo Horizonte, Brasil, 1997.
Mark D. M. and Frank A. U. “Language issues for geographical information systems.
National Center for Geographic Information and Analysis (NCGIA)”, Technical Report
pp. 90-100, 1990.
ESRI, “Case Tools Tutorial”, The Cutting-Edge Technology, Environmental Systems
Research Institute, Inc. New York Street, Redlands, CA 92373-8100 United States of
America, 2000
ESRI, “Designing Geodatabases with Visio”, The Cutting-Edge Technology,
Environmental Systems Research Institute, Inc. New York Street, Redlands, CA 923738100 United States of America, 2000
ESRI, “Exploring ArcObjects – applications and cartography”, The Cutting-Edge
Technology, Environmental Systems Research Institute, Inc. New York Street,
Redlands, CA 92373-8100 United States of America, 2000
ESRI, “Introduction to Case Tools”, The Cutting-Edge Technology, Environmental
Systems Research Institute, Inc. New York Street, Redlands, CA 92373-8100 United
States of America, 2000
ESRI, “Modelling our world”, The Cutting-Edge Technology, Environmental Systems
Research Institute, Inc. New York Street, Redlands, CA 92373-8100 United States of
America, 2000
ESRI, “Map Generalization in GIS: Practical Solutions with Workstation ArcInfo
Software”, The Cutting-Edge Technology, Environmental Systems Research Institute,
Inc. New York Street, Redlands, CA 92373-8100 United States of America, 2000
ESRI, “Programing ArcObjects with VBA - a task oriented approach”, CRC Press,
United States of America, 2000
Filho, J, “Projeto de Banco de Dados para Sistemas de Informação Geográfica”,
Universidade Federal de Viçosa, 36571-000 Viçosa, Brasil, 2001.
Eriksson H. E, Penker M., “UML Toolkit”, John Wiley & Sons, 1998
70
International Organization for Stadardization, “ISO/DIS 19108 – Geographic
Information – Temporala schema”, Technical Committee ISO/TC 211, Geographic
Information/Geomatics, 2001
International Organization for Stadardization, “ISO/DIS 19110 – Geographic
Information – Methodology for feature Cataloguing”, Technical Committee ISO/TC
211, Geographic Information/Geomatics, 2001
International Organization for Stadardization, “ISO/DIS 19115 – Geographic
Information
-
Metadata”,
Technical
Committee
ISO/TC
211,
Geographic
Information/Geomatics, 2001
International Organization for Stadardization, “ISO/DIS 19136 – Geographic
Information – Geography Markup Language”, Technical Committee ISO/TC 211,
Geographic Information/Geomatics, 2001
International Organization for Stadardization, “ISO/DIS 19501 Unified Modeling
Language
(UML)”,
Technical
Committee
ISO/TC
211,
Geographic
Information/Geomatics, 2001
International Organization for Stadardization, “ISO/DIS 19503 XML Metadata
Interchange
(XMI)”,
Technical
Committee
ISO/TC
211,
Geographic
Information/Geomatics, 2001
International Organization for Stadardization, Ad-Hoc Working Group, “Proposed
Semantic Data Model for Geographic Data”, Technical Committee ISO/TC 211,
Geographic Information/Geomatics, 2001
Oliveira J. L., Pires F., and Medeiros, C. M. B.. “An environment for modeling and
design of geographic applications.” GeoInformatica pp. 29-58, 1997.
Rumbaugh J., Jacobson I., Booch G., “The Unified Modeling Language User Guide.”
AddisonWesley, 1999.
Rumbaugh J., Jacobson I., Booch G., “The Unified Modeling Language Refrence
Manual.” AddisonWesley, 1999.
Rumbaugh J., Jacobson I., Booch G., “The Unified Modeling Language Developer
Process.” AddisonWesley, 1999.
71
Rumbaugh J, Blaha M, Premerlani W, Eddy F, and Lorensen W. “Object-Oriented
Modeling and Design.” Prentice-Hall, 1991.
Karla A, Borges V, Clodoveu Davis A, and Laender A. H. F, “OMT-G: An object
oriented data model for geographic applications”, GeoInformática, 2001.
Borges K. A. V, Laender A. H. F, and Davis Jr. C. A. “Spatial data integrity constraints
in object oriented geographic data modeling.” In Proceedings of the 7th International
Symposium on Advances in Geographic Information Systems (ACM GIS’99), pp. 1-6,
1999.
Kemp K. K. “Environmental modeling with GIS: a strategy for dealing with spatial
continuity.” Ph.D. thesis, University of California at Santa Barbara, 1992.
Lopes J. “Generalização Cartográfica”, FCUL, Tese de Mestrado, Lisboa, Portugal, pp.
32-47, 2005
NATO, “STANAG 2251 IGEO (EDITION 6) – Scope and Presentation of Military
Geographic Information and Documentation (MGID)”, Military Agency for
Standardization, Brussels, 1999.
NATO, “STANAG 7074 IGEO (EDITION 2) – Scope and Presentation of Military
Geographic Information and Documentation (MGID)”, Military Agency for
Standardization, Brussels, 2001.
Nunes, M. and O’Neill, H. “Fundamental de UML”, FCA Editora de Informática, Rua
D. Estefânia 183-1º Esq, Lisboa, Portugal, 2001.
Chen P. “The entity-relationship model-toward a unified view of data. ACM
Transactions on Database Systems”, pp. 9-36, 1976.
Abiteboul S. and Richard R. Hull. “IFO: A formal semantic database model.” ACM
Transactions on Database Systems pp. 525-565, 1987.
Silva, A. and Videira, C, “UML, Metodologias e Ferramentas CASE”, Centro Atlântico,
V. N. Famalicão, Porto, Portugal, 2001.
72
Anexos 73
Anexo A – A estrutura do ArcInfo UML ModeL 1
Anexo A – A estrutura do ArcInfo UML Model Extracto da estrutura do ArcInfo UML Model utilizado como base de trabalho para a modelação da base de dados (versão para Microsoft® Visio® 2003). Fig A‐1 A estrutura base do ficheiro utilizado para a realização do trabalho de modelação. Fig A‐2 A estrutura de pastas, onde serão guardadas as diferentes partes do modelo criado. Fig A‐3 A estrutura da pasta, onde será guardada a parte do modelo criado, relativa às entidades de rede. Anexo A – A estrutura do ArcInfo UML ModeL 2
Fig A‐4 A estrutura da pasta, onde se guarda a informação do modelo relativa às interfaces criadas. Fig A‐5 extracto da estrutura da pasta que serve de apoio à criação da rede geométrica. Anexo A – A estrutura do ArcInfo UML ModeL 3
Fig A‐6 Extracto da pasta onde se encontra definida a informação relativa aos elementos base de qualquer rede geométrica e dos quais todas as entidades herdam alguns dos seus atributos . Fig A‐7 Extracto da estrutura da pasta que serve de apoio à criação dos Diagramas de Classes. Anexo B – Os Temas da IGeoE_BDG 1
Anexo B – Os Temas da IGeoE_BDG Extracto da modelação efectuada no respeitante aos temas, sua estrutura e implementação. Nota: a informação relativa às entidades apresentadas é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig B‐1 A pasta Workspace é o local da estrutura deste ficheiro onde se guarda a informação relativa não só aos Temas bem como às Classes e valores de Domínio. As pastas organizadas por Temas (a verde) e a definição das entidades que os compõem estão guardados dentro da pasta denominada MOD_25K (a azul). As restantes pastas na raíz da pasta workspace possuem dentro de cada uma a definição das Classes e valores padronizados que compõem cada Anexo B – Os Temas da IGeoE_BDG 2
Fig B‐2 A definição das Classes e dos valores padrões que compõem cada Tema. Anexo B – Os Temas da IGeoE_BDG 3
Fig B‐3 A imagem apresentada pretende mostrar como deve estar feita a organização da informação, apesar de se ter tido cuidado algum cuidado com o grafismo importa reter que é aqui que se define qual a organização da estrutura que se pretende criar, ao nível dos Temas e geometrias possíveis (a sua definição em pormenor é feita noutros locais como se vai poder perceber). Anexo C – As Classes e Relacões na IGeoE_BDG 1
Anexo C – As Classes e Relacões na IGeoE_BDG Extracto da modelação efectuada no respeitante a algumas das suas Classes e Relações implementadas. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig C‐1 A definição das Classes que foram definidas dentro do Tema da Altimetria. Fig C‐2 Na cor verde podem ver‐se as características inerentes à Classe das Curvas de Nível (os atributos por defeito e a classificação das respectivas curvas (as entidades que constituem a Classe) ‐ segmento a verde). Fig C‐2 Na cor azul podem ver‐se as características inerentes à Classe Linha de Costa (os atributos por defeito e o único tipo de entidades que constituem a Classe) – seta a azul). Anexo C – As Classes e Relacões na IGeoE_BDG 2
Fig C‐3 A definição efectuada para a entidade Curva de Nível Mestra Par. Fig C‐4 A imagem apresenta a definição exaustiva de todos os atributos da Classe Curvas de Nível. Fig C‐5 A definição da relação existente entre os Castelos ou Fortes e as Capelas. Anexo C – As Classes e Relacões na IGeoE_BDG 3
Fig C‐6 A definição da relação existente entre as Pontes Largas de Betão e as Estradas Estreitas. Fig C‐7 Na figura apresentada é possível ver como se implementou uma Class Extension (incluindo um interface). Anexo C – As Classes e Relacões na IGeoE_BDG 4
Nas figuras que se seguem, apresentam‐se para o Tema Vias de Comunicação não só as Classes que a constituem mas também todas as suas entidades e respectiva distribuição pelas Classes. Fig C‐8 Fig C‐9 Fig C‐10 Fig C‐11 Anexo C – As Classes e Relacões na IGeoE_BDG 5
Fig C‐12 Anexo D – As Entidades Geográficas da IGeoE_BDG 1
Anexo D – As Entidades Geográficas da IGeoE_BDG Extracto da modelação efectuada no respeitante a algumas das Entidades Geográficas implementadas. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig D‐1 Alguns dos atributos, inicialmente, definidos para algumas das entidades pertencentes ao Tema Terreno. Fig D‐2 Informação relativa à definição dos atributos para a entidade escarpado. Anexo D – As Entidades Geográficas da IGeoE_BDG 2
Fig D‐3 A definição da entidade Heliporto, seus atributos e possíveis valores (de acordo com o FACC). Fig D‐4 A definição das geometrias possíveis para toda e qualquer uma das entidades criadas nesta modelação. Anexo D – As Entidades Geográficas da IGeoE_BDG 3
Fig D‐5 Para o Tema Altimetria encontram‐se sinalizados a azul as entidades geográficas e a verde os respectivos subtipos. Fig D‐6 Agrupados por cores podem ver‐se os binómios entidade – subtipo (respectivo) e uma visualização simples dos seus atributos. Anexo E – Rede Geométrica e Regras de Conectividade 1
Anexo E – Rede Geométrica e Regras de Conectividade Extracto de informação respeitante a Redes Geométricas e Regras de Conectividade in [ESRI, 2000e]. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig E‐1 Os dois tipos de redes (geométrica e lógica) que podem ser ser definidas neste tipo de projectos (fazendo uso das aplicações mencionadas) in [ESRI, 2000e] pp. 131. Anexo E – Rede Geométrica e Regras de Conectividade 2
Fig E‐2 Os tipos de ligações que se podem implementar entre entidades in [ESRI, 2000e] pp. 132. Pode ver‐se em ambas as imagens e para cada tipo de rede: •
•
Em cima rede geométrica Em baixo rede lógica Anexo F – Exportação para XML e Validação Semântica 1
Anexo F – Exportação para XML e Validação Semântica Extracto de imagens exemplificativas da exportação para XML e posterior Validação Semântica. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig F‐1 O primeiro passo na exportação do modelo construído para o formato XML. Fig F‐2 Execução e conclusão, com sucesso, na exportação do modelo construído para o formato XML. Anexo F – Exportação para XML e Validação Semântica 2
Fig F‐3 Execução da validação semântica no ficheiro XML acabado de criar (contém a informação relativa à estrutura da futura BDG). Fig F‐4 Definição da informação a incluir no relatório da validação Semântica e informação do resultado obtido aquando da execução da mesma. Anexo G – Criação da IGeoE_BDG 1
Anexo G – Criação da IGeoE_BDG Extracto de imagens exemplificativas da criação da IGeoE_BDG. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig G‐1 Criação de uma BDG “vazia” para depois se poder carregar a estrutura (do XML). Fig G‐2 Selecção do ficheiro em formato XML onde se encontra guardado o modelo (caso se repita este passo a aplicação guarda a informação e avisa sempre que existirem alterações). Anexo G – Criação da IGeoE_BDG 2
Fig G‐3 A pré visualização da estrutura da futura BDG. Fig G‐4 Esta pré visualização permite verificar a estrutura criada, permitindo inclusivé pequenas alterações. Anexo G – Criação da IGeoE_BDG 3
Fig G‐5 A estrutura de todas as características de cada entidade geográfica. Fig G‐6 Tanto antes de se proceder ao carregamento da estrutura na BDG vazia (que atrás foi criada) como à posteriori da sua execução é apresentado um relatório detalhado que inclui uma descrição de todas as operações efectuadas. Anexo G – Criação da IGeoE_BDG 4
Fig G‐6 Apresentação da estrutura final obtida na modelação da BDG para a série M888 na escala 1:25 000 do IGeoE. Anexo H – Carregamento da IGeoE_BDG 1
Anexo H – Carregamento da IGeoE_BDG Extracto de imagens exemplificativas da metodologia de carregamento “automático” da IGeoE_BDG. Nota: a informação relativa a alguns dos elementos apresentados é apenas um extracto da totalidade da mesma visto que pela sua dimensão não permitiria uma visão de conjunto conveniente de toda a informação. Fig H‐1 Em cima à esquerda encontra‐se seleccionada (a azul) a ferramenta desenvolvida para efectuar a conversão e carregamento da informação para a IGeoE_BDG (a ferramenta possui incluidos todos os processos criados para executar todas as conversões e carregamentos de modo a partir do DGN do IGeoE e terminar com a IGeoE_BDG ). Fig H‐2 À esquerda pode‐se ver um extracto do modelo criado para converter a informação armazenada em ficheiros do tipo CAD e converter para o tipo SHP (leva com ela a informação relativa à toponímia, entidades representadas por células, etc...) Anexo H – Carregamento da IGeoE_BDG 2
Fig H‐3 A aplicação desenvolvida em VB6 para executar os modelos apresentados (na imagem anterior ) esta ferramenta permite, de um modo user friendly, seleccionar de uma só vez (independentemente do número) quais os ficheiros a converter de maneira a que se prossiga para as restantes fases de conversões e carregamentos. Anexo H – Carregamento da IGeoE_BDG 3
Fig H‐4 Na imagem de topo pode ver‐se o modelo completo, enquanto que na outra image, a central, permite verificar quais as ferramentas utilizadas, parametrizações impostas e metodologia seguida para converter com sucesso a entidade Portagem em Via Única ou Dupla (abordada e descrita no cap III – 3.3 Uma Metodologia de Carregamento). Anexo H – Carregamento da IGeoE_BDG 4
Fig H‐5 Extracto do relatório do modelo de carregamento criado no que se refere a todas as variáveis parametrizadas. É possível seleccionar todas e cada uma delas, obtendo um relatório mais pormenorizado de cada uma. Fig H‐6 Extracto do relatório do modelo de carregamento criado no que se refere a todas os processos utilizados, ferramenras implementadas e respectivas parametrizações. É também aqui possível seleccionar todas e cada uma delas, obtendo um relatório mais pormenorizado de cada uma. Anexo H – Carregamento da IGeoE_BDG 5
Fig H‐7 Extracto do relatório que é possível gerar sobre cada ferramenta programada para cada passo das conversões e carregamentos efectuados.