FERRAMENTAS UTILIZADAS PARA CRIAR A INTERFACE

O desenvolvimento da interface do sistema será implementada na linguagem Java utilizando a biblioteca Geotools versão 2.2-RC0, versão estável.

Java é uma linguagem que não se prende a nenhuma arquitetura e a nenhuma empresa, é rápida e estável. Pode construir sistemas críticos, sistemas que precisam de velocidade e até sistemas que vão para fora do planeta, como a sonda Spirit enviada pela Nasa para Marte.

Java tem um mar de projetos open source, que estão lá, esperando por usuários e desenvolvedores. Java é multiplataforma, ou seja, aplicação é executada a partir de uma maquina virtual, tornando a aplicação independente de sistemas operacionais.

O NetBeans é um projeto open source fundado pela Sun Microsystems em junho de 2000. A IDE NetBeans é um ambiente de desenvolvimento - uma ferramenta pra programadores, que permite escrever, compilar, debugar e instalar programas. A IDE é completamente escrita em Java, mas pode suportar qualquer linguagem de programação.

Existem também um grande número de módulos para estender a IDE NetBeans. A IDE NetBeans é um produto livre, sem restrições de uso.

O GeoTools é uma biblioteca Java Open Source que fornece métodos para manipulação de dados geo-espaciais, viabilizando, por exemplo, para a implementação de um GIS (Geographic Information System). A biblioteca GeoTools implementa as especificações da OGC (Open Geoespatial Consortium), em colaboração com o projeto GeoAPI, que é uma comunidade de desenvolvedores que projetam e implementam, nesta linguagem, soluções de interfaces derivadas de padrões da OGC/ISO para projetos de SIG desenvolvidos na linguagem Java (Figura 8 e 9).

Entre os recursos deste conjunto de ferramentas, apresentamos algumas características e potencialidades desta biblioteca:

• Suporte para inúmeros formatos vetoriais e matriciais:

o ESRI® Shapefile (escrita e leitura);

o GML (somente leitura em desenvolvimento);

o WFS (somente leitura em desenvolvimento);

o PostGIS (escrita e leitura);

o Oracle® Spatial (somente leitura);

o ESRI® ArcSDE (somente leitura);

o MySQL;

o GeoMedia (somente leitura);

o Tiger (somente leitura);

o VPF (somente leitura em desenvolvimento);

o MapInfo – par MIF e MID (somente leitura);

o ArcGrid – ArcInfo ASCII Grid e GRASS ASCII Grid (leitura/escrita);

o GeoTIFF (somente leitura em desenvolvimento);

o Imagens com georeferenciamento baseado em “arquivo de mundo”

(leitura/escrita);

o WMS (somente leitura em desenvolvimento).

• Análises topológicas sobre as geometrias (JTS –Java Topology Suite);

• Transformação de coordenadas;

• Implementações para renderização.

GeoTools é usado por muitos projetos, incluindo WFS (Web Feature Servers), WMS (Web Map Servers) e aplicações desktop. Vejamos alguns dos projetos que implementam Geotools:

• GeoServer – OGC Web Característica Serviço (WFS) implementação de referência

• GeoVISTA Studio – Visualização de Códigos e ambiente de construção de modelos

• MyMaps

• The Ballon Project

• uDig—User-friendly Desktop Internet GIS (Figura 8)

FIGURA 8: UDIG – USER-FRIENDLY DESKTOP INTERNET GIS F^ONTE: ^{RETIRADADEHTTP}://^GEOTOOLS.^CODEHAUS.^ORG/

FIGURA 9: SIG DESENVOLVIDOUTILIZANDO GEOTOOLSEM NETBEANS

FONTE: RETIRADADEHTTP://GEOTOOLS.CODEHAUS.ORG/

4 Estudo de Caso

