Português (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
1. INTRODUÇÃO
Um dos maiores desafios para os estados modernos é a proposição e a implementação de políticas públicas capazes de atender às necessidades da população. Diante da importância dessa problemática, torna-se obscuro imaginar alguma política pública definida e realizada sem o uso de informação confiável.
As tecnologias da informação, resultantes de processos sociais de diversas naturezas, se afirmaram como uma condição para as transformações econômicas e socio-espaciais ocorridas em escala mundial nas últimas décadas. Diante dos avanços tecnológicos, é fundamental discutir as possibilidades das mudanças que essas ferramentas proporcionam, a fim de aprimorar o gerenciamento do território. Nesse sentido, é importante perceber o desenvolvimento tecnológico da informação geográfica, dos Sistemas de Informação Geográfica (SIGs) e dos Sistemas de Gerenciamento de Banco de Dados (SGBD), com o intuito de subsidiar o aprimoramento técnico da administração territorial.
Embora seja uma discussão atual, a questão da sistematização do território é uma preocupação antiga, e foi o cadastro francês, produzido no início do século XIX, o precursor dos cadastros modernos, por reconhecer a importância de mapas em grande escala e de um levantamento cadastral sistemático baseado em parcelas, como destacou Carneiro (2003, p. 29-30). Desse modo, o presente trabalho realiza um estudo de caso do Cadastro Territorial Urbano (CTU) de João Pessoa, capital da Paraíba, Brasil, para abordar a práxis e produzir uma discussão teórica sobre as parcelas, as menores unidades espaciais desse sistema territorial, a partir do desenvolvimento e aplicação de um modelo OMT-G, a fim de propor possíveis contribuições.
Os SIGs são uma tecnologia multidisciplinar que está na fronteira de diversas áreas do conhecimento, por isso são percebidas de maneira diferente por especialistas de diferentes áreas. Esses sistemas possuem o potencial de otimizar a forma como as prefeituras lidam com seu CTU, sendo fundamental no desenvolvimento desses sistemas a elaboração de um modelo de informação geográfica coeso para a implementação de um banco de dados geográfico relacional (BDG-R) consistente.
Nessa discussão sobre sistemas de administração territorial, é fundamental mencionar a norma internacional de informação geográfica - ISO 19152.2012, Geographic Information -Land Administration Domain Model (LADM). O LADM é um framework baseado no marco conceitual da obra “Cadastre 2014 - A Vision for a Future Cadastral System” da Fédération Internationale des Géomètres (FIG) de 1998 (ISO 19152:2012, p.vi).
O projeto da obra “Cadastre 2014”, da FIG, foi iniciado em 1994 realizando um estudo comparativo dos sistemas cadastrais no mundo, a fim de desenvolver uma nova visão de cadastro moderno para os próximos vinte anos. Essa iniciativa da FIG, com envolvimento do World Bank e da UN-Habitat, entre outros colaboradores, garantiu o desenvolvimento do LADM, esse modelo conceitual flexível e promissor que vem permitindo diversos países implementarem suas jurisdições e integrarem seus sistemas.
No Brasil, é consenso pela literatura acadêmica que a ausência de normas e padrões específicos para os mapeamentos em grandes escalas, sejam elas de referência ou cadastrais, causam problemas para a interoperabilidade das informações geográficas efetivas no país (Hasenack et al., 2013; Carissimi et al., 2011; Brasil, 2010; CONCAR, 2006; Pereira et al., 2003 apudMachado & Camboim, 2019; Ramos & Ugeda, 2019; Silva et al., 2021). As discussões sobre essa problemática são atuais, pertinentes e vastas, por isso é importante citá-las, pois entendo que é apenas no reconhecimento dos problemas que se buscam soluções.
Considerando o que foi levantado até aqui, este trabalho realiza uma breve apresentação em torno das legislações que tratam sobre o CTU no Brasil. Além disso, aborda o tema dos sistemas de administração territorial, comentando parte da teoria dentro desses manuais. No desenvolvimento prático do trabalho foi utilizada uma abordagem de Arquitetura Orientada por Modelos (MDA - Model-Drive Architecture), com a ferramenta OMT-G Design, para valer-se do PostgresSQL e das extensões espaciais PostGIS e AST_Postgis, cujas arquiteturas se integram ao SIG QGIS.
Nesse sentido, foi significativo utilizar a técnica de modelagem Object Modeling Technique for Geographic Applications - OMT-G no trabalho, pela existência dessa estrutura aberta (OpenSource), além de ser uma técnica indicada aos produtores de informação geográfica do país, de acordo com o documento de Especificação Técnica para a Estruturação de Dados Geoespaciais Vetoriais (ET-EDGV, 2017).
Após a presente introdução, o artigo segue estruturado da seguinte maneira: no segundo tópico são apresentados os materiais e métodos. No subtópico Materiais, são comentadas as ferramentas utilizadas, além das informações geográficas necessárias para o estudo de caso. Já no subtópico Métodos, é feita uma abordagem sobre a legislação e os sistemas de administração territorial, comentando acerca da unidade espacial dos sistemas, secção em que também é fundamentada a questão da modelagem do banco de dados geográficos e da técnica Object Modeling Technique - OMT-G. Mais adiante, no terceiro tópico, são apresentados os resultados e a discussão. Esse tópico é dividido em duas partes: a primeira consiste em um relato sobre o processo de elaboração do modelo do projeto e a execução da implementação do BGD-R, enquanto a segunda evidencia a execução da verificação do banco de dados geográficos implementado, para assim discutir o modelo. Por fim, o quarto tópico apresenta as considerações finais do trabalho.
2. MATERIAIS E MÉTODOS
2.1. Materiais
2.1.1. Softwares utilizados
PostgreSQL v. 10.3, compiled by Visual C++ build 1800, 64bit:
Originalmente desenvolvido em 1986 como parte do projeto POSTGRES da Universidade da Califórnia de Berkeley, há mais de trinta anos ativa, PostgreSQL ganhou forte reputação devido a comprovada confiabilidade da arquitetura do sistema, que integra dados com um conjunto de recursos robustos para manipulação com capacidade de extensão, fornecendo soluções inovadoras e de alto desempenho de maneira consistente. O PostgreSQL é executado nos principais sistemas operacionais existentes. É o mais avançado software livre (Open Source) de Banco de Dados Objeto Relacional do mundo.
pgAdmin 4:
O sistema de gerenciamento do PostgreSQL é o mais popular software livre de Sistema de Gerenciamento de Banco de Dados Objeto Relacional (SGBD-OR) do mundo.
PostGIS 2.3.4 r16312:
É uma extensão espacial aberta para o banco de dados do PostgreSQL. Promove a capacidade de trabalhar com objetos geográficos no banco de dados. É um projeto associado a Open Source Geospatial Foundation (OSGeo).
Ast_postgis:
O AST-PostGIS é uma extensão espacial aberta, criada em 2016 por Luiz Lizardo, orientando do professor Clodoveu Davis, do departamento de Ciências da Computação da Universidade Federal de Minas Gerais (UFMG). É uma poderosa e eficiente extensão espacial para PostgreSQL/PostGIS, que incorpora tipos de dados espaciais avançados e implementa restrições de integridade espacial do formato OMT-G.
QGIS versão 3.8.3-Zanzibar:
Inicialmente desenvolvido em 2002, como Quantum GIS e, a partir de 2007, tornou-se um projeto incubado pelo Open Source Geospatial Foundation (OSGeo), com a primeira versão lançada no início de 2009. É um proeminente SIG livre que integra a arquitetura do PostgreSQL e do PostGIS.
2.1.2. Aquisição de dados e área de estudo da aplicação
Para a elaboração de um modelo para o cadastro territorial básico de João Pessoa é preciso identificar as parcelas do município. No Decreto n.º 6.499 de 20 de março de 2009, que determina o Plano Diretor da cidade de João Pessoa, está registrada toda regulamentação do processo de parcelamento do solo, no qual foi constatado que, no município de João Pessoa, o processo de parcelamento na área urbana cria o lote como a unidade territorial que compõe seu cadastro (João Pessoa (PB), 2009). Essa situação parece ser bem comum no território brasileiro, como destacam Loch e Erba (2007, p. 32): “No contexto brasileiro, utilizam-se comumente os termos lote, para se referir à unidade de registro do Cadastro Urbano, e propriedade rural para o caso do Cadastro Rural”.
Para o desdobramento do modelo que permitiu discutir sobre o CTU de João Pessoa, foi essencial obter as informações geográficas de todas as entidades cujos atributos compõem a base para identificação da parcela (setor cartográfico, quadra e lote). Além dessas informações geográficas, é importante uma base cartográfica que permita criar a descrição do território a partir da visualização de toda a área para modelagem. Na tabela 1, constam as fontes das informações geográficas adquiridas e utilizadas no trabalho.
Tabela 1 Fonte e formato das informações geográficas
| Informação geográfica | Fonte | Formato |
|---|---|---|
| Lote | PMJP | Shapefile |
| Setor cartográfico | PMJP | Shapefile |
| Limite municipal | IBGE | Shapefile |
| Ortoimagem | PMJP | Geotiff |
A informação geográfica Lote é a base do cadastro do município, que contém todas as informações alfanuméricas utilizadas no presente trabalho. É referente a fevereiro de 2017, elaborado pela Prefeitura Municipal de João Pessoa (PMJP) e cedida pela mesma. Foi constatado que a base cadastral de lotes continha todas as informações necessárias para a elaboração de um modelo de cadastro, sendo percebido que uma pequena porção do território seria suficiente para o desenvolvimento do BDG-R.
Para a realização do trabalho foi escolhida uma área de duas quadras vizinhas (25081 e 25080) ao Instituto Federal da Paraíba (IFPB), localizadas no bairro de Jaguaribe, próximo ao centro de João Pessoa. A escolha se deu por se tratar de uma área conhecida que não teve mudanças significativas em relação à base cadastral de lotes de 2017, da PMJP, com a ortoimagem do aerolevantamento da PMJP, de 2012.
A ortoimagem utilizada é referente à folha 292-210 do ortomosaico1 de 2012 da PMJP, com pixel de aproximadamente 17cm. O produto que criou a base cartográfica permitiu manipular as informações geográficas para poder implementá-las ao BDG da aplicação, essencial para o desenvolvimento do trabalho, por permitir visualizar detalhes da área ortogonalmente.
Dessa maneira, foram adquiridas todas as informações geográficas necessárias para a elaboração do modelo de cadastro urbano de João Pessoa e a implementação do BDG-R. Na figura 1 está a visualização da área da aplicação do estudo.
2.2. Metodologia
2.2.1. Legislação cadastral urbana e produtores de informação geográfica - Brasil
No Brasil, o Ministério de Estado das Cidades instituiu a legislação que estabeleceu as diretrizes para a criação do Cadastro Territorial Multifinalitário (CTM) no país, definida a partir da Portaria n.º 511 de 7 de dezembro de 2009, que determina: “quando adotado pelos Municípios brasileiros, será o inventário territorial oficial e sistemático do município e será embasado no levantamento dos limites de cada parcela, que recebe uma identificação numérica inequívoca” (Brasil, 2009).
Ainda de acordo com a Portaria n.º 511, é considerada parcela cadastral toda e qualquer porção da superfície no município a ser cadastrada como a menor unidade do sistema cadastral, definida como uma parte contígua da superfície terrestre com regime jurídico único. Em seu Artigo 15, é indicado um método para o cadastro do identificador numérico inequívoco da parcela, a partir dos atributos geográficos específicos das entidades do cadastro. Cabe perceber que no Brasil, quando se trata do CTU, os profissionais técnicos da área se referem à concepção de CTM, por conta da legislação. É válido ressaltar que a responsabilidade da produção e da administração dos dados cadastrais no Brasil é dividida entre o Instituto Nacional de Colonização e Reforma Agrária (INCRA), nas áreas rurais, e as prefeituras, nas áreas urbanas.
Outra legislação relevante a ser citada é o Decreto n.º 8.764, de 10 de maio de 2016, que instituiu o Sistema Nacional de Gestão de Informação Territorial (SINTER). Este projeto colaborativo, sob a gestão da Secretaria da Receita Federal, visa integrar o Registro de Imóveis ao Cadastro Territorial em todo país. O decreto estipulou a Comissão Nacional de Cartografia (CONCAR) como responsável pela elaboração da norma técnica que determina os padrões cartográficos da informação geográfica no Brasil, o já citado documento ET-EDGV, de 2017.
2.2.2. Cadastre 2014, Sistemas de Administração Territorial (SAT) e a unidade espacial
Para estudar a questão da unidade espacial nos sistemas de administração territoriais, é importante fazer uma breve caracterização dos pacotes do esquema conceitual do SAT LADM. A parte (Party) representa a pessoa física ou jurídica, ocupante e/ou proprietário da unidade espacial relacionada; Administrativo (Administrative) corresponde aos direitos, restrições e responsabilidades que incidem sobre cada unidade espacial. Por último, o pacote da Unidade Espacial (SpatialUnit) composta pelas parcelas, edifícios, redes de infraestrutura e cada unidade cadastrada. Este pacote inclui o subpacote referente ao Levantamento e Representação (Surveying and Representation). É relevante para o trabalho apresentar a definição do Cadastre 2014:
(...) é um inventário público metodicamente arranjado de dados relativos a todos os objetos legais da terra dentro de um determinado país ou distrito, baseado no levantamento de seus limites. Esses objetos legais da terra são sistematicamente identificados por meio de alguma designação separada. Eles são definidos tanto pelo privado como pelo direito público. Os contornos da propriedade, as identificações junto com os dados descritivos, podem mostrar para cada objeto natural da terra, tamanho, valor e direitos legais ou restrições associadas ao objeto da terra (Kaufmann & Steudler, 1998, p. 15).
É considerável saber que essa definição do Cadastre 2014 é baseada na definição de Henssen de 1995 sobre o Cadastro. A diferença das definições é vista nos termos utilizados: a parcela é referida como objeto legal da terra ou como unidade espacial na ISO 19152.2012, remetendo à uma concepção do cadastro mais atual, como um sistema administrativo territorial. Além disso, um sistema cadastral baseado no Cadastre 2014 se propõe a responder perguntas relacionadas não apenas a onde e quanto, mas também a quem e como.
Desse modo, vale evidenciar algumas colocações sobre o anexo G da ISO 19152:2012, que trata sobre o trabalho de cooperação realizado entre os LADM e o Infrastructure for Spatial Information in the European Community (INSPIRE). Nesse anexo, é relatado que os projetos foram desenvolvidos ao mesmo tempo e que houve um trabalho conjunto das equipes envolvidas, para assegurar a consistência entre o INSPIRE e o LADM, embora seja colocado que há diferença no escopo e no resultado dos projetos, pois o LADM obteve maior êxito na característica de sistema multifinalitário. Cabe salientar que foi a partir do entendimento e das definições de classes relacionadas ao conceito de parcela que tornou possível a integração entre INSPIRE e o LADM, assim sendo, existe consenso entre os projetos para que o conceito de parcela seja a unidade espacial do sistema de administração territorial (ISO 19152:2012).
Portanto, para melhor usufruir do potencial desse sistema é preciso perceber a importância da unidade espacial, definindo classificações para esses espaços diferenciais. Para auxiliar o entendimento dos objetos identificados como parcelas, é relevante aludir sobre a ISO 19152:2012, especificamente o anexo D, com exemplos de perfis do LADM implementados em diferentes países. O que é pertinente relacionar ao trabalho é a respeito do pacote SpacialUnit do modelo português, visto na figura 2, comparando as especializações das parcelas à discussão do trabalho.
De acordo com a ISO 19152:2012, o conceito por trás do diagrama é que qualquer local dentro do território do país deve ser coberto por uma instância das três classes, ou seja, qualquer local pode ser classificado como um PT_ParcelG, um PT_SocialArea ou um PT_Baldio. A ISO 19152:2012(E) apresenta uma breve definição dessas classes:
⎯ PT_ParcelG: classe espacial que representa uma parcela pertencente ao bem imóvel privado legal regime. São as parcelas que podem ser legalmente registadas como entidade jurídica autônoma;
⎯ PT_SocialArea: vias públicas que atendem a diversos lotes, ou outras áreas do serviço público municipal ou domínio nacional (que não estão sob o regime de propriedade privada);
⎯ PT_Baldio: classe espacial sob regime jurídico específico, pertencente à comunidade local, conforme reconhecido na Constituição Portuguesa (p. 74).
No modelo do sistema de gerenciamento territorial português, a parcela PT_ParcelG tem função parecida com as parcelas de imóveis do cadastro urbano de João Pessoa, referenciadas como lote. Já a função da parcela PT_SocialArea é similar ao do objeto trecho_central, e a parcela PT_Baldio pode ser associada à calçada do modelo urbano do trabalho.
É pertinente saber que existem outros frameworks que servem para dar suporte ao desenvolvimento de SAT, como o Land Information System (LIS) e o GeoFrame. O desenvolvimento do modelo deste trabalho tem conceito semelhante ao diagrama da SpacialUnit do LADM português, e também possui semelhança com o pacote de Mapa Urbano Básico (MUB) do Framework GeoFrame, visto no artigo “Modelagem conceitual de banco de dados geográficos aplicada ao Cadastro Técnico Multifinalitário”, de Gonçalves et al. (2009).
2.2.3. Modelagem de banco de dados geográficos e a técnica Object Modeling Technique - OMT-G
Sobre os bancos de dados geográficos, é pertinente ressaltar que existem algumas maneiras de modelar sua estrutura. Inicialmente, os primeiros modelos para aplicações geográficas foram guiados a partir da existência interna das estruturas dos SIGs, forçando o usuário a ajustar a interpretação do fenômeno espacial à estrutura acessível (Casanova et al.,2005).
Foi percebido que mesmo as técnicas de modelagem de dados semânticos e orientados a objetos, como o conhecido Modelo Entidade (ER), ou o modelo Object Modeling Technique (OMT), não oferecem recursos adequados para representar as aplicações geográficas. Embora altamente expressivos, esses modelos apresentam limitações para representar informações geográficas, por não incluírem as primitivas geográficas.
Autores como Borges et al. (2001) apontaram que a dificuldade em usar os modelos citados acima em aplicações geográficas são incontáveis, devido ao fato de precisarem detalhar a localização, tempo de observação e acurácia.
A técnica de modelagem OMT-G tem a finalidade e a capacidade de promover soluções para essas questões, fornecendo primitivas que providenciam os meios para modelar a geometria e a topologia dos dados espaciais, suportando diferentes estruturas topológicas, múltiplas visualizações de objetos e relacionamentos espaciais que aumentam a capacidade de representação semântica do modelo e facilitam a criação de aplicações geográficas estáveis. Além de fazer parte das primitivas definidas para o diagrama de classes da Unified Modeling Language - UML (Borges et al., 2005).
É importante saber que o OMT-G tem dois tipos de classes básicas: classes georreferenciadas e classes convencionais. Através delas são representados os três tipos de dados: contínuo, discreto e não-espaciais. A classe georreferenciada é especializada em dois tipos, geo-campo e geo-objeto. São as especializações das classes georreferenciadas e as relações existentes que aumentam a capacidade de representação do modelo OMT-G.
No modelo do trabalho, é possível ver os dois tipos da classe básica da técnica OMT-G, com algumas das especializações geo-objetos, das classes georreferenciadas. Algumas entidades seriam melhor definidas como geo-campo, mas como o foco do modelo sobre cadastro é na identificação das parcelas numa área pequena com uma escala grande, não foi pertinente definir entidades do tipo geo-campo.
A figura 3 mostra dois tipos de relações espaciais, um é o da entidade trecho_central com a calçada, numa relação de proximidade (Near) de até 10m. O outro tipo de relação é topológica de rede (Arc-Node Network), a partir da especialização das classes trecho_central e cruzamento, geo-objetos com geometria e topologia denominados respectivamente de arco unidirecional e nó. Também é visto na figura 3 a agregação do trecho_central com logradouro, uma classe convencional.
3. RESULTADOS E DISCUSSÃO
3.1. Estrutura para elaboração do modelo de Cadastro e implementação do banco de dados geográfico
O modelo do trabalho foi desenvolvido na aplicação OMT-G Designer. Essa ferramenta online e aberta permitiu desenvolver o modelo lógico do cadastro e gerar o modelo físico do projeto. É importante salientar que para utilizar o modelo físico gerado da aplicação, foram realizadas pequenas modificações nas chaves estrangeiras das entidades do código gerado, sendo fundamental ter a extensão AST-PostGIS instalada ao banco de dados para implementar o código físico da aplicação.
A extensão AST-PostGIS permitiu ao SGBD averiguar com exatidão os tipos e as relações espaciais das entidades do modelo OMT-G. Tal constatação foi observada durante a implementação das informações ao BDG, pois quando as entidades espaciais não correspondiam com suas restrições espaciais, não era possível o registro no BDG-R. A afirmação de exatidão é apenas para os tipos e relacionamentos que constam no modelo.
O modelo do trabalho foi projetado apenas para utilizar a geometria do Setor cartográfico 25, onde se encontram as quadras da área de estudo. O foco do modelo de cadastro territorial apresentado é nas relações de dois objetos geográficos com o lote, parcela relacionada ao imóvel, ou seja, a unidade que compõe o inventário territorial oficial e sistemático do município de João Pessoa.
No modelo, o lote é representado como um objeto composto de duas formas de representação espacial, polígono para o limite do lote e linha para a face do lote, com as informações descritivas do lote na super classe convencional. O limite dos lotes é agregado espacialmente à quadra, com a classe convencional do lote também associada à quadra.
São dois os objetos que merecem atenção nesse modelo. O primeiro é a calçada, que foi dividida pelo número de faces da quadra, proporcionando maior poder descritivo e relacional das informações territoriais nesse sistema. Sua geocodificação é determinada a partir da face ao norte da quadra, seguindo no sentido horário, ou seja, em uma quadra de quatro faces, a face norte vai ser 01 e a face sul 03, enquanto a leste e a oeste respectivamente 02 e 04.
O segundo objeto que merece atenção é o trecho central, o segmento de logradouro, no centro das vias entre os cruzamentos, que compõem a entidade convencional logradouro. O trecho central é uma classe do tipo Geo-objeto com Geometria e Topologia especializada como uni-direcional, criando a rede da malha viária do tipo arco-nó no modelo, com o objeto geográfico cruzamento especializado como nó. É importante especificar que o sentido atribuído aos trechos centrais é associado à numeração dos lotes no logradouro. Os códigos utilizados para compor a identificação da calçada e do trecho foram retirados do arquivo de Lotes da PMJP.
Esse modelo de CTU do município de João Pessoa considerou os objetos espaciais calçada e trecho central como parcela. É preciso perceber que as parcelas do tipo lote e calçada da mesma quadra devem sempre estar em uma única e mesma divisão territorial do cadastro. Diferente dessas parcelas, a do tipo trecho central deve ter um entre dois tipos de relacionamento espaciais com as divisões cadastrais, alguns segmentos representam os limites de duas divisões, enquanto os restantes dos trechos devem estar contidos em uma única divisão territorial. Sua principal forma de representação deve ser como linha unidirecional, para a aplicação da metodologia do código de identificação.
Na figura 4, acima, está o diagrama de classes elaborado na aplicação OMT-G Designer que foi utilizado para o trabalho. Adiante, na tabela 2, consta o dicionário de dados do BDG, para facilitar o entendimento das consultas do próximo subtópico.
Tabela 2 Dicionário de dados BDG
| Item | Municipio | |||
| Descrição | Limite do município de João Pessoa | |||
| Observações | Informação geográfica do IBGE | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_mun | Código de identificação do município | Varchar | 5 | PK / Identity |
| nome_mun | Nome do município | Varchar | 50 | Not Null |
| codi_uf | Código de identificação da unidade federal | Varchar | 2 | Not Null |
| nome_uf | Nome da unidade federal | Varchar | 50 | Not Null |
| Item | setor_cartografico | |||
| Descrição | Classe georreferenciada da divisão territorial do Cadastro de João Pessoa, referente apenas a geometria do setor cartográfico 25 | |||
| Observações | Essa tabela possui chave estrangeira de município | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_setor | Código de identificação do setor cartográfico | Varchar | 2 | PK/Identity |
| codi_mun | Código de identificação do município | Varchar | 5 | FK/municipio |
| Item | Quadra | |||
| Descrição | Classe georreferenciada das quadras contidas no setor cartográfico 25 da área de estudo | |||
| Observações | Essa tabela possui chave estrangeira de setor_cartografico | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_quadra | Código de identificação da quadra | Varchar | 5 | PK/Identity |
| codi_setor | Código de identificação do setor cartográfico | Varchar | 2 | FK/setor_cartografico |
| n_faces | Número de faces da quadra | Int | - | Not Null |
| Item | Lote | |||
| Descrição | Super classe convencional para armazenamento das informações do lote | |||
| Observações | Essa tabela possui chave estrangeira de quadra, de calçada e de trecho_central | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_lote | Código de identificação do lote | Varchar | 9 | PK/Identity |
| Item | Lote | |||
| Descrição | Super classe convencional para armazenamento das informações do lote | |||
| Observações | Essa tabela possui chave estrangeira de quadra, de calçada e de trecho_central | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_quadra | Código de identificação da quadra | Varchar | 5 | FK/quadra |
| codi_calcada | Código de identificação da calçada | Varchar | 7 | FK/calcada |
| uso | Classificação de uso: residencial; comercial; serviço e indefinido | Varchar | 50 | Not null |
| numero | Número do lote no logradouro | Int | - | Not null |
| id_trecho | Chave primária do trecho central | Int | - | Fk/trecho_central |
| codi_trecho | Código de identificação do trecho central | Varchar | 14 | |
| area | Área do lote limite | Real | - | Not null |
| perimetro | Perímetro do lote limite | Real | - | Not null |
| Item | lote_limite | |||
| Descrição | Classe georreferenciada do limite dos lotes | |||
| Observações | Essa tabela possui chave estrangeira de quadra | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_lote | Código de identificação do lote | Varchar | 9 | PK/Identity |
| codi_quadra | Código de identificação da quadra | Varchar | 5 | FK/quadra |
| Area | Área do lote limite | Real | - | Not null |
| perimetro | Perímetro do lote limite | Real | - | Not null |
| Item | lote_face | |||
| Descrição | Classe georreferenciada da face do lote | |||
| Observações | Essa tabela possui chave estrangeira da calçada e do trecho_central | |||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_lote | Código de identificação do lote | Varchar | 9 | PK/Identity |
| codi_calcada | Código de identificação da calçada | Varchar | 7 | FK/calcada |
| numero | Número do lote no logradouro | Int | - | Not null |
| Item | lote_face | |||
| Descrição | Classe georreferenciada da face do lote | |||
| Observações | Essa tabela possui chave estrangeira da calçada e do trecho_central | |||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| id_trecho | Chave primária do trecho central | Int | - | Fk/trecho_central |
| codi_trecho | Código de identificação do trecho central | Varchar | 14 | - |
| Item | Calçada | |||
| Descrição | Classe georreferenciada da calçada | |||
| Observações | Essa tabela possui chave estrangeira da quadra e do trecho_central | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_calcada | Código de identificação da calçada | Varchar | 7 | PK/Identity |
| codi_quadra | Código de identificação da quadra | Varchar | 5 | FK/quadra |
| lado | Referência ao lado do objeto calçada no trecho central | Varchar | 50 | Not null |
| id_trecho | Chave estrangeira do trecho central | Int | - | Fk/trecho_central |
| codi_trecho | Código de identificação do trecho central | Varchar | 14 | - |
| Item | trecho_central | |||
| Descrição | Classe georreferenciada do trecho central do logradouro | |||
| Observações | Esse item possui duas chaves estrangeiras do cruzamento, duas da calçada e uma do logradouro | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio |
| Id | Chave primária do trecho_central | Int | - | PK |
| de_no | Chave estrangeira do cruzamento, referente ao ponto inicial | Int | - | Fk/cruzamento |
| para_no | Chave estrangeira do cruzamento, referente ao final inicial | Int | - | FK/cruzamento |
| calcada_esq | Chave estrangeira da calçada, do lado esquerdo | Varchar | 7 | FK/calcada |
| calcada_dir | Chave estrangeira da calçada, do lado direito | Varchar | 7 | FK/calcada |
| codi_trecho | Código de identificação do trecho central | Varchar | 14 | - |
| codi_lo | Chave estrangeira do logradouro | Int | - | FK/logradouro |
| Tabela | Cruzamento | |||
| Descrição | Classe georreferenciada do cruzamento | |||
| Observações | Nó da rede com trecho central | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_cruzamento | Chave primária do cruzamento | Int | - | PK |
| Tabela | Logradouro | |||
| Descrição | Super classe convencional do logradouro | |||
| Observações | Essa tabela possui chave estrangeira do trecho_central | |||
| Campos | ||||
| Nome | Descrição | Tipo de dado | Tamanho | Restrições de domínio (PK, FK, Not null, Check, Default, Identity) |
| codi_lo | Chave primária do logradouro | Int | - | PK |
| nm_comp_lo | Nome completo do logradouro | Varchar | 100 | Not null |
| cep | CEP do logradouro | Varchar | 8 | Not null |
| id_trecho | Chave estrangeira do trecho central | Int | - | Fk/trecho_central |
O processo de implementação do BDG Relacional foi realizado com SGBD PostgreSQL, com as extensões espaciais PostGIS e AST_PostGIS instaladas no banco de dados (BD). A partir da modelagem concluída na aplicação OMT-Designer, foi utilizado o modelo físico gerado no BD.
É importante ressaltar que a aplicação gera dois modelos físicos para implementar o BDG-R do modelo, sendo o primeiro relacionado a estrutura (DDL-Structure), e o segundo dinâmico (Dynamic-Constraints), que trata das relações espaciais implementadas pela extensão AST_PostGIS. Como dito anteriormente, foi preciso fazer algumas correções, mas apenas no modelo físico da estrutura.
Na figura 5 está parte do modelo físico que criou o BDG-R da aplicação, com o Script SQL da criação da entidade espacial da quadra, e das relações espaciais com o setor_cartografico e com o lote_limite. As informações geográficas que foram vetorizadas em cima da ortoimagem são: cruzamento, trecho_central, calcada, lote_face, lote_limite, e quadra. As informações alfanuméricas que compõem as entidades do BDG foram preenchidas a partir das informações do arquivo shapefile de lotes do cadastro fornecido pela PMJP.
A figura 6 é a visualização das informações geográficas vetorizadas que compõem o BDG-R, com exceção da visualização da camada da quadra abaixo da camada de lote. A partir dos objetos geográficos vetorizados, geometricamente ajustados às restrições espaciais do modelo e devidamente compostos com suas informações alfanuméricas, foram exportadas juntos com as informações geográficas do limite do município e do setor cartográfico 25 para o BDG-R no SGBD do PostgreSQL, utilizando a ferramenta PostGIS Shapefile Import/ExportManager.
A figura 7 apresenta a estrutura física do BDG-R implementada no SGBD do PostgreSQL e parte da estrutura dinâmica, referente às restrições espaciais da quadra.
3.2. Verificação do BDG, demonstração dos identificadores dos objetos calcada e trecho_central e uma breve discussão das possibilidades desse sistema
A extensão AST_PostGIS foi uma ferramenta muito pertinente ao trabalho, pois além de implementar os dados espaciais avançados e as relações espaciais OMT-G, ela incrementa funções para verificação das relações espaciais entre qualquer classe espacial do BDG, estando ou não a relação espacial das classes implementadas ao BDG.
Quando implementada ao BDG, a extensão AST_PostGIS cria a tabela ast_violation_log, onde é identificada e registrada toda violação da relação espacial entre os objetos das classes chamadas e determinadas na função de verificação espacial da extensão, visto na figura 8.
Na intenção de ter uma tabela para o registro de todos os tipos de resultados, mas apenas True ou False (verdadeiro ou falso), das funções chamadas de verificação de relação espacial da extensão AST_PostGIS, criou-se a tabela ast_validacao_log. Na figura 9 está o registro da tabela ast_validacao_log, que mostra todos os resultados das relações espaciais da extensão AST_PostGIS chamadas. Os oitos tipos de relações espaciais entre os objetos do modelo foram chamados e registrados como verdadeiro. Apenas a nona chamada, referente à relação espacial toque (touches) do objeto lote_face com trecho_central deu falso, o que corresponde a real situação desses objetos no BDG-R, como visto na figura 6.
Cabe destacar que não foi viável aplicar chave primária na metodologia de identificação do objeto trecho_central, porque apenas uma unidade desta classe possui as informações completas do cadastro territorial necessárias à aplicação do identificador. Na figura 10 é possível identificar esse único objeto do trecho_central que tem os parâmetros para aplicar a metodologia do código de identificação.
Na figura 11 está a seleção desse objeto, a coluna codi_trecho é o código identificador do trecho, criado a partir do código identificador das calçadas no trecho, nas colunas calcada_esq e calcada_dir. Com a consulta realizada para descobrir qual trecho da Rua Dep. Luiz Clementino de Oliveira (id_logradouro 3) que está entre a Av. Primeiro de Maio (id_logradouro 2) e a Rua Assis Vidal (id_logradouro 1). Essa consulta espacial utiliza a função ST_Touches, que identifica o trecho central do logradouro com id 3 que está entre os trechos do logradouro de id 2 e 1.
A criação do código de identificação do objeto do trecho central é dada a partir da junção dos códigos dos objetos da calçada esquerda com a calçada direita (fator cultural) relacionadas espacialmente ao trecho, podendo ser observada na tabela 3. Primeiro uniram-se os códigos dos setores onde estão as calçadas, seguido da quadra e face. Vale lembrar que é a numeração crescente da face do lote no logradouro que determina a direção do trecho central, com as faces dos lotes das calçadas do lado esquerdo com números ímpares, enquanto as do lado direito com números pares.
O código de identificação do trecho_central foi traçado para facilitar a identificação do tipo de relacionamento espacial das divisões cadastrais (Setores cartográficos), com alguns segmentos representando os limites de duas divisões, enquanto os restantes dos trechos devem estar contidos em uma única divisão territorial. No caso do objeto do trecho central apresentado na tabela 3 está contido em uma única divisão territorial.
Tabela 3 Código de identificação da calçada e trecho central
| Calçada esquerda | Calçada direita | Trecho_central |
| 2508002 | 2508104 | 25250800810204 |
O CTU da PMJP não possui a informação geográfica da calçada e, embora haja informação geográfica dos trechos de logradouro, é apenas aplicado o método de seriação comum (sem relação espacial de hierarquia), provavelmente por não ser considerado uma parcela. O código de identificação das parcelas cadastrais, de acordo com a Portaria n.º 511, deve possuir a propriedade de localizá-las territorialmente, pela característica do método de herança dos atributos das unidades espaciais relacionadas.
O procedimento metodológico que criou a identificação única dos objetos da calçada é similar ao que criou o código de identificação dos objetos da face de quadra (ou face de logradouro) da informação geográfica do Censo do IBGE de 2010, diferente na forma de representação e, por utilizar as informações do cadastro do município para compor o código de identificação, garante maior estabilidade ao código de identificação dos objetos da informação geográfica.
A figura 12 mostra a seleção das informações do identificador único da calçada esquerda do trecho central selecionado na figura 11, com o total de lotes com face para essa calçada e quantos destes são de uso comercial.
A consulta da figura 12 foi realizada para demonstrar as possibilidades e o potencial desse sistema cadastral básico, com as informações do número de lotes e uso por face da quadra presentes na informação geográfica face_logradouro do Censo do IBGE de 2010. Com isso, queremos demonstrar que um sistema cadastral eficiente e transparente pode revelar essas informações fidedignas à realidade do momento, em vez de serem disponibilizadas apenas a cada dez anos pelo IBGE.
A metodologia apresentada para os identificadores únicos e a representação espacial dos objetos geográficos calçada e trecho de logradouro - objetos identificados como parcelas para o modelo sobre cadastro urbano do trabalho - aumentaram a capacidade descritiva e relacional desse sistema territorial.
4. CONSIDERAÇÕES FINAIS
O trabalho evidenciou a utilização de uma estrutura Open Source que permite o desenvolvimento de um SIG baseado numa MDA para a implementação de um BDG-R no formato OMT-G. Esse artigo tenta aproximar os profissionais da área de geografia, de arquitetura e das engenharias às tecnologias de SGBD, a partir das discussões teóricas e práticas da temática do estudo.
O modelo do trabalho foi elaborado em virtude da verificação da necessidade de criar novas classificações de parcelas para o CTU de João Pessoa. Os objetos geográficos identificados como parcela nesse trabalho se evidenciaram como pedaços da terra com condição homogênea de existência dentro de seus limites, correspondendo ao entendimento de unidade espacial do “Cadastre 2014”. Entretanto, o modelo do trabalho não se apresenta acabado, pois as representações das entidades geográficas e as relações espaciais ainda podem ser plenamente desenvolvidas.
A afirmação acima é constatada principalmente na entidade do trecho central do modelo, objeto geográfico identificado como parcela, que foi parcialmente desenvolvido, a priori a representação cartográfica apenas como linha unidirecional é uma contradição ao conceito de parcela, além de não possuir relação espacial com a divisão territorial do cadastro (setores cartográficos) do município de João Pessoa - PB.
É pertinente entender que a identificação e classificação de espaços diferenciais de parcelas são fundamentais para o planejamento urbano e para a produção de um espaço urbano mais sustentável, contribuindo para a normatização de um parcelamento de solo mais coerente, facilitando assim a fiscalização. Considerar apenas o lote como objeto da transformação do espaço rural em urbano não é um bom indicador de desenvolvimento urbano sustentável, pois esse processo de parcelamento do solo pode criar loteamentos em área de vulnerabilidade ambiental, além de poder exceder a capacidade de ocupação da área, podendo vir a criar situações de desastre que poderiam ser evitadas.
Foi identificado que os manuais ou frameworks citados no trabalho trazem grandes contribuições, ainda assim, possuem um quadro muito subjetivo em relação ao entendimento da parcela. Portanto, pensando em trabalhos futuros, é interessante estudar outros tipos de unidades espaciais para a classificação de todas as parcelas do território do município, como rios e áreas de preservação permanente (APP) dentre outras, percebendo a parcela como um espaço diferencial que pode ser sistematicamente classificado.
