INTERSECÇÃO COM TOLERÂNCIA NO POSTGIS

A função ST_Intersects do PostGIS retorna verdadeiro se duas geometrias compartilham qualquer porção do espaço (é a "função contrária" à ST_Disjoint). Essa função recebe as duas geometrias envolvidas:

                ST_Intersects (a.geom, b.geom)

A função ST_Intersects tem elevada precisão (tolerância muito baixa). Mesmo quando a vetorização é feita com o “SNAP” (atração) habilitado, isso eventualmente pode ser um problema quando precisa ser usado em porções intermediárias de linhas ou polígonos (em pontos, vértices ou nós dificilmente ocorre), ou em algum outro caso específico. Uma solução para essa questão, que permite verificar intersecções com tolerância maior, é o uso da função ST_DWithin, que recebe por parâmetro, além das geometrias envolvidas, o valor tolerância (ou seja, funciona como se fosse um ST_Intersects com “buffer” definido pela tolerância).

                ST_DWithin (a.geom, b.geom, tolerância)

Obs.: A tolerância depende do sistema de coordenadas utilizado. Utilizei tolerância 0.00001 em sistema de coordenadas UTM e isso se mostrou bem adequado para trabalhar com elementos em cidades de médio porte.

TRANSFORMANDO GEOMETRIAS MÚLTIPLAS EM GEOMETRIAS SIMPLES NO POSTGIS

Como a ferramenta de importação de shapes no PostGIS (PostGIS Shapefile Import/Export Manager) tem como padrão a importação de geometrias múltiplas (multiline e multipolygon), mesmo que elas sejam geometrias simples, é comum se desejar a alteração dessas feições para geometrias simples (line e polygon). Isso pode ser feito de várias formas (habilitando a opção Generate simple geometries instead of MULTI geometries na importação, por exemplo), mas uma alternativa bem simples para essa alteração, que é feita diretamente no banco de dados, quando as geometrias deveriam ser simples (ou seja, são únicas, embora tenham sido importadas e/ou estejam definidas como múltiplas) é o uso da função ST_GeometryN:

ALTER TABLE nome_da_tabela ALTER COLUMN geom TYPE geometry(LineString,31982) USING ST_geometryN(geom,1);

No caso desse exemplo uma tabela que estivesse definida como MultiLineString passa a ser LineString (em polígonos basta substituir o LineString por Polygon). O exemplo usa como sistema de coordenadas o SIRGAS2000 na zona UTM 22 Sul (31982), para utilização de outro sistema basta trocar o número de identificação.

O exemplo acima serve apenas quando não há vários polígonos em um mesmo elemento. Para criar uma tabela (com geometrias simples) a partir de uma geometria múltipla (que cada elemento possua vários polígonos) use:

CREATE TABLE nome_da_tabela AS WITH dump AS (SELECT campo1, campo2, campo3,(ST_DUMP(geom)).geom AS geom FROM nome_da_tabela_de_origem) SELECT campo1, campo2, campo3, geom::geometry(LineString,31982) FROM dump;

GEOMETRIAS SIMPLES E MÚLTIPLAS

   Um conceito muito presente em bancos de dados geográficos é o de geometrias simples e múltiplas. Mas o ideal é usar Polygon ou MultiPolygon? LineString ou MultiLineString? A resposta depende do uso que se quer dar a essas feições.

   O conceito: primeiramente é importante entender o conceito, ou seja, o que diferencia geometrias simples de múltiplas. O melhor modo de entender isso é utilizando exemplos: em uma tabela de países, a área do Brasil poderia ser representada por um único polígono, mas e a do Japão? Seriam necessários pelo menos 4 polígonos para representar suas principais ilhas. Outro exemplo é que algumas rodovias no Brasil são descontinuadas, ou seja, uma linha apenas não poderia representá-las totalmente. Essa é a essência do conceito de múltiplas geometrias - em uma única feição pode ser armazenada mais de uma representação espacial, diferente das geometrias simples, onde cada feição associa-se a uma única representação espacial.