No processo de construção de modelos busca-se abstrair aspectos relevantes de uma totalidade deixando para segundo plano os aspectos menos importantes. Para cada nível de abstração existe um modelo correspondente que o caracteriza. O Nível Conceitual a informação em modelos conceituais. De um modo geral, os modelos conceituais de dados permitem representar a realidade da aplicação. Definem como cada entidade será armazenada, independente da tecnologia escolhida, apresentando como resultado final, o esquema do banco de dados.

Até o aparecimento dos primeiros SIG, praticamente nada existia em termos de representação específica em modelo de dados de entidades geográficas ou espaciais. Diversas propostas foram sendo desenvolvidas, principalmente focalizadas em estender os modelos criados para aplicações convencionais às aplicações geográficas. No entanto, modelos de dados para aplicações geográficas têm necessidades adicionais, tanto com relação à abstração de conceitos e entidades, quanto ao tipo de entidades representáveis e seu inter- relacionamento. Para dar respaldo às características particulares da representação conceitual de dados geo-espaciais, surgem as primeiras propostas de modelagem baseada em Ontologias.

Ontologias são abstrações que descrevem diferentes tipos de organização de dados como tabelas relacionais, textos e imagens em um senso georeferenciado (Fonseca, 2001). A expressividade oferecida pelas ontologias permite interoperar informações geográficas no nível semântico.

Chama-se a atenção para o fato de que os SIG são sistemas multidisciplinares, ou seja, podem ser utilizados por diferentes comunidades de usuários, cada uma com seus interesses e conhecimentos próprios (geólogos, sociólogos, biólogos, engenheiros, etc.). Desta forma, visões de conhecimento sobre uma mesma realidade precisam ser combinadas de modo a atender às necessidades de cada comunidade. Pessoas com interesses diferentes

identificam de formas diferentes a mesma região geográfica. Um dos pontos básicos destas diferenças é refletido nos nomes dados às entidades do mundo real. Estas entidades geográficas, coletadas e armazenadas em BDG são chamadas de feições na literatura de referência da área. Feições geográficas são coletadas e modeladas por um modelo conceitual.

Associado ao fator da multidisciplinaridade tem-se ainda que os SIG manipulam diferentes formatos, tipos e semânticas de dados. Não existe consenso entre as Instituições publicas ou privadas no sentido de padronizar conceitos e conteúdos, já que estas instituições produzem seus próprios modelos semânticos.

Baseado neste contexto, optou-se por modelar conceitualmente a base de conhecimento do sistema em ontologia. O objetivo da modelagem semântica baseada em ontologia reside no fato de que o sistema possa adaptar, filtrar ou explicar a informação, armazenada em sua base de dados, para os diferentes tipos de usuários. Por exemplo, o fato de um SIG explicar para um sociólogo o significado de alguns conceitos geológicos pode ser importante para que o sociólogo entenda a razão de determinadas decisões técnicas de um geólogo. De maneira geral, uma ontologia tem como objetivo compartilhar conhecimento comum sobre a estrutura da informação entre pessoas, sistemas, agentes de software e etc.

Além disso, permite a reutilização do conhecimento sobre um domínio, introduzindo padrões que permitam a interoperabilidade entre aplicações (Pelazzo, 2006). A capacidade de integrar múltiplos domínios com diferentes significados para os diferentes usuários (e sistemas) que irão utilizá-los é chamada de interoperabilidade KASHYAP (1996), HARVEY (1999) APUD FONSECA (2001). Ainda não existe um consenso na exata definição de ontologia.

GUARINO et al. (1995) descrevem diversas interpretações que vêm sendo utilizadas na literatura:

 Ontologia como uma disciplina filosófica;

 Ontologia como um sistema conceitual informal;

 Ontologia como um cálculo da semântica formal;

 Ontologia como uma especificação de uma conceitualização caracterizada por:

 Propriedades formais específicas e

 Somente por propósitos específicos;

 Ontologia como o vocabulário usado por uma teoria lógica;

 Ontologia como uma especificação de uma teoria lógica (meta-level).

