Agricultura Familiar e Geoprocessamento
Olá Pessoal!
Hoje gostaria de comentar com vocês sobre um trabalho elaborado pela também Tecnóloga em Geoprocessamento, Julie Eugênio.
Há algum tempo ela preparou um projeto de gerenciamento de atividades de agricultura familiar fazendo uso de técnicas de Geoprocessamento.
O objetivo principal da pesquisa dela foi o desenvolvimento de uma aplicação, com base em técnicas de Geoprocessamento, para apoiar as atividades de um projeto voltado à agricultura familiar sustentável denominado “Cinturão Verde”, inserido no programa de microcrédito “Empreender-JP”, no município de João Pessoa, capital do Estado da Paraíba.
O mapa abaixo mostra a localização da área de estudo.
Durante a construção da aplicação SIG integrada a um Banco de Dados Geográficos deu-se ênfase ao uso de tecnologias livres, com destaque para o Quantum Gis (QGis) e PostgreSQL/PostGis.
Na parte escrita do trabalho desenvolvido foi detalhada toda a metodologia empregada. A qual está resumida na figura abaixo.
O trabalho foi extremamente elogiado pelos responsáveis técnicos da prefeitura de João Pessoa. Você pode fazer o download do trabalho completo a partir do link abaixo, que traz o tema da monografia escrita com base nesse projeto.
Espero que tirem proveito de mais essa demonstração da potencialidade do uso de tecnologias livres para Geoprocessamento.
Abraços.
--
Anderson Medeiros
Tecnólogo em Geoprocessamento
Criação de Templates para PostGIS
Olá a todos, muito bom está por aqui novamente.
Hoje vou falar para vocês de um assunto que na minha graduação o Prof. Marcello Benigno[1] sempre "enchia o saco" repetindo e repetindo e repetindo... a criação de templates para o banco de dados (no nosso caso, PostgreSQL[2]). Templates nada mais são que modelos pré-definidos de banco de dados, que aumentam a produtividade na criação de novos bancos. Neles nós colocamos características comuns aos bancos de dados que serão criados e só associamos os novos bancos a eles.
Como exemplo, hoje a tarde precisei recriar um template_postgis para que pudesse sincronizar uma aplicação geodjango a ele (A aplicação poderá ser vista em breve na edição número 1 da revista Geo.NET), então fiz da seguinte forma:
Como root chamei o postgres:
# su postgres
Após entrar no root postgres, mandei criar um novo banco de dados chamado template_postgis:
$ createdb -U postgres template_postgis
A opção "-U" do comando createdb se refere ao usuário que será dono do banco, ou do template, como é nosso caso (Para maiores informações sobre outras opções do comando createdb digite $ man createdb). Para esta versão, o root postgres é por default o dono das tabelas, bancos e templates criados, por tanto, não faz necessário informá-lo como usuário.
Para que seja possível rodar as funções da extensão espacial postgis, é necessário a criação da linguagem procedural plpgsql. Por meio desta, é possível rodar as funções contidas nos arquivos lwpostgis.sql e ref_spatial_sys.sql, arquivos estes que contem funções que resolvem referência espacial, tipos de geometrias, sistemas de coordenadas e etc. Para criar a linguagem, basta usar o comando:
$ createlang -d template_postgis -U postgres plpgsql
A opção "-d" informa para qual banco de dados, ou template será criada a nova linguagem procedural (Para maiores informações, consulte $ man createlang).
Depois de ter criado a linguagem, basta importar os arquivos lwpostgis.sql, lwpostgis_upgrade.sql e spatial_ref_sys.sql. Para isso usaremos o terminal interativo do pgsql através do comando:
$ psql -d template_postgis -f lwpostgis.sql
$ psql -d template_postgis -f lwpostgis_upgrde.sql
$ psql -d template_postgis -f spatial_ref_sys.sql
Neste ponto é importante tomar nota de que, se o usuário não estiver no path onde estão os arquivos acima, lhe será retornado um erro. Para evitar tal erro, consulte a documentação para a sua distribuição.
Para confirmar se tudo correu bem, entre no template e faça uma consulta às tabelas da seguinte forma:
$ psql -d template_postgis
template_postgis=# \dt Lista de relações Esquema | Nome | Tipo | Dono ---------+------------------+--------+---------- public | geometry_columns | tabela | postgres public | spatial_ref_sys | tabela | postgres (2 registros)
Observe que dentro do template_postgis foram criadas as tabelas espaciais, e que por default o dono das mesmas é o root postgres. Agora ficou simples, pois sempre que for preciso criar um db com extensão espacial, basta rodar o comando:
$ psql -T template_postgis <nome_novo_db>
Este novo db será criado, e dentro dele já estarão inseridas as tabelas espaciais.
Fácil não é? 
Abraço a todos.
Referencias:
[1] Prof. Marcello
[2] PostgreSQL
Vicente Martins.
shp2pgsql: Você conhece esta fantástica ferramenta?
Olá pessoal, boa noite.
É tempo de retomar a implementação de antigos projetos no trabalho (isso soa estranho né?), para poder mostrar que existem ferramentas livres, super-poderosas e que trazem respostas a várias perguntas de "onde" estão os problemas.
Neste trabalho que estou reiniciando na Companhia, estamos implementando um DB (Data Base) que guardará um monte de informações que estavam soltas nas mãos de todos os seus "donos".
Com estas informações, será possível fazer várias análises, inclusive espaciais, e diponibilizá-las em um ambiente interno [intranet] a partir de uma aplicação WebGIS, o que facilitará o acesso a informação de interesse comum, bem como facilitará o planejamento das decisões a serem tomadas. É sim um projeto extravagante, uma vez que um "novato" vai mexer com o lugar e "poder" de muita gente lá dentro, mas em contra-partida, tenho certeza que isso trará melhorias para a Companhia, o que é na verdade o objetivo do mesmo.
Para vocês hoje, trago uma ferramenta que a muito tempo não utilizava, mas que é extremamente importante quando falamos de PostGIS: shp2pgsql. O Anderson a um tempo atrás disponibilizou um mini-tutorial no ClickGeo[1], que inclusive serviu de fonte de pesquisa para mim, e que recomendo para quem quer utilizar shp2pgsql. Algumas outras pesquisas na documentação oficial da extensão[2], mais algumas conversas com o próprio Anderson e outros amigos da área, me vi "obrigado" a compartilhar mais um pouco de conhecimento.
A shp2pgsql, como o prórpio nome sugere, é um aplicativo que transforma arquivos shapefile da ESRI em sql, em que os antigos dados em formato shapefile são inseridos dentro das tabelas de um Data Base em PostgeSQL/PostGIS da maneira correta.
Para tanto, é necessário conhecer alguns parametros que precisamos informar ao aplicativo. De maneira geral, a utilização do shp2pgsql se dá da seguinte forma:
# shp2pgsql /path/do/shape/dado.shp nome_tabela > nome_arquivo.sql
# psql -d nome_DB -f nome_arquivo.sql
Convenções:
- "#" você precisa estar logado como super-usuário para utilizar esta ferramenta;
- "/path/do/shape/dado.shp" é o caminho onde está guardado o dado em shapefile;
- "psql -d" define o Data Base utilizado;
- "psql - f" executa o arquivo .sql indicado. Talvez seja necessário informar o caminho total do arquivo ".sql", caso não se esteja dentro do path indicado.
Porém, é possível informar alguns parametros para o aplicativo shp2pgsql que facilita a inserção dos dados desejados. Dentre os principais (ao menos para mim, foram os mais utilizados) cito:
-s: Este parametro define o SRID (Spatial Reference System Identifier)que será utilizado.
# shp2pgsql -s <SRID> dado.shp nome_tabela > nome_arquivo.sql
-W: Este parametro informa a codificação em que está o seu Data Base, inserindo os dados na mesma codificação.
# shp2pgsql -s <SRID> -W <encoding> dado.shp nome_tabela > nome_arquivo.sql
Bem, fora estes, o carregador de dados shp2pgsql traz outros parametros de inserção de dados que vale a pena ser consultado. De qualquer forma, é interessante consultar a documentação.
Vou ficando por aqui.
Abraço a todos.
Vicente Martins.
Referências:
[1] ClickGeo - Importando Arquivos Shapefile para PostGIS 8.1 via prompt do DOS
Monografia
Boa noite pessoal,
Muita gente já me pediu e estava sem tempo de colocar online, mas agora vai.
A Construção de um Sistema Geocodificado de Acidentes de Trânsito
Defendi a monografia ano passado e fica como referência para quem tiver interesse.
Tenho certeza que não é perfeita, portanto, se tiverem algumas dúvidas ou enxergarem alguns erros, por favor, entre em contato
Abraços
George
O Geoprocessamento e Suas Tecnologias – Parte 2
Olá!
Conforme vimos na primeira parte deste post, o Geoprocessamento é um conjunto de tecnologias dinâmicas com alto potencial de aplicação.
Até aqui vimos que Geoprocessamento e SIG não são as mesma coisa. O SIG é apenas uma importante tecnologia dentre as diversas incluídas no Geoprocessamento.
Vimos também que programas como o gvSIG e ArcGis não são "SIGs" mas softwares para SIG. Assim como o Geoprocessamento possui várias ramificações tecnológicas o SIG é um sistema composto por softwares, hardwares, metodologias, recursos humanos e dados.
Ficamos de ver o que são e pra servem tecnologias como o Banco de Dados Geográfico e o WebMapping.
Banco de Dados Geográficos
Bom, vamos por partes. O que é um Banco de Dados (BD)?
Todo local, físico ou virtual onde estão armazenados dados, pode em certo sentido, ser chamado de banco de dados. Por exemplo, uma enciclopédia pode ser considerada um banco de dados. Mas para nós aqui da área de Geoprocessamento é mais importante o conceito especial de banco ou base de dados relacional. Ou seja um banco onde dados são armazenados na forma de tabelas relacionáveis entre si através campos chaves.
As mais diversas facetas de atividades, desde locadoras de DVD até grandes indústrias metalúrgicas usam-se deste tipo de base para ter um maior controle sobre fatores como cadastro de clientes e sua condição em relação à empresa (Inadimplência, por exemplo).
Neste ponto, é importante evitar confundir o BD em sí (conjunto de tabelas relacionáveis) com o programa que o gerenciará, o Sistema Gerenciador de Banco de Dados (SGBD). EM outras palavras, softwares como Access, MySQL, Oracle, PostgreSQL não são BD, mas sim SGBD.
Mas ainda não falamos no assunto deste tópico. O que é e para que serve um Banco de Dados Geográfico (BDG)?
O BDG, também chamado de Banco de Dados Espacial (BDE), é semelhante ao descrito acima (relacional), com a grande e importante diferença de suportar feições geométricas em suas tabelas.
Este tipo de base com geometria oferece a possibilidade de análise e consultas espaciais. É possível calcular nestes casos, por exemplo, áreas, distâncias e centróides, além de realizar a geração de buffers e outras operações entre as geometrias.
Como dica de estudos para você obter uma boa base conceitual sobre BDG, indico o livro "Banco de Dados Geográficos" do INPE, que está disponível para download em PDF aqui.
Atualmente, alguns programas de SGBD desenvolveram extensões que inserem no software características de Sistemas Gerenciadores de Banco de Dados Geográficos (SGBDG) o PostgreSQL, MySQL, e Oracle, sendo os dois primeiros softwares livres e o último proprietário.
Vamos falar um pouco mais do PostgreSQL e como ele passa a agir como SGBDG. O PostgreSQL é desenvolvido atualmente pela PostgreSQL Global Development Group. Quando se percebeu a necessidade de extender este SBGD para suportar dados espaciais desenvolveu-se a extensão conhecida como PostGis.
Sendo assim, vamos entender que o PostGis não é um BDG ou um SGBDG, ele é apenas uma extensão, um plugin, do PostgreSQL que lhe confere funções para armazenamento e manipulação de dados geográficos.
A figura abaixo procura mostrar a diferença entre o PostgreSQL e "seu filho". Note que para termos um BDG no PostgreSQL faz-se necessária a devida instalação da extensão PostGis.
Você pode importar arquivos vetoriais shapefile (*.shp) para dentro de um "Banco PostGis" utilizando recursos oferecidos pelo próprio programa ou utilizando algum software de SIG com essa funcionalidade. O shapefile será convertido em uma tabela espacial que pode ser integrada com as convencionais contidas na base, além de poder ser visualizada e manipulada através de programas como o gvSIG, Kosmo, Quantum Gis, Udig e muitos outros desta safra. Para baixar tutoriais sobre como realizar esta operação com alguns destes softwares, clique aqui.
Para baixar a versão mais recente do PostgreSQL e sua extensão espacial PostGis, acesse os links abaixo.
Para finalizar este post vamos considerar outra tecnologia do Geoprocessamento, a saber, WebMapping.
WebMapping (WebGis)
A internet vem se destacando nos últimos anos como uma excelente ferramenta para disponibilização e interligação de dados das mais diversas fontes e naturezas.
A geomática, como área do conhecimento, também encontrou na internet um nicho para suas atividades. A disponibilização de mapas digitais, os chamados WebGis ou WebMapping, tem-se tornado comum, permitindo que um maior número de usuários tenha acesso a dados espacializados, de forma hábil e atraente.
Talvez o estopim para o crescimento das aplicações SIG para internet tenha sido a popularização de serviços online gratuitos de localização como o Google Earth e Google Maps.
Os mapas na web se apresentam de três formas princiapais:
1) Mapas Estáticos - Mapas no formato de imagem (*.jpg, *.gif, *.png, etc) integrados à páginas da internet.
2) Mapas Gerados à partir de formulários - Fornece-se parâmetros para geração de mapas na forma de imagem.
3) Mapas Dinâmicos - O usuário seleciona uma área de seu interesse em um mapa geral, gerando uma navegação para outro mapa ou imagem mais específico com informações mais detalhadas desta região. Em geral apresentam interface atraente com ícones para consulta espacial calculo de distância e etc.
Para mais detalhes sobre tipos de mapas veja a publicação disponibilizada neste link.
Há muitos softwares e frameworks livres para o desenvolvimento de aplicações WebGis. Podemos destacar alguns: MapServer, GeoServer, i3Geo, Alov Map, Time Map, Open Layers e P.Mapper.
Diversos órgãos públicos fazem uso destas ferramentas para divulgação dos resultados de seus trabalhos.
A imagem abaixo mostra um exemplo de aplicação desenvolvida com MapServer e o framework P.Mapper. Clique aqui para acessar a página da aplicação (Este é um exemplo de mapa dinâmico).
Nesta visão geral sobre algumas das tecnologias do Geoprocessamento, pudemos dissipar alguns falsos conceitos em torno de termos como SIG, BDG, SGBDG, WebGis, etc. Espero que tenham gostado do que leram.
Fiquem à vontade para deixar sua sugestão de tema, críticas e impressões através do e-mail anderson[@]geoprocessamento.net
Anderson Medeiros
Tecnólogo em Geoprocessamento
Acidentes de Trânsito e Geoprocessamento
Olá novamente pessoal,
Venho falar com vocês de um assunto sério: acidentes de trânsito. Matam milhares de pessoas, ferem outras milhares e custam aos cofres públicos milhares de reais anualmente. Claro que o dinheiro neste caso não é o denominador comum, mas imaginem:
De acordo com o IPEA (Instituto de Pesquisas Econômicas Aplicadas) cada acidente de trânsito custa, em média, por vítima envolvida:
- vítima ilesa: R$1.040,00
- vítima ferida: R$36.305,00
- vítima fatal: R$270.165,00
São valores absurdos. Isso, de acordo com o IPEA, envolve não só custos materiais e despesas hospitalares, mas também perda de produção, ou seja, dias parados no trabalho.
Bem, e o que Geoprocessamento ou SIG tem à ver com isso? Bem, um acidente é um evento extremamente complexo, com diversas variáveis importantes para uma macro-análise do trânsito e da segurança viária. Então, como conhecer um acidente de trânsito e suas variáveis? Como analisar a frequência de acidentes e as condições de tráfego de cada via? Podemos correlacionar os acidentes com mau tempo?
Um sistema que cadastre e analise acidentes é o ideal. Mas como localizar cada acidente? Temos à nossa disposição em quase todos os softwares de SIG/GIS ferramentas que executam a geocodificação. A geocodificação é basicamente o processo de se assinalar uma localização pontual (um ponto) à uma descrição textual, geralmente um endereço. Podemos utilizar ferramentas de geocodificação para localizar acidentes? Afirmativo. E focos de dengue? Afirmativo. E...qualquer coisa que possua um endereço em seu cadastro.
Um sistema deste tipo pode ajudar a salvar vidas e a diminuir o gasto público com obras ou medidas de segurança desnecessárias. Um sistema que realize este trabalho pode dar aos responsáveis pelo planejamento viário, subsídio técnico-científico para a proposição de medidas concretas.
Durante minha monografia, tentei desenvolver um sistema que fizesse este tipo de trabalho. Utilizei para o trabalho o banco de dados PostgreSQL e PostGIS e um algoritmo de geocodificação desenvolvido por David Bitner (não tenho o endereço do algoritmo, mas se quiserem dar uma olhada só me pedir por email).
Funcionou?
Funcionou, mas existem alguns percalços no caminho: a polícia militar e outros órgãos que registram os acidentes de trânsito em boletins de ocorrência, algumas vezes registram somente a via em que o acidente ocorreu e as vias que interseccionam aquele trecho (Rua X, entre rua A e Avenida B) ou somente o cruzamento em que o mesmo ocorreu.
Ferramentas de geocodificação tradicionais não suportam este tipo de endereçamento, portanto utilizei um pouquinho de código pl/pgsql para adicionar esta funcionalidade. Seria um sistema muito ruim se mais da metade dos acidentes cadastrados não fossem possíveis de serem geocodificados. Qualquer análise espacial realizada seria furada, pois os dados não estão completos.
Certo, mas o que eu preciso para montar algo similar? Ok, vamos lá.
- Uma base de referência de logradouros, com os seguintes atributos (ou similares): ID_Trecho, ID_Logradouro, Tipo_Logradouro, Nome_Logradouro, Numero_Inicial_Esquerdo, Numero_Inicial_Direito, Numero_Final_Esquerdo e Numero_Final_Direito, Intersecao_Anterior e Intersecao_Posterior. A base deve conter os trechos de logradouros devidamente preenchidos.
- Você pode usar um Guia Sei ou IR A CAMPO, e anotar estas numerações. Claro que para um projeto maior isto não funcionaria, mas é um começo. Nos campos Numeracao*, devem constar as numerações iniciais/finais de cada lado da via e em Intersecao* os logradouros que interseccionam aquele trecho.
- O algortimo geocodificador e um serviço geocodificador. Tudo isto vem com o algoritmo. O algoritmo é um pedaço de código que é orientado pelo serviço. O serviço é criado preenchendo-se a tabela correta, onde indicaremos qual é a base de referência e quais são os campos de interesse.
- Não tem quatro. É só isso.
Bem cada acidente tem suas características, um número x de veículos envolvidos e outras informações relativas à cada motorista e gravidade de ferimentos (por veículo). A maioria dos algoritmos geocodificadores possuem ferramentas para geocodificação ad-hoc (propósito em si) e podemos desenvolver maneiras para geocodificador dados em batch (ou fornadas, levas, etc.).
No caso deste trabalho, foi desenvolvido um trigger ou gatilho, disparado assim que um usuário inserir alguma coisa na tabela que registra os acidentes, realizando uma busca pela representação pontual daquele endereço. Este trigger também avalia o tipo de endereço inserido pelo usuário, se ele representava um endereço completo (Rua A, 768) ou se representava um cruzamento (Rua A com Rua B) ou se apenas continha os valores das interseções (Rua A, entre Rua B e Rua C).
As funções complementares, que geocodificam entre intersecções ou em cruzamentos são apenas o uso simples de SQLs comuns e da função nativa do PostGIS ST_Line_Interpolate_Point, que recebe como argumentos a linha que se deseja interpolar a uma porcentagem.
Certo, como localizar um cruzamento? Bem, lembra que nossa base de referência possui o atributo Sufixo_Direcao e que este representa para qual linha "estamos indo"? Então, para selecionar a linha e mandar ela para a função, foi utilizando o seguinte:
SELECT * FROM logradouros WHERE Tipo_Logradouro = 'TipoEscolhido AND Nome_Logradouro = 'NomeEscolhido' AND Sufixo_Direcao = 'IntersecaoPosteriorEscolhida'.
À partir daí é só o caso de jogar na função: ST_Line_Interpolate_Point(ResultadoQuery,.99). A função já lhe retorna o ponto desejado.
E como usar esta função para localizar um acidente que ocorreu entre intersecções? Bem, como não temos idéia de onde o acidente ocorreu na via, utilizamos o ponto médio do logradouro para localizá-lo.
A função utilizada é a mesma, a única coisa que muda é o SQL, onde especificamos também um Prefixo_Direcao e ao invés de .99 na porcetagem da função, utilizamos .5, nos retornando o exato ponto médio daquele trecho.
Bem isso foi apenas uma pequena introdução à geocodificação e ao pequeno trabalho que realizei durante o ano de 2008. O sistema está pronto e funcioona! Mas ninguém usa 
.
Já existe um sistema para cadastro de acidentes em Uberlândia, mas é um sistema proprietário, e quem o desenvolvou não tem nem idéia do que Geoprocessamento significa. Ainda vai levar um bom tempo para os órgãos públicos descobrirem o tanto que as novas tecnologias podem ajudar, a poupar e neste caso, até a salvar vidas.
George
History Tables – pt 1
Boa noite pessoal.
Uns posts atrás falei sobre uma função que permitisse e criasse automaticamente as regras e tabelas para armazenamento de registros históricos no PostGIS.
Bem, aqui vão algumas questões: O PostgreSQL nos permite lidar com este tipo de situação de duas formas: Rules e/ou Triggers.
No caso do nosso projetinho, foram utilizadas rules para lidar com o que precisamos fazer. Bem, o que deve ter um histórico de feições?
Primeiramente ele deve guardar todas as feições inseridas, atualizadas e deletadas, bem como a data, hora, nome do usuário que realizou a alteração, e uma coisa interessante, qual é a versão atual daquela feição. Desta forma podemos rastrear quais foram as alterações históricas de cada versão e caso preciso, achar a versão mais apropriada e restaurá-la para o banco de dados principal.
Além disso, temos um registro histórico de fato. Sabemos todas as alterações de uma feição. É possível entender como um lote mudou, por exemplo, ou como um animal rastreado por GPS está se movimentando. Outra coisa bacana, podemos saber como está evoluindo a cobertura vegetal de uma determinada região. Aumentou? Diminuiu? Não existe ambiguidade ou imperícia. Tudo pode ser restaurado e analisado de acordo com uma dimensão extra, o tempo.
Bem, vou postar aqui a estrutura de uma tabela histórica:
CREATE TABLE foo_history ( history_id SERIAL NOT NULL, date_created timestamp NOT NULL DEFAULT NOW(), date_deleted timestamp DEFAULT NULL, operation VARCHAR(20) NOT NULL, user VARCHAR(80) NOT NULL DEFAULT CURRENT_USER, current_version VARCHAR(80), LIKE foo, CONSTRAINT foo_history_pk PRIMARY KEY(history_id) );
É mais ou menos isso. Deêm uma olhada na linha 8, a expressão LIKE foo. Ela diz ao PostgreSQL que ele deve procurar a estrutura da tabela foo, e copiar ela todinha embaixo. Legal não? Imagine a tabela foo:
CREATE TABLE foo ( fid SERIAL NOT NULL, classe_vegetacao VARCHAR(30) NOT NULL, CONSTRAINT foo_pk PRIMARY KEY(fid) ); -- nossa tabela final gerada pela função é: CREATE TABLE foo_history ( history_id SERIAL NOT NULL, date_created timestamp NOT NULL DEFAULT NOW(), date_deleted timestamp DEFAULT NULL, operation VARCHAR(20) NOT NULL, user VARCHAR(80) NOT NULL DEFAULT CURRENT_USER, current_version VARCHAR(80), fid INTEGER, classe_vegetacao VARCHAR(30), CONSTRAINT foo_history_pk PRIMARY KEY(history_id) );
*Uma particularidade: qualquer campo do tipo SERIAL (como fid, na tabela foo) é realmente do tipo INTEGER. Quando declaramos SERIAL, o PostgreSQL entende que deve criar uma sequência específica para aquele campo e escolhe o valor padrão para aquele campo o próximo valor daquela sequência.
Bem, para começar precisamos de um código SQL que gere automaticamente este código acima. Ele precisa gerar a tabela sem que o usuário digite nada, apenas escolha a tabela que ele quer montar um registro histórico.
Nosso código também precisa montar automaticamente as regras que vão realizar a gestão desta tabelinha acima. Lembre-se que precisamos de uma regra para cada tipo de modificação na tabela, uma para INSERT, uma para UPDATE e uma para DELETE.
Cada uma tem uma particularidade, pois as alterações na tabela histórica não são as mesmas. A regra para delete, por exemplo, não deve criar novo registro na série histórica, apenas indicar que o registro foi deletado.
Não é muito complicado, mas também não é muito simples. Daqui uns dias falo deste códigozinho e dou umas dicas sobre ele.
George Silva
Contribuindo um pouquinho…
Boa noite pessoal,
Alguns dias atrás me cadastrei no trac da OsGeo para ver se conseguia solucionar algum tiquete em aberto.
Para quem não sabe, trac é um sistema que controla as informações sobre bugs, melhoramentos entre outras coisas à fazer, dentro de um projeto de software. Ele permite um usuário aceitar uma tarefa, postar arquivos e mensagens e receber comentários em seu trabalho.
Aceitei o tíquete #180 que pede a criação de algumas funções para criar tabelas "históricas", permitindo o usuário saber quem alterou a tabela, como alterou, quando e todas as alterações feitas. À partir daí ele tem opções de restaurar uma feição que foi deletada ou editada de forma errada, entre outras coisinhas.
Montei algumas funções em pl/pgsql puro para gerar estes códigos, e as mesma estão disponíveis no link mostrado acima. Ainda existe muita discussão à ser feita para que elas comecem a pertencer ao código "oficial" do PostGIS, mas está caminhando. PS do dia 13/01/2010 - o patch foi aceito e já foi comitado em trunk. Provavelmente seu PostGIS já vem com o módulo, com algumas mudanças. Não deixe de conferir!
O bacana, além de aprender e conhecer gente nova, é poder devolver um pouco pra um software excelente. Uma contribuição pequena, com certeza, mas que mais pra frente pode ajudar muita gente.
George Silva