Obs.: Alguns bancos de dados espaciais também usam conceitos de coleções geométricas, onde podem coexistir linhas, pontos e/ou polígonos em uma mesma tabela.

   Quando usar: deve-se analisar cada caso, mas de modo geral pode-se dizer que o ideal é utilizar geometrias múltiplas apenas quando necessário (quando feições precisarem de mais de uma representação espacial) e para as demais situações utilizar geometrias simples, especialmente porque diversas funções espaciais somente funcionam sobre geometrias simples.

MATERIAIS SOBRE GEOPROCESSAMENTO

   Em contato com a área acadêmica e prática do geoprocessamento tenho encontrado algumas fontes de material online (que podem ser visualizados e baixados) muito ricas:

http://www.dpi.inpe.br/livros.php - Livros on-line da Divisão de Processamento de Imagens do Instituto Nacional de Pesquisas Espaciais, o INPE;

http://www.arq.ufmg.br/SiteLabGeo/Laboratorio_Geo/publicacoes.htm - Publicações do laboratório de geoprocessamento da Universidade Federal de Minas Gerais;

http://www.dsr.inpe.br/sbsr2007/biblioteca/ - Conteúdo completo (artigos) dos Simpósios Brasileiros de Sensoriamento Remoto.

   Além disso, usando as palavras-chave corretas é possível encontrar muito material em:

http://scholar.google.com.br/ (Google acadêmico – pesquisa específica em trabalhos acadêmicos);

http://www.dominiopublico.gov.br (Domínio público – disponibiliza diversos materiais que se encontram sob domínio público);

http://www.teses.usp.br/ (Biblioteca digital da Universidade de São Paulo – disponibiliza o material produzido pela USP; possui inclusive uma área específica sobre cartografia histórica).

   Outras universidades (UNICAMP, UNESP, etc.) também possuem bibliotecas digitais (e cursos relacionados à área) onde pode ser encontrado material. Caro leitor, participe enviando também outros lugares onde é possível encontrar material sobre geoprocessamento.

DEFININDO/ALTERANDO O SISTEMA DE COORDENADAS EM TABELAS DO POSTGIS

   Apesar de ser algo relativamente simples (mas ao mesmo tempo muito importante), tive bastante dificuldade de encontrar informações quando procurei sobre como definir e/ou alterar o sistema de coordenadas de geometrias dentro do PostGIS nas versões mais recentes do PostgreSQL/PostGIS, que definem os SRIDs na view geometry_columns (no meu caso, uso PostgreSQL 9.1 com PostGIS 2.0), portanto aqui está, de uma maneira simples, como fazer isso.

Para definer o SRID use:

ALTER TABLE nome_da_tabela ALTER COLUMN coluna_espacial TYPE Geometry(tipo_da_geometria, numero_do_SRID_desejado) USING ST_SetSRID(coluna_espacial, numero_do_SRID_desejado);

Exemplo:

ALTER TABLE ponto_onibus ALTER COLUMN geom TYPE Geometry(Point, 31982) USING ST_SetSRID(geom,31982);

(define o SRID 31982 – SIRGAS 2000 UTM 22 Sul – para a tabela ponto_onibus, representada por pontos) .

Para alterar (transformar, ou seja, fazer a conversão de um SRID já definido para outro) o SRID use:

ALTER TABLE nome_da_tabela COLUMN coluna_espacial TYPE Geometry(tipo_da_geometria, numero_do_SRID_desejado) USING ST_Transform(coluna_espacial, numero_do_SRID_desejado);

Exemplo:

ALTER TABLE dutos ALTER COLUMN geom TYPE Geometry(LineString,29192) USING ST_Transform(geom,29192);

(altera a tabela dutos, representada por linhas, para o SRID 29192 – SAD69 UTM 22 Sul) .

Observações:

- As informações sobre todos os sistemas de coordenadas disponíveis encontram-se na tabela spatial_ref_sys, no schema public.

- As informações sobre os SRIDs das tabelas encontram-se na view geometry_columns, no schema public.

SISTEMAS DE INFORMAÇÃO GEOGRÁFICA, BANCOS DE DADOS ESPACIAIS E ARQUITETURAS

   Dentre os Sistemas de Informações Geográficas mais utilizados destacam-se os proprietários ArcGIS e IDRISI, e os livres Quantum GIS, gvSIG, GRASS e SPRING (embora este não possa ser considerado um software livre, é gratuito e brasileiro), entre outros. No caso dos Sistemas Gerenciadores de Bancos de Dados Espaciais (ou Geográficos) temos os proprietários Oracle Spatial e SQL Server 2008, e os livres PostGIS (extensão do PostgreSQL), MySQL e SpatiaLite (extensão do SQLite, que não é propriamente um SGBD, mas sim uma biblioteca em C que implementa um banco de dados embutido com funções SQL), entre outros.
   Embora seja muito usado na área pela facilidade de acesso local e disponibilidade, o Microsoft Access não possui suporte espacial, no entanto é utilizado (assim como outros SGBDs) através da arquitetura dual, ou seja, os dados alfanuméricos são armazenados no banco de dados e os dados espaciais (o “desenho”) é armazenado em formatos específicos definidos pelo SIG em uso. No entanto, essa abordagem tem uma série de limitações, como a dependência de um SIG específico, acesso apenas local e outros.
   O fato é que, infelizmente, muitos profissionais que atuam na área desconhecem o uso de bancos de dados espaciais e as diversas vantagens associadas ao seu uso (como possibilidade de acesso concorrente, relacionamentos e funções de topologia, manipulação direta de dados espaciais, etc.). Isso se deve a diversos fatores, especialmente a falta de qualificação adequada, o uso do SIG apenas como cadastro, e outros. Mas é importante lembrar que há muito material na internet (especialmente em relação aos softwares livres, devido ao contexto comunitário de seu desenvolvimento e aplicação) e, com alguma dedicação e um pouco de tempo, é perfeitamente possível a um profissional que atua na área limitado por um banco de dados local e/ou sem suporte espacial migrar para um contexto de SGBD com suporte espacial e maior liberdade em relação ao SIG utilizado.
   Após um bom tempo de pesquisas, optei na minha atividade profissional pelo uso do PostGIS e do SIG Quantum GIS. No caso do PostGIS por ter ampla integração com SIGs em geral (praticamente todos os mais utilizados possuem suporte a esse SGBD) e o Quantum GIS foi escolhido por possuir uma interface muito amigável, ser de fácil uso, ter suporte à linguagem Pyton (com diversos complementos) e às ferramentas Sextante, além de não interferir no banco de dados PostGIS (alguns SIGs exigem algumas modificações e/ou adequações no SGBD), mas sempre que necessário (para algum tipo de análise específica indisponível no Quantum GIS, por exemplo) utilizo também outros SIGs.

RETOMANDO AS ATIVIDADES...

   Após um bom tempo com o blog parado (apesar das novidades na parte profissional), estou retomando as postagens. Nesse período que passou, entrei definitivamente para a área de geoprocessamento, atuando como Analista de Geoprocessamento no setor público. Isso ocorreu vários meses atrás, mas preferi esperar alguma experiência profissional começar a aparecer para voltar a postar. Também devido a esse contexto, diversas postagens de agora em diante terão um foco mais prático e específico que as anteriores, que eram mais abrangentes e conceituais.
   Já reuni material para diversas postagens e pretendo voltar a postar continuamente, pois acho fundamental a divulgação do conhecimento, ainda mais considerando que tenho trabalhado com softwares livres. 

   Portanto, em breve, novas postagens sobre geoprocessamento no BLOG GEOGRAFANDO...