A geração da base de conhecimento em ontologia é feita a partir do processamento de classes que representam o conhecimento dos usuários e de classes que representam o conhecimento do SIG. As ontologias que representam o conhecimento do SIG são formadas por conceitos manipulados pelo SIG. As ontologias que representam o conhecimento dos usuários são formadas por conceitos que podem ser apresentados aos usuários pela interface do SIG, e que os usuários tenham um entendimento claro do que os mesmos significam.

No caso da criação da classe Unidade, duas ontologias foram utilizadas, uma ontologia urbana e uma ontologia geométrica. A ontologia urbana permite identificar as características semânticas das classes do Plano de Informação Turismo, já a ontologia geométrica permite a localização (coordenadas geográficas) e a geometria da classes (se é um polígono, linha ou ponto).

Owl:

Sigma-tur

ObjetoEspacial

ObjetoTemporal

ObjetoEspacoTemporal AcomodacaoStatus

EventoCultural Evento

PosicaoEspacoTemporal

Tempo Posicao

É_um É_um

É_um É_um

É_um É_um

TemPosicaoEspacial

TemPosicaoTemporal

TemPosicaoEspacoTemporal

É_um É_um

(X,Y, t )

Expoama:Feira de Agro-negócio FeiraExposicoes

É_um InstânciaDe

InstânciaDe

Tem Posi caoE spac oTem pora l

FestaCírio InstânciaDe

Tem Posi caoE spac oTem pora l

F^IGURA10: O^{NTOLOGIAGEOGRÁFICAPARCIALDO} P^LANODE I^NFORMAÇÃO T^URISMOPARAO M^UNICÍPIODE MARABÁ - OBJETOSESPAÇO-TEMPORAIS

F^ONTE: WEITZEL ^ETAL.(2008)

OWL:

SIGMA-TUR

ObjetoEspacial

ObjetoTemporal

ObjetoEspacoTemporal

PosicaoEspacoTemporal

Tempo Posicao

É_um É_um

É_um É_um

É_um

TemPosicaoEspacial

TemPosicaoTemporal

TemPosicaoEspacoTemporal (X,Y)

Praia Tucunaré InstânciaDe

InstânciaDe

TemPosicaoEspacial

AtividadesTurísticas

Pescaria

É_um

Tem Po sica oE spac oTem po ral

Inst ânci aDe

(X,Y, t ) Tem Posi caoE spac oTem pora l

Inst ânci aDe AtributosNaturais

É_um

F^IGURA 11: O^{NTOLOGIAGEOGRÁFICAPARCIALDO} P^LANODE I^NFORMAÇÃO T^URISMOPARAO M^UNICÍPIODE M^ARABÁ- ^{OBJETOSESPACIAIS}

FONTE: WEITZEL ETAL.(2008)

Além das classes descritas na Figura 10, construídas utilizando o Protegé, foram especificadas as classes que referenciam a geometria dos objetos (polígono, linha e ponto), a divisão municipal em Distritos (Pioneiro, Cidade Nova, Industrial, de Expansão e Nova Marabá), e os componentes dos distritos em Quadras, Lotes, Unidades e Ruas (e trechos de ruas), Figura 12.

Owl:

Sigma-tur

ObjetoEspacial

ObjetoTemporal

Distrito

PosicaoEspacoTemporal

Tempo Posicao

É_um

É_um

É_um É_um

É_um TemPosicaoEspacial

TemPosicaoTemporal

FazParteDe Unidade Quadra

Lote

Rua/TrechoRua TemPosicaoEspacial

FazParteDe FazParteDe FazParteDe

Geometria TemGeometria

Pioneiro

InstânciaDe

F^IGURA 12: O^{NTOLOGIAGEOGRÁFICAPARCIALDO} P^LANODE I^NFORMAÇÃO T^URISMOPARAO M^UNICÍPIODE M^ARABÁ- ^{GEOMETRIA EOUTRASCLASSES}

FONTE: WEITZEL ETAL.(2008)

Uma ontologia OWL - Ontologies Web Language (Linguagem de Ontologias para Web) pode incluir as decrições das classes, propriedades e suas instâncias. Abaixo na Figura 13 tem-se trechos da ontologia com as descrições das classes, propriedades dos objetos, dados da propriedade e alguns objetos que foram instanciados, por simplificação foram omitidos trechos da codificação.

....Ontology(<http://www.owl-ontologies.com/SIGMATUR.owl>

Comment("Ontologia espaco-temporal do setor de turismo do Municipio de Maraba") // Class: http://www.w3.org/2002/07/owl#Thing

// Class: http://www.owl-ontologies.com/SIGMATUR.owl#AcomodacaoStatus

EquivalentClasses(AcomodacaoStatusObjectOneOf(TresEstrelas,DuasEstrelas,UmaEstrels)) // Class: http://www.owl-ontologies.com/SIGMATUR.owl#IntermediacaoServicoTurismo Declaration(OWLClass(IntermediacaoServicoTurismo))

SubClassOf(IntermediacaoServicoTurismo ObjetoEspacial) // Class: http://www.owl-ontologies.com/SIGMATUR.owl#Rua Declaration(OWLClass(Rua))

SubClassOf(Rua ObjetoEspacial)

// Class: http://www.owl-ontologies.com/SIGMATUR.owl#Unidade )...

// Object property: http://www.owl-

ontologies.com/SIGMATUR.owl#TemPosicaoEspacoTemporal Declaration(ObjectProperty(TemPosicaoEspacoTemporal))

ObjectPropertyDomain(TemPosicaoEspacoTemporal ObjetoEspacoTemporal) // Object property: http://www.owl-ontologies.com/SIGMATUR.owl#TemStatus ObjectPropertyDomain(TemStatus Acomodacao)

ObjectPropertyRange(TemStatus AcomodacaoStatus)

FIGURA 13: ONTOLOGIAGEOGRÁFICAEM OWL (TRECHOS) F^ONTE: WEITZEL ETAL.(2008)

Foi utilizado a linguagem RDF (resource description format) e esquemas em RDF como meios de atribuir semântica aos elementos estruturais. A RDF é codificada como um conjunto de tripla: (assunto, verbo e objeto). Em RDF, um documento declara que uma entidade em particular tem propriedades (é_um, tem_relacao_com) com outra entidade. Estas triplas podem ser escritas em tags de XML (Dornfest et al (2001). Na figura 14 ilustra-se apenas um exemplo dos construtores taxonômicos das classes RDF que foram gerados.

<!-- http://www.owl-ontologies.com/SIGMATUR.owl#TemAcomodacao -->

<owl:ObjectProperty rdf:about="#TemAcomodacao">

<rdfs:range rdf:resource="#Acomodacao"/>

<rdfs:domain rdf:resource="#Distrito"/>

</owl:ObjectProperty>

<!-- http://www.owl-ontologies.com/SIGMATUR.owl#TemAtividade -->

<owl:ObjectProperty rdf:about="#TemAtividade">

<rdfs:range rdf:resource="#AtividadeTuristica"/>

<rdfs:domain rdf:resource="#Distrito"/>

</owl:ObjectProperty>

<!-- http://www.owl-ontologies.com/SIGMATUR.owl#TemPosicaoEspacial -->

<owl:ObjectProperty rdf:about="#TemPosicaoEspacial">

<rdfs:domain rdf:resource="#ObjetoEspacial"/>

</owl:ObjectProperty>

FIGURA 14: CONTRUTORESEM RDF (TRECHOS) F^ONTE: WEITZEL ^ETAL.(2008)

Na figura 15, apresentamos o diagrama de temas de aspectos turísticos de interesse do projeto SIGMA – Cadastramento Georreferenciado de Informações Turísticas, de forma hierarquizada, delimitando os tipos de informações relevantes neste sistema, baseando-se nos interesses da atividade turística. O Diagrama apresenta os planos: transportes, praias, pontos ecológicos, gastronomia, hospedagem, edificações, praças, diversão. Cada um destes planos apresenta subdivisões, detalhando os serviços que são oferecidos em cada segmento. O mais alto nível nesta hierarquia, é o distrito, neste caso, Marabá Pioneira.

FIGURA 15: DIAGRAMADE TEMASDEASPECTOS TURÍSTICOSDEINTERESSEDOPROJETO

FONTE: ELABORAÇÃO PRÓPRIA (2008)

As fases de implementação seguiram os passos descritos no diagrama a seguir (figura 16), inicialmente trabalhamos com o mapa no formato DXF, gentilmente cedido pelo grupo de SIGMA (habitação), depois usamos o SPRING, para importação das layers, resultando nos shapefiles, que por sua vez foram utilizados para elaboração do banco de dados geográfico no Postgre/Postgis, este foi integrado com o API Geotools através de um API JDBC, e por fim uma interface foi elaborada, apresentando de forma transparente a consulta dos locais e suas respectivas localizações.

F^IGURA 16. D^{IAGRAMADASFASESDE}IMPLEMENTAÇÃODOSISTEMA

FONTE: ELABORAÇÃOPRÓPRIA

API JDBC Postg reSQL Mapa

Auto CAD

1º Passo Coleta da Base de Dados

2º Passo Criação do BDG

3º Passo Implementação da Interface de Aplicação

4º Passo Implementação da Interface Gráfica

SPRING Postg

reSQL +

PostGIS API Geotools Interface Gráfica Java

Shapefiles

Na fase inicial do projeto, a base cartográfica cedida pela prefeitura de Marabá, estava no formato nativo do AutoCad, foi necessário fazer uma exportação para o formato DXF- R12, com esta extensão foi possível trabalhar com o mapa no Spring, com a finalidade de extrair separadamente as camadas do plano de informação turismo: quadras, unidades (que referenciam as unidades turisticas, ou simplesmente turismo) lotes e vias, e fazer a exportação dessas camadas no formato Shapefile. Para que fosse possível a exportação, criou-se um banco de dados denominado “Turismo” no Spring, o passo seguinte foi a criação de um projeto (figura 17). As informações contidas no projeto referentes à base cartográfica são:

Projeção: É a projeção da terra no plano, ou seja, o mapa. Quando se projeta uma superfície esférica em um plano, como é o caso da terra, ela sofrerá deformações ou alterações. Um exemplo é quando se tenta planificar (achatar) uma laranja cortada ao meio.

Por esse motivo, as projeções derivam de três tipos: cilíndricas, cônicas e planas ou azimutais.

- Sistemas: UTM, trabalhamos com o sistema de projeção UTM (Universal Transverso Mercator) derivada da projeção cilíndrica, caracteriza-se por seus paralelos e meridianos se cruzarem em linha reta num ângulo de 90°, preservado a integridade dos ângulos, mas ampliando exageradamente áreas extensas ou em latitudes elevadas. O sistema UTM divide o mapa em 60 fusos ou zonas, de maneira que cada zona cobre a longitude de 6°.

- Modelos da Terra: SAD69, um datum caracteriza-se por uma superfície de referência posicionada em relação a terra. O South American Datum ( SAD ) foi estabelecido como o sistema geodésico regional para a América do Sul, desde 1969. O SGB (Sistema Geodésico Brasileiro) integra o SAD69.

- Longitude: 0 51 0 0

- Zona: 22, referente a zona que se encontra a cidade de Marabá.

Retângulo Envolvente: Coordenadas x1, x2, y1,y2 do retângulo envolvente do mapa.

FIGURA 17: CRIAÇÃODE PROJETONO SPRING

F^ONTE: E^LABORAÇÃO P^RÓPRIA

Com o projeto ativo, criou-se o modelo de dados, neste caso optou-se pelo modelo de dados cadastral.

A importação dos dados foi feita selecionando as camadas (layer), uma a uma e associando-as a um plano de informação (figura 18). Esses planos de informação fazem parte da categoria denominada Marabá, criada anteriormente no modelo de dados.

O passo seguinte foi mostrar o mapa, selecionando no painel de controle os layers e clicando no botão desenhar (figura 19).

F^IGURA 18: I^{MPORTAÇÃODABASE}CARTOGRÁFICA

FONTE: ELABORAÇÃO PRÓPRIA

FIGURA 19: ILUSTRANDOOSLAYERSNATELA

F^ONTE: E^LABORAÇÃO P^RÓPRIA

A importação foi realizada selecionado um layer no painel de controle e exportando-o

para o formato Shapefile. O Shapefile é composto de três arquivos

Através do PostGis, que é uma extensão espacial do PostGre, criou-se um banco de dados denominado Turismo, que suporta tabelas espaciais e tabelas convencionais de dados.

Os shapefiles importados para a base de dados geraram automaticamente uma tabela espacial.

A importação foi realizada através da Interface de linha de comando do SGBD (Sistema Gerenciador de Banco de Dados) utilizando o shp2pgsql, um carregador de dados que cria uma tabela e insere dados do arquivo shapefile. A linha de comando para a importação é composta dos seguintes parâmetros (figura 20):

shp2pgsql –s 4291 nome_do_shape nome_da_tabela > nome_do_arquivo.sql

O parâmetro –s faz correspondência à localização no Hemisfério Sul e o número 4291, juntamente com o parâmetro anterior, faz referência ao SRID - (Identificador do Sistema de Referência Espacial).

Os Shapefiles e o shp2pgsql devem estar em um mesmo diretório, neste caso, colocou- se os arquivos na pasta shapes. A importação gera um arquivo .sql, que é executado no pgAdmin, criando então a tabela.

F^IGURA 20: I^MPORTANDOO S^HAPEFILE Q^UADRAS FONTE: ELABORAÇÃO PRÓPRIA

As tabelas espaciais originadas pela importação dos shapefiles foram: Lotes, Quadras

e Unidades formadas por objetos espaciais do tipo polígono, e Vias formadas por objetos espaciais do tipo linha, estas tabelas têm em comum os campos (figura 21):

- gid: chave primária do tipo inteiro e de auto incremento.

- sprarea: campo do tipo numérico que guarda informações da área do polígono ou linha.

- sprperimet: campo do tipo numérico que guarda informações do perímetro do polígono ou linha.

- sprclasse: campo do tipo string vazio.

- the_geom: campo do tipo geometry que guarda em hexadecimal as coordenadas geográficas do polígono ou linha.

FIGURA 21: TABELA ESPACIALDE LOTES

F^ONTE: E^LABORAÇÃO P^RÓPRIA

Para elaboração do banco de dados foi considerado o modelo conceitual baseado em ontologias, sendo necessário à implementação das seguintes tabelas:

- Tabela Tipo atributos naturais: composta pelo campo código do tipo (chave

primária), e o campo nome (figura 22), sendo classificados da seguinte forma: 01 Parques, 02 Reservas, 03 Bosques, 04 Zoológicos e 05 Praias.

FIGURA 22. TABELA SUBTIPOATRIBUTOSNATURAISNO PGADMIN

F^ONTE: E^LABORAÇÃO P^RÓPRIA

- Tabela Atributos Naturais: composta pelos campos: código do atributo (chave primária); código do tipo, chave estrangeira referente à tabela Tipo Atributos Naturais; o nome que caracteriza o local, endereço, telefone, informações, horário de funcionamento, url e o campo Gid (figura 23), que é o identificador geográfico, permitindo a pesquisa da sua localização, uma chave estrangeira que referencia da tabela quadra.

F^IGURA 23. T^ABELA A^TRIBUTOS N^ATURAISNO P^GA^DMIN FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Tipo Atributos Culturais: composta pelo campo código do tipo (chave primária), e o campo nome (figura 24), sendo classificados da seguinte forma: 01 Museus, 02 Praças, 03 Monumentos e 04 Mercados Municipais.

F^IGURA 24. T^ABELA T^IPO A^TRIBUTOS C^ULTURAISNO P^GA^DMIN FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Atributos Culturais: composta pelos campos: código do atributo(chave

primária); código do tipo, chave estrangeira referente a tabela Tipo do Atributo Cultural; o nome que o caracteriza, bem como o endereço, telefone, informações, horário de funcionamento, url e o campos Gid (figura 25), também chaves estrangeira referenciando as tabelas quadra e unidade.

F^IGURA 25. T^ABELA A^TRIBUTOS C^ULTURAISNO P^GA^DMIN FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Tipo Produtos de Turismo: composta pelo campo código do tipo (chave primária), e o campo nome (figura 26), sendo classificados da seguinte forma: 01 Artesanato e 02 Gastronomia.

FIGURA 26. TABELA TIPO PRODUTODE TURISMONO PGADMIN

F^ONTE: E^LABORAÇÃO P^RÓPRIA

- Tabela Produtos de Turismo: composta pelos campos: código do produto de turismo (chave primária); código do tipo, chave estrangeira referente a tabela Tipo Produto de Turismo, o nome que o caracteriza, bem como o endereço, telefone, informações, horário de funcionamento, url e o campo Gid (figura 27), também chave estrangeira referenciando a

tabela unidade.

FIGURA 27. TABELA PRODUTOSDE TURISMONO PGADMIN

FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Tipo Serviços de Apoio: composta pelo campo código do tipo (chave primária), e o campo nome (figura 28), sendo classificados da seguinte forma: 01 Bancos, 02 Correios, 03 Hospitais e Delegacias.

F^IGURA 28. T^ABELA T^IPO S^ERVIÇOSDE A^POIONO P^GA^DMIN FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Serviços de Apoio: composta pelos campos: código do produto de turismo (chave primária); código do tipo, chave estrangeira referente a tabela Tipo Serviços de Apoio, o nome que o caracteriza, bem como o endereço, telefone, informações, horário de funcionamento, url e o campo Gid (figura 29), também chave estrangeira referenciando a tabela unidade.

FIGURA 29. TABELA SERVIÇODE APOIONO PGADMIN

FONTE: ELABORAÇÃO PRÓPRIA

- Tabela Tipo Serviços de Turismo: composta pelo campo código do tipo (chave primária), e o campo nome (figura 30), sendo classificados da seguinte forma: 01 Alimentação, 02 Hospedagem e 03 Intermediação de serviços.

F^IGURA 30. T^ABELA T^IPO S^ERVIÇOSDE T^URISMONO P^GA^DMIN F^ONTE: E^LABORAÇÃO P^RÓPRIA

- Tabela Subtipo Serviços de Turismo: composta pelo campo código do tipo (chave primária); código do tipo, chave estrangeira referente a tabela Tipo Serviços de Turismo e o campo nome (figura 31).

F^IGURA 31. T^ABELA S^UBTIPO S^ERVIÇOSDE T^URISMONO P^GA^DMIN F^ONTE: E^LABORAÇÃO P^RÓPRIA

- Tabela Serviços de Turismo: composta pelos campos: código do produto de turismo (chave primária); código do subtipo, chave estrangeira referente a tabela Subtipo Serviços de Apoio, o nome que o caracteriza, bem como o endereço, telefone, informações, horário de funcionamento, url e o campo Gid (figura 32), também chave estrangeira referenciando a tabela unidade.

F^IGURA 32. T^ABELA S^ERVIÇODE A^POIONO P^GA^DMIN FONTE: ELABORAÇÃO PRÓPRIA

Para a renderização, ou seja, a visualização do mapa contido no BDG, tal como os

No documento TCC _Sistema de informação geográfica (SIG).pdf (páginas 35-74